Well, now you can, kinda, right? Since you can charge standard USB-C, any USB outputting external battery should power the Mac. Carry as many as you want!
That's not really true. USB-C has multiple operating voltages, and both sides have to agree to support a given operating voltage, or else you won't get any power from it. An external battery could potentially provide 5V, 12V, 15V, or 20V. The internal battery is likely 14V, so a 5V supply will be completely ignored, and a 12V supply will probably power the laptop, but will not charge the battery, and will result in the internal battery slowly draining when the CPUs are going at full tilt.
So you would need a USB-C brick designed for powering a laptop, as opposed to one designed to power a cell phone or tablet.
If by "successful", you mean that his ROI was less than sticking the money in an index fund and forgetting about it, then sure, we can call him that. Hey! That means I'm a successful businessman, too! Cool!
They really shouldn't have cut the capacity at all. Better to give people longer battery life. The existing machines were already plenty thin, so nobody benefits from shaving off half a millimeter or whatever, whereas lots of people would be happier with four hours of battery life under heavy load instead of three.:-)
I'm not sure that you should so be so quick to assume that you can ignore the SoC's power consumption, though. I'd imagine that its CPU must be at least as capable as the one in the Apple Watch, if not more so, because the screen is bigger. And that can burn through its ~1 Wh battery in 2.5 hours under heavy use (*). Over the supposed 10-hour battery life of a laptop, that's 4 Wh out of 75, which means that in the worst case (e.g. with the touch CPU stuck in a tight loop), more than 5% of the battery's capacity could get burned by that second CPU alone. I mean, a 5% increase in consumption under unusual circumstances isn't the end of the world, but it isn't really lost in the noise, either.
(*) Admittedly, the numbers above are exaggerating the CPU consumption a bit, because the Apple Watch also has a radio, but I don't have any good way to compute the CPU power consumption more precisely, nor can I be certain that the CPU really is in a comparable performance class to the Apple Watch. So there's a fair amount of speculation involved.:-)
Yeah, that would be. Well, in that case, count your blessings that you bought your machine when you did. A few years later, you'd have gotten one whose power connector was even worse.:-)
I've never gotten five hours on any 15" MacBook Pro while running Xcode, and I've used three of them (mine, my previous employer's, and my current employer's). Part of the problem is that Xcode's CPU utilization increases by at least n^2 and maybe n^3 based on the size of the project file. Tiny projects seem to work fine and you can deal with them for several hours, but when you open up bigger projects, it can take five minutes just to get the point where it doesn't SPOD at every click. The reason for the SPODding is that Xcode keeps one CPU running at 100% continuously for the first two hours indexing all the files in the project every single time you change git branches. On those projects, your battery capacity is nowhere near five hours.
I've never gotten more than about three hours while running Finale, either. With Garritan instruments enabled, it runs potentially multiple instances of their VI audio unit plugins continuously (at low latency) so that it can quickly play notes as you click them in on the staff. This sucks battery life like you wouldn't believe. I've never gotten more than about three hours or so while doing that. (I'm estimating here, but it sure as hell isn't five, much less eight.)
But yeah, this new version is significantly worse.
I guess I'm not sensible then because I expect self-driving cars to rigidly adhere to all traffic laws especially something as simple as a speed limit.
I expect this not because I don't realize that autonomous vehicles can respond quicker than humans and have better collision detection sensors than humans, but because they are mindless programmed automatons that should rigidly adhere to a set of rules that are programmed into them.
I expect them to be capable of doing something that simple. I'm saying that I don't think they should be required by law to do so, but rather that the law should adapt to allow vehicles to judge the maximum safe speed using some reasonable set of rules even if the result of that computation results in the vehicle exceeding the speed limit by some reasonable margin.
On the other hand, I'm not convinced that it will actually be possible to get speed limits completely correct. There's no guarantee that a camera will be able to see a speed sign, depending on other vehicles on the road, which means it will depend on a database of speed limits.
If you've ever driven with a Garmin that supposedly gives the speed limits, you know that even on minor highways, it is frequently off by a quarter mile. And it frequently says that the speed limit is 5–10 MPH lower or higher than it actually is. And that isn't even taking into consideration temporary speed limits, etc. I have approximately zero faith in local governments to properly report speed limit changes to the appropriate agencies to ensure that this data stays up-to-date, particularly when they can take advantage of the discrepancy to raise revenue for their communities.
So basically, there are going to be situations where self-driving cars go too fast or too slow based on the speed limit. It is pretty much inevitable. That's what makes it all the more important to make sure that there are universal standards for choosing a reasonable speed for the road that all autonomous vehicles adhere to. And if we have those standards, then it becomes largely irrelevant whether the autonomous vehicles adhere to the posted limits at that point.
I have occasionally seen this on the 2014/2015 retina MBPs as well, but not often. It certainly isn't the sort of thing that happens frequently or highly reproducibly, though, and I've never seen it drain the battery in an hour. That sort of power consumption shouldn't even be possible with all four cores running full tilt. Maybe the GPU is doing something crazy.
That said, I doubt that this has anything to do with Safari, but rather with something Safari is doing that's tickling a bug related to the touch bar. Otherwise, everybody would be seeing these power management failures frequently, rather than frequently on touch bar MBPs and rarely on other models.
For that matter, the touch bar CPU itself could be burning through the battery. I mean, there's something bordering on bats**t crazy about adding a second CPU and simultaneously cutting the power capacity by 25%.
Magsafe tends to be really bad if you do things like use your laptop in bed while plugged in.
I think you misspelled "MagSafe 2". The original MagSafe was much more robust against those sorts of things (ignoring its tendency to fail to show a proper charge light at times). It was only when Apple redesigned the connector to make the machine even thinner that its reliability started to suck. (Hmm. I'm sensing a pattern.)
If a background daemon gets into a tightly rolled loop consuming 100% of a CPU, the battery will run down quickly. And if that background daemon is one that is specific to the new hardware, it would affect only that model. So chances are, the problem is caused by some of the software that manages the new touch strip.
That said, it is likely that the smaller battery in the new model makes the problem worse than it otherwise would be.
This has always been the case with the MacBook Pro. For example, on the 2014-ish 15" retina models, you could easily burn through an "8 hour" battery in two or three hours by running things like Lightroom, Xcode, Finale (with Garritan instruments enabled), etc. For folks running high-end pro apps, Mac laptops haven't gotten great battery life since they took away our ability to put the machine to sleep, swap in a second battery, and keep going.
Don't get me wrong, I love the fact that the newer batteries don't stop working after a couple of years like the older ones, but I would kill to have a MacBook Pro with current-generation LiPo batteries in a removable form factor at 100 Wh apiece.
The batteries aren't big enough, and Apple's power saving features are too aggressive, leading to a situation where the slightest load that pokes the machine in the wrong way (ie, anything that causes the GPUs to switch, or more CPU cores to wake up) will cause your battery % to drop through the floor.
According to one report, they originally planned to use a bigger battery and ran into manufacturing problems and had to fall back to the smaller battery. That said, the story seems suspect, given that they used a bigger battery in every prior model, meaning that the larger-capacity batteries should already exist and be thoroughly tested. It seems more likely that it's a cover story (as in "cover your *** story"), and that some designer's mandate for decreased thickness overrode all the engineers saying that reducing battery capacity was a bad idea.
The answer is either "lots" (who were summarily ignored), or "none at all" (because everyone was fearing for their jobs- thou shall not go against thy word of thy great Ive).
If the answer is "none at all", it probably isn't because they feared for their jobs, but rather because so many of the older generation have left for other companies, and the new college hires running the show strongly exhibit the Dunning–Kruger effect. But I suspect the answer is "lots", and that the engineers were ignored in favor of thin. The evidence of design trumping function is just too overwhelming in product after product to believe that engineering has much (if any) real input until after things go catastrophically wrong and a product starts slipping.
Autonomous vehicles need to avoid doing anything that would cause problems for non-autonomous vehicles and pedestrians (e.g. going the wrong way on one-way streets, ignoring lane markers, going twice the speed limit, etc.), but strict adherence to speed limits is completely pointless and unnecessary even in the short term. For that matter, most of the time, it is pointless even for human drivers, much less for reverse-panopticon AI cars.
We tolerate speed limits because of the safety benefits, but there's no reason to tolerate them in situations where they have no benefit. So I would expect most areas that do autonomous car pilot programs to fairly quickly set a separate maximum speed for autonomous vehicles based only on mechanical factors like curve tightness and traffic light timing, without all the safety padding designed for meat popsicles. I would expect the owners of those vehicles to insist on it.
Here is a video from a few days ago of a self-driving car running a red light. So, sadly, no. The belief that a machine which has been programmed by humans is now incapable of making mistakes is one that I'm surprised to hear from a Slashdot user.
I never said that they would be incapable of making mistakes. Initially, they have to be at least as good as humans, or we shouldn't let them on the road, but they need not be better (though many of these systems already are, statistically).
But in the long run, as they get better at driving (machine learning, etc.), they should quickly become dramatically better than humans. After all, humans learn from their mistakes individually; computers learn from their mistakes collectively.
I've seen nothing to indicate that it was ever intended to apply only to content hosted on developers' servers. The original articles all said that ATS exceptions would go away, and that only web views would be able to make noncompliant requests, which breaks as soon as you add NSURLProtocol into the mix. Maybe that wasn't the perception Apple intended to create, but it is the one they created. (Or, more likely, that was the perception they intended to create, but they got so much backlash that they backed down. Either way....)
BTW, I haven't looked at the iOS Chrome source code, but at least on other platforms, Chrome uses its own networking stack built on top of plain old TCP sockets. Chances are, the iOS version does, too, in which case it wouldn't be affected by ATS anyway. Other browsers, not so much.
So this abundance of choice is a good thing as far I'm concerned. It means more chances for serial dramas and comedies that I do like. It means more chances for entertainment that any one can enjoy.
Unfortunately, in my experience, it usually means quite the opposite. The more shows are in simultaneous production, the fewer viewers there are per show, on average. This means that more shows means less chance of any given show finding its audience before poor ratings cause the network brass to cancel it. We're already seeing most shows not make it past the first season. Before long, we'll see most shows not make it past the first half season. And the net result will be more content of lesser quality, left unfinished, aborted mid-story-arc by overzealous management who see each show as nothing more than a share number instead of as a creative work that people should want to enjoy over the long term.
Most sensible people expect that self-driving cars will go significantly above the speed limit, because the reasons for limiting them to the speed limit (inability to look everywhere at once and see people pulling out of driveways, see kids about to run across the street unexpectedly, etc.) don't apply when you have a dozen cameras being monitored continuously by an AI, nor do most common human failings like inattentiveness, inability to properly assess speed of traction loss on curves, poor judgment of road conditions in general, etc. Anyone who would expect a self-driving car to obey a speed limit intended for humans with human reaction time (particularly on open highways) is arguably insane, or at best, a complete luddite.
Similarly, self-driving cars need not continue to obey traffic lights once they have achieved critical mass....
Besides breaking a lot of apps, what good would it do to enforce it? It would take all of a day to write a basic emulation layer to pass NSURLRequest objects to libcurl. This already got delayed once by six months, and now it is delayed indefinitely because it breaks major apps by major companies in ways that can't readily be fixed without abandoning Apple's networking stack, which some folks are probably already doing in response. The policy backfired, and chances are good that it will *never* be implemented, because doing so would make the platform as a whole less secure rather than more.
The sandboxing thing drove a number of very high-profile developers from the MAS, and is widely regarded as a complete failure, both because of that and because it prevented entire categories of apps from being available through the MAS, eliminating any possibility of most users realistically choosing to limit their Mac to only MAS titles and thus significantly reducing its utility as a curated app distibution channel.
They should not be in a hurry to repeat that mistake. At least on the Mac platform, there was an alternative—direct distribution. Apple won't allow that om iOS, so entire categories of apps, if forced to enable ATS, would have only two options: Switch to libcurl with an emulation layer or leave the iOS platform entirely. (See my comments elsewhere about this breaking any app that deals with user-entered URLs for non-web purposes and also breaks web views when backed by custom NSURLProtocol subclasses.)
Indeed, I used to work for a company whose app's downloads got blocked in various countries because the URLs were sent in the clear. My snarky comment was that app developers will care about web security as soon as Apple does.
But the big reason the ATS mandate was absurd is that lots of apps have to be able to download arbitrary content from arbitrary URLs, and web views aren't necessarily involved. And even when they are, developers often need to work around limitations in iOS WebKit by using custom NSURLProtocol subclasses to manipulate web view traffic on its way out (e.g. adding custom headers, authentication credentials, etc.). With ATS enabled, doing that becomes impossible.
So yeah, mandatory ATS was never going to fly, and lots of us said so almost immediately after the announcement. I'm glad they finally got the message.
Many pro users just want a powerful machine that doesn't require any special accommodation to make it usable in their studio. Rack mountability and portability? Those are niche cases. More important is silence and desk space. The trash can is a brilliant design for a single-computer, quiet desktop.
Rack mounting is common in recording studios, and portable rack use is common for gigging musicians. Silence is critical, but the previous Mac Pro was also fairly quiet until the fans ramped up, and the difference in baseline noise level goes away if you have to attach a third-party RAID box to make up for a lack of adequate internal storage. Lack of even a single drive bay was IMO a critical design mistake.
For that matter, most recording studio setups deliberately use separate drives for audio data and the OS so that occasional paging and other system activity doesn't impact audio performance. And although the faster random access performance of the SSD certainly helps with that, a system with only one drive is still arguably compromised by design for audio purposes even if you ignore the lack of capacity, because the previous Mac Pro could have multiple SSDs if you needed them.
The trash can would make a better midrange system with a single, modest (geforce 1050 range) graphics card and a single consumer-grade, quad processor. Those things don't even need to be replaceable if the system price is in the $1500 range.
This. It's an overpriced high-end Mac Mini, not a true successor to the Mac Pro. The Mac Pro was effectively discontinued in 2013.
It is an elegant design that completely ignores the needs of its target audience in favor of making something pretty. Most pros don't care at all about a sleek and elegant design, because we stick the computers under our desks anyway. What we care about are all the things that the previous Mac Pro did, but the current one doesn't. The tower design was a much, much better design for a sizable percentage of pro users, and the new design is a major downgrade that looks like it was designed as a high end Mac Mini with beefier CPUs and GPUs instead of as a pro machine.
With the exception of the faster CPU, the faster GPU, and the PCIe-attached SSD (all of which Apple could have done much more easily in the previous form factor), the only advantage that the new Mac Pro design has over the old one is cooling (fan noise). Unfortunately, the only people who care significantly about fan noise are audio recording engineers, and:
Recording studios need way more than a terabyte of storage.
Recording requires fast, low-latency storage, so they can't readily use a NAS in another room.
Apple doesn't build any silent RAID arrays to go with the Mac Pro.
So their super-silent Mac Pros have a noisy third-party RAID array right next to them, completely defeating the purpose of making the computer silent in the first place. Worse, if folks take those machines on the road and need external storage, they have to carry two pieces of hardware instead of one.
Additionally:
The previous design was trivially adaptable to rack mounting. The new one has to sit on a shelf.
It is challenging to transport on the road because if it falls on its side, it rolls.
It isn't stackable. The space it occupies and the space above it are lost, because it vents heat from the top.
It has no standard PCIe slots, making GPU upgrades unlikely.
It has no SD slot, requiring an unsightly external dongle that diminishes the visual appeal that would otherwise attract designer/photographers. (Mind you, neither did the previous model, which annoyed me on an ongoing basis, so at least they are consistent.)
It lacks dual-link DVI, which at least initially was a minor headache for many folks.
Apple's stock SSD is considerably slower than the PCIe SSDs you can use on the towers.
The twelve-core configuration of the trash can is still not significantly faster in multicore performance than the fastest tower version, but costs considerably more.
The single-core performance is considerably worse, so poorly multithreaded apps like Xcode really bog down on the newer models.
None of those design deficiencies impact every user, but each one takes a chunk out of potential sales by making it less suitable for some segment of one of its target markets. And these are just the design flaws that come to mind off the top of my head. For example, I seriously considered buying one myself before I realized that I would never survive with only a terabyte of effectively non-expandable storage, and I didn't want to spend ten grand for something that wouldn't really be faster than a previous-generation machine costing a fraction as much.
So basically, I'm not sure who the new Mac Pro was supposed to appeal to. It looks very pretty on your desk until you start hooking up external storage to replace the functionality that was present on the previous model. And in terms of functionality, it is more disposable than previous models, offering significantly fewer upgrade options, and yet costs significantly more. It is an absolutely baffling design that IMO marked the start of Apple's descent into madness. And that's why we say that it isn't "pro".
Perhaps not driving, but it actually does explain certain changes in thought processes after having kids. I've noticed that some women become hyper-protective after having kids, with an exaggerated fear of every theoretical danger. Of course, humans are not particularly good at understanding probability to begin with, so I always assumed that this perception was just confirmation bias on my part, or at most was the result of social conditioning (being around other hyper-protective people making people hyper-protective).
When you look at this in conjunction with the study that compared liberal and conservative brains, however, this study paints a different picture. That study showed that conservatives had more grey matter in the amygdala (the fear center) and less grey matter in the anterior cingulate cortex (the part of brain that handles complexity). Although this study doesn't show increased grey matter in the amygdala, it does show less grey matter in the angular cingulate cortex (among other parts) with no reduction in the amygdala to balance that out. Based on that, it stands to reason that these female brain changes during pregnancy make mothers more protective of their offspring, thus at least historically improving the odds of the survival of the species.
The question, then, is whether this grey matter loss can be prevented. As an advanced society, we aren't constantly running from predators, and we don't need those same sorts of relative increases in fear response after pregnancy. These days, those changes mostly harm society by creating helicopter parents that harm social development of their offspring. If we could find a way to prevent this grey matter loss, we would likely improve society immensely.
It may also have to do with the fact that California has invested in higher education more than any other state. Look where the founders of these companies come from! It may also have to do with California having things like public transportation so that people can actually get to work. The weather in Florida is just as good as California and no earthquakes. We have no tech industry to speak of and much lower taxes.
The funny thing is that half my coworkers at the startup where I first worked in the Valley were originally from Florida and used to work at a tech company there. Florida, despite its favorable tax structure, used to have a tech industry and basically no longer does. Keeping a knowledge-based industry requires a certain critical mass, and if you don't have that, the industry disintegrates.
This also ensures that instead of their games stopping working in three or four OS releases from insufficient maintenance, they'll stop working in three or four years when they turn down their DRM server.
According to the analyst quoted in this Slashdot article [slashdot.org], as much as 50% of GN7 Owners have, or planned to, switch to an iPhone 7. Considering that means completely changing platforms for the user involved, that's a very high number. Even the "more solid" number of just under 30% is pretty high, considering it's a platform-change.
Any GN7 owners have replaced their devices by now. So whatever sales they might have gained from this have already happened. But from what I've read, those sales predictions didn't materialize, in part because the cell carriers gave big discounts for anybody who replaced their GN7 with another Samsung device.
The iPhone 6s is enjoying a bit of a renaissance, due to the recently-decreased price and increased memory. So it is probably picking-up some budget-conscious iPhone users. But I think the iPhone 7 is still more popular than the 6s. And in fact, it is [bgr.com]. So there's another lie of yours disproven by facts...
Uh... you're comparing a brand new feature release model to a year-old bug-fix release. Its initial sales, despite better availability, were slower according to several analysts. A couple of analysts say that they were comparable or slightly better. Either way, a new phone release should be comparable to the iPhone 6, and all the reports I've read say that it isn't even in the same league.
Of course, we'll never know for sure, because Apple conveniently stopped reporting their per-model sales numbers. Companies don't generally stop reporting numbers if they're good news, which leads me to believe that iPhone 7 is probably not selling nearly as well as hoped.
iOS Marketshare Plummeting: Not according to this article [9to5mac.com] from just a week ago, which states that iPhone 7 Marketshare Growth is the strongest, and overall market share is the highest, in the U.S., and not so bad in other places (e.g. #2 in China, #1 in the U.K.)., than it has been in two years. That sounds like anything but dire sales figures to me...
That might be true for U.S. sales, but according to Gartner group, worldwide iOS sales were down by over 7% year-over-year at last check, verging on single-digit percentage territory. That's a level that Apple hasn't enjoyed since the original iPhone. Fortune is slightly less pessimistic, but even they aren't predicting growth.
So, try harder at your Hater bullshit next time, willya? It was hardly even challenging exposing your bullshit for exactly that.
Hater? Hardly. I own an iPhone 6s and a Retina MacBook Pro, I run my server infrastructure on Macs, and I worked for Apple for almost thirteen years. Most of the time, I'm the first to defend their product decisions. For me to say that they screwed up, they have to really screw up.
Slashdot Mirror
That's not really true. USB-C has multiple operating voltages, and both sides have to agree to support a given operating voltage, or else you won't get any power from it. An external battery could potentially provide 5V, 12V, 15V, or 20V. The internal battery is likely 14V, so a 5V supply will be completely ignored, and a 12V supply will probably power the laptop, but will not charge the battery, and will result in the internal battery slowly draining when the CPUs are going at full tilt.
So you would need a USB-C brick designed for powering a laptop, as opposed to one designed to power a cell phone or tablet.
If by "successful", you mean that his ROI was less than sticking the money in an index fund and forgetting about it, then sure, we can call him that. Hey! That means I'm a successful businessman, too! Cool!
They really shouldn't have cut the capacity at all. Better to give people longer battery life. The existing machines were already plenty thin, so nobody benefits from shaving off half a millimeter or whatever, whereas lots of people would be happier with four hours of battery life under heavy load instead of three. :-)
I'm not sure that you should so be so quick to assume that you can ignore the SoC's power consumption, though. I'd imagine that its CPU must be at least as capable as the one in the Apple Watch, if not more so, because the screen is bigger. And that can burn through its ~1 Wh battery in 2.5 hours under heavy use (*). Over the supposed 10-hour battery life of a laptop, that's 4 Wh out of 75, which means that in the worst case (e.g. with the touch CPU stuck in a tight loop), more than 5% of the battery's capacity could get burned by that second CPU alone. I mean, a 5% increase in consumption under unusual circumstances isn't the end of the world, but it isn't really lost in the noise, either.
(*) Admittedly, the numbers above are exaggerating the CPU consumption a bit, because the Apple Watch also has a radio, but I don't have any good way to compute the CPU power consumption more precisely, nor can I be certain that the CPU really is in a comparable performance class to the Apple Watch. So there's a fair amount of speculation involved. :-)
Yeah, that would be. Well, in that case, count your blessings that you bought your machine when you did. A few years later, you'd have gotten one whose power connector was even worse. :-)
I've never gotten five hours on any 15" MacBook Pro while running Xcode, and I've used three of them (mine, my previous employer's, and my current employer's). Part of the problem is that Xcode's CPU utilization increases by at least n^2 and maybe n^3 based on the size of the project file. Tiny projects seem to work fine and you can deal with them for several hours, but when you open up bigger projects, it can take five minutes just to get the point where it doesn't SPOD at every click. The reason for the SPODding is that Xcode keeps one CPU running at 100% continuously for the first two hours indexing all the files in the project every single time you change git branches. On those projects, your battery capacity is nowhere near five hours.
I've never gotten more than about three hours while running Finale, either. With Garritan instruments enabled, it runs potentially multiple instances of their VI audio unit plugins continuously (at low latency) so that it can quickly play notes as you click them in on the staff. This sucks battery life like you wouldn't believe. I've never gotten more than about three hours or so while doing that. (I'm estimating here, but it sure as hell isn't five, much less eight.)
But yeah, this new version is significantly worse.
I guess I'm not sensible then because I expect self-driving cars to rigidly adhere to all traffic laws especially something as simple as a speed limit.
I expect this not because I don't realize that autonomous vehicles can respond quicker than humans and have better collision detection sensors than humans, but because they are mindless programmed automatons that should rigidly adhere to a set of rules that are programmed into them.
I expect them to be capable of doing something that simple. I'm saying that I don't think they should be required by law to do so, but rather that the law should adapt to allow vehicles to judge the maximum safe speed using some reasonable set of rules even if the result of that computation results in the vehicle exceeding the speed limit by some reasonable margin.
On the other hand, I'm not convinced that it will actually be possible to get speed limits completely correct. There's no guarantee that a camera will be able to see a speed sign, depending on other vehicles on the road, which means it will depend on a database of speed limits.
If you've ever driven with a Garmin that supposedly gives the speed limits, you know that even on minor highways, it is frequently off by a quarter mile. And it frequently says that the speed limit is 5–10 MPH lower or higher than it actually is. And that isn't even taking into consideration temporary speed limits, etc. I have approximately zero faith in local governments to properly report speed limit changes to the appropriate agencies to ensure that this data stays up-to-date, particularly when they can take advantage of the discrepancy to raise revenue for their communities.
So basically, there are going to be situations where self-driving cars go too fast or too slow based on the speed limit. It is pretty much inevitable. That's what makes it all the more important to make sure that there are universal standards for choosing a reasonable speed for the road that all autonomous vehicles adhere to. And if we have those standards, then it becomes largely irrelevant whether the autonomous vehicles adhere to the posted limits at that point.
I have occasionally seen this on the 2014/2015 retina MBPs as well, but not often. It certainly isn't the sort of thing that happens frequently or highly reproducibly, though, and I've never seen it drain the battery in an hour. That sort of power consumption shouldn't even be possible with all four cores running full tilt. Maybe the GPU is doing something crazy.
That said, I doubt that this has anything to do with Safari, but rather with something Safari is doing that's tickling a bug related to the touch bar. Otherwise, everybody would be seeing these power management failures frequently, rather than frequently on touch bar MBPs and rarely on other models.
For that matter, the touch bar CPU itself could be burning through the battery. I mean, there's something bordering on bats**t crazy about adding a second CPU and simultaneously cutting the power capacity by 25%.
I think you misspelled "MagSafe 2". The original MagSafe was much more robust against those sorts of things (ignoring its tendency to fail to show a proper charge light at times). It was only when Apple redesigned the connector to make the machine even thinner that its reliability started to suck. (Hmm. I'm sensing a pattern.)
If a background daemon gets into a tightly rolled loop consuming 100% of a CPU, the battery will run down quickly. And if that background daemon is one that is specific to the new hardware, it would affect only that model. So chances are, the problem is caused by some of the software that manages the new touch strip.
That said, it is likely that the smaller battery in the new model makes the problem worse than it otherwise would be.
This has always been the case with the MacBook Pro. For example, on the 2014-ish 15" retina models, you could easily burn through an "8 hour" battery in two or three hours by running things like Lightroom, Xcode, Finale (with Garritan instruments enabled), etc. For folks running high-end pro apps, Mac laptops haven't gotten great battery life since they took away our ability to put the machine to sleep, swap in a second battery, and keep going.
Don't get me wrong, I love the fact that the newer batteries don't stop working after a couple of years like the older ones, but I would kill to have a MacBook Pro with current-generation LiPo batteries in a removable form factor at 100 Wh apiece.
According to one report, they originally planned to use a bigger battery and ran into manufacturing problems and had to fall back to the smaller battery. That said, the story seems suspect, given that they used a bigger battery in every prior model, meaning that the larger-capacity batteries should already exist and be thoroughly tested. It seems more likely that it's a cover story (as in "cover your *** story"), and that some designer's mandate for decreased thickness overrode all the engineers saying that reducing battery capacity was a bad idea.
If the answer is "none at all", it probably isn't because they feared for their jobs, but rather because so many of the older generation have left for other companies, and the new college hires running the show strongly exhibit the Dunning–Kruger effect. But I suspect the answer is "lots", and that the engineers were ignored in favor of thin. The evidence of design trumping function is just too overwhelming in product after product to believe that engineering has much (if any) real input until after things go catastrophically wrong and a product starts slipping.
Autonomous vehicles need to avoid doing anything that would cause problems for non-autonomous vehicles and pedestrians (e.g. going the wrong way on one-way streets, ignoring lane markers, going twice the speed limit, etc.), but strict adherence to speed limits is completely pointless and unnecessary even in the short term. For that matter, most of the time, it is pointless even for human drivers, much less for reverse-panopticon AI cars.
We tolerate speed limits because of the safety benefits, but there's no reason to tolerate them in situations where they have no benefit. So I would expect most areas that do autonomous car pilot programs to fairly quickly set a separate maximum speed for autonomous vehicles based only on mechanical factors like curve tightness and traffic light timing, without all the safety padding designed for meat popsicles. I would expect the owners of those vehicles to insist on it.
I never said that they would be incapable of making mistakes. Initially, they have to be at least as good as humans, or we shouldn't let them on the road, but they need not be better (though many of these systems already are, statistically).
But in the long run, as they get better at driving (machine learning, etc.), they should quickly become dramatically better than humans. After all, humans learn from their mistakes individually; computers learn from their mistakes collectively.
I've seen nothing to indicate that it was ever intended to apply only to content hosted on developers' servers. The original articles all said that ATS exceptions would go away, and that only web views would be able to make noncompliant requests, which breaks as soon as you add NSURLProtocol into the mix. Maybe that wasn't the perception Apple intended to create, but it is the one they created. (Or, more likely, that was the perception they intended to create, but they got so much backlash that they backed down. Either way....)
BTW, I haven't looked at the iOS Chrome source code, but at least on other platforms, Chrome uses its own networking stack built on top of plain old TCP sockets. Chances are, the iOS version does, too, in which case it wouldn't be affected by ATS anyway. Other browsers, not so much.
Unfortunately, in my experience, it usually means quite the opposite. The more shows are in simultaneous production, the fewer viewers there are per show, on average. This means that more shows means less chance of any given show finding its audience before poor ratings cause the network brass to cancel it. We're already seeing most shows not make it past the first season. Before long, we'll see most shows not make it past the first half season. And the net result will be more content of lesser quality, left unfinished, aborted mid-story-arc by overzealous management who see each show as nothing more than a share number instead of as a creative work that people should want to enjoy over the long term.
Most sensible people expect that self-driving cars will go significantly above the speed limit, because the reasons for limiting them to the speed limit (inability to look everywhere at once and see people pulling out of driveways, see kids about to run across the street unexpectedly, etc.) don't apply when you have a dozen cameras being monitored continuously by an AI, nor do most common human failings like inattentiveness, inability to properly assess speed of traction loss on curves, poor judgment of road conditions in general, etc. Anyone who would expect a self-driving car to obey a speed limit intended for humans with human reaction time (particularly on open highways) is arguably insane, or at best, a complete luddite.
Similarly, self-driving cars need not continue to obey traffic lights once they have achieved critical mass....
Besides breaking a lot of apps, what good would it do to enforce it? It would take all of a day to write a basic emulation layer to pass NSURLRequest objects to libcurl. This already got delayed once by six months, and now it is delayed indefinitely because it breaks major apps by major companies in ways that can't readily be fixed without abandoning Apple's networking stack, which some folks are probably already doing in response. The policy backfired, and chances are good that it will *never* be implemented, because doing so would make the platform as a whole less secure rather than more.
The sandboxing thing drove a number of very high-profile developers from the MAS, and is widely regarded as a complete failure, both because of that and because it prevented entire categories of apps from being available through the MAS, eliminating any possibility of most users realistically choosing to limit their Mac to only MAS titles and thus significantly reducing its utility as a curated app distibution channel.
They should not be in a hurry to repeat that mistake. At least on the Mac platform, there was an alternative—direct distribution. Apple won't allow that om iOS, so entire categories of apps, if forced to enable ATS, would have only two options: Switch to libcurl with an emulation layer or leave the iOS platform entirely. (See my comments elsewhere about this breaking any app that deals with user-entered URLs for non-web purposes and also breaks web views when backed by custom NSURLProtocol subclasses.)
. . . .it's not like Apple has a good record on SSL/TLS. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections.
This is NOT Rocket Science. . . .
Indeed, I used to work for a company whose app's downloads got blocked in various countries because the URLs were sent in the clear. My snarky comment was that app developers will care about web security as soon as Apple does.
But the big reason the ATS mandate was absurd is that lots of apps have to be able to download arbitrary content from arbitrary URLs, and web views aren't necessarily involved. And even when they are, developers often need to work around limitations in iOS WebKit by using custom NSURLProtocol subclasses to manipulate web view traffic on its way out (e.g. adding custom headers, authentication credentials, etc.). With ATS enabled, doing that becomes impossible.
So yeah, mandatory ATS was never going to fly, and lots of us said so almost immediately after the announcement. I'm glad they finally got the message.
Rack mounting is common in recording studios, and portable rack use is common for gigging musicians. Silence is critical, but the previous Mac Pro was also fairly quiet until the fans ramped up, and the difference in baseline noise level goes away if you have to attach a third-party RAID box to make up for a lack of adequate internal storage. Lack of even a single drive bay was IMO a critical design mistake.
For that matter, most recording studio setups deliberately use separate drives for audio data and the OS so that occasional paging and other system activity doesn't impact audio performance. And although the faster random access performance of the SSD certainly helps with that, a system with only one drive is still arguably compromised by design for audio purposes even if you ignore the lack of capacity, because the previous Mac Pro could have multiple SSDs if you needed them.
This. It's an overpriced high-end Mac Mini, not a true successor to the Mac Pro. The Mac Pro was effectively discontinued in 2013.
It is an elegant design that completely ignores the needs of its target audience in favor of making something pretty. Most pros don't care at all about a sleek and elegant design, because we stick the computers under our desks anyway. What we care about are all the things that the previous Mac Pro did, but the current one doesn't. The tower design was a much, much better design for a sizable percentage of pro users, and the new design is a major downgrade that looks like it was designed as a high end Mac Mini with beefier CPUs and GPUs instead of as a pro machine.
With the exception of the faster CPU, the faster GPU, and the PCIe-attached SSD (all of which Apple could have done much more easily in the previous form factor), the only advantage that the new Mac Pro design has over the old one is cooling (fan noise). Unfortunately, the only people who care significantly about fan noise are audio recording engineers, and:
So their super-silent Mac Pros have a noisy third-party RAID array right next to them, completely defeating the purpose of making the computer silent in the first place. Worse, if folks take those machines on the road and need external storage, they have to carry two pieces of hardware instead of one.
Additionally:
None of those design deficiencies impact every user, but each one takes a chunk out of potential sales by making it less suitable for some segment of one of its target markets. And these are just the design flaws that come to mind off the top of my head. For example, I seriously considered buying one myself before I realized that I would never survive with only a terabyte of effectively non-expandable storage, and I didn't want to spend ten grand for something that wouldn't really be faster than a previous-generation machine costing a fraction as much.
So basically, I'm not sure who the new Mac Pro was supposed to appeal to. It looks very pretty on your desk until you start hooking up external storage to replace the functionality that was present on the previous model. And in terms of functionality, it is more disposable than previous models, offering significantly fewer upgrade options, and yet costs significantly more. It is an absolutely baffling design that IMO marked the start of Apple's descent into madness. And that's why we say that it isn't "pro".
Perhaps not driving, but it actually does explain certain changes in thought processes after having kids. I've noticed that some women become hyper-protective after having kids, with an exaggerated fear of every theoretical danger. Of course, humans are not particularly good at understanding probability to begin with, so I always assumed that this perception was just confirmation bias on my part, or at most was the result of social conditioning (being around other hyper-protective people making people hyper-protective).
When you look at this in conjunction with the study that compared liberal and conservative brains, however, this study paints a different picture. That study showed that conservatives had more grey matter in the amygdala (the fear center) and less grey matter in the anterior cingulate cortex (the part of brain that handles complexity). Although this study doesn't show increased grey matter in the amygdala, it does show less grey matter in the angular cingulate cortex (among other parts) with no reduction in the amygdala to balance that out. Based on that, it stands to reason that these female brain changes during pregnancy make mothers more protective of their offspring, thus at least historically improving the odds of the survival of the species.
The question, then, is whether this grey matter loss can be prevented. As an advanced society, we aren't constantly running from predators, and we don't need those same sorts of relative increases in fear response after pregnancy. These days, those changes mostly harm society by creating helicopter parents that harm social development of their offspring. If we could find a way to prevent this grey matter loss, we would likely improve society immensely.
The funny thing is that half my coworkers at the startup where I first worked in the Valley were originally from Florida and used to work at a tech company there. Florida, despite its favorable tax structure, used to have a tech industry and basically no longer does. Keeping a knowledge-based industry requires a certain critical mass, and if you don't have that, the industry disintegrates.
This also ensures that instead of their games stopping working in three or four OS releases from insufficient maintenance, they'll stop working in three or four years when they turn down their DRM server.
Any GN7 owners have replaced their devices by now. So whatever sales they might have gained from this have already happened. But from what I've read, those sales predictions didn't materialize, in part because the cell carriers gave big discounts for anybody who replaced their GN7 with another Samsung device.
Uh... you're comparing a brand new feature release model to a year-old bug-fix release. Its initial sales, despite better availability, were slower according to several analysts. A couple of analysts say that they were comparable or slightly better. Either way, a new phone release should be comparable to the iPhone 6, and all the reports I've read say that it isn't even in the same league.
Of course, we'll never know for sure, because Apple conveniently stopped reporting their per-model sales numbers. Companies don't generally stop reporting numbers if they're good news, which leads me to believe that iPhone 7 is probably not selling nearly as well as hoped.
That might be true for U.S. sales, but according to Gartner group, worldwide iOS sales were down by over 7% year-over-year at last check, verging on single-digit percentage territory. That's a level that Apple hasn't enjoyed since the original iPhone. Fortune is slightly less pessimistic, but even they aren't predicting growth.
Hater? Hardly. I own an iPhone 6s and a Retina MacBook Pro, I run my server infrastructure on Macs, and I worked for Apple for almost thirteen years. Most of the time, I'm the first to defend their product decisions. For me to say that they screwed up, they have to really screw up.