Earlier quoted context omitted.
Microsoft needs to keep building their own hardware because 3rd party manufacturers are doing to Microsoft's brand what Mac clones did to Apple in the early 90s. The Surface is absolutely gorgeous. If they softened the edges on the tablet portion it would be on my list of greatest pieces of tech hardware ever made. I would love to see MS try to build its own 'Yoga' type laptop...provided I can still install Linux on…
> provided I can still install Linux on it. The chance that that happens, is abut the as Microsoft giving the physical devices out for free. Lock-in is the common way today to get market control.
Why Does Windows Have Terrible Battery Life?
281–290 of 329 posts
Re: Why Does Windows Have Terrible Battery Life?
#282Earlier quoted context omitted.
But that's the thing. They did create the hardware, and it isn't even the first generation, and it still performs poorly. The problem isn't the hardware. It's the software. So either Microsoft makes a new OS from scratch that only works on their hardware, or this problem won't be fixed anytime soon, either way.
imagine owning a race car team. For years you buy cars from Ferrari. Finally, you're forced to make your own. While in 5 years you will certainly have a better understanding of the car, V1 of your new product will certainly be a bit inferior.
This is exactly how Lamborghini got started.
Re: Why Does Windows Have Terrible Battery Life?
#283When you aren't creating the hardware, it is harder to care about power management in the software because that is seen as "someone else's problem". It is easy to blame things on terrible drivers or whatever, but no matter how you look at it, the product is worse as a result. This is why Microsoft needs to keep building their own hardware like the Surface. As time goes on, if Microsoft does it right, Surface is going…
Why do you think this is about the hardware at all? Most of the savings are down to software (try Windows or Linux on the Macbook Air). It requires lots of hard work to change the kernel to make better use of sleep state and to reduce CPU utilisation in apps.
The reality is that Apple cares about battery life, because they know users do, they work constantly on this. Numerous Apple announcements talk up battery life improvements, they are clearly very aware of this issue.
I've never got the impression that that Microsoft does care very much about this issue, in fact their kernel doesn't even sound like it gets much development in the core functions (it's all about fixing bugs and adding features).
Re: Why Does Windows Have Terrible Battery Life?
#284Earlier quoted context omitted.
I seriously doubt it's x86 baggage. You don't pay a battery life penalty for code you don't execute.
While you don't use the battery for code you don't execute, when your code is finely tuned to a single machine (as in CPU + auxiliary chips) architecture rather than able to run on a wider choice of hardware, you may be able to squeeze some extra juice from your battery.
Except MacOS X ships fat binaries for multiple CPU architectures and uses a kernel originally designed in the 1980's for an m68k machine.
Re: Why Does Windows Have Terrible Battery Life?
#285I think the article is asking the wrong question. A better question is: why does Apple (OSX/iOS) have such awesome battery life? After all, it wasn't always this good, or rather, it's been improving by leaps and bounds, both with new hardware and with new OS versions.
I think the answer is that Apple really, really cares and has been extremely focused on power/performance for a number of years. It has the focus, the institutional awareness and know-how that's been built up since around Tiger, and last not least the people on their performance teams.
That's how you get great battery life.
Re: Why Does Windows Have Terrible Battery Life?
#286Earlier quoted context omitted.
I put servers in quotes to denote something that serves that wasn't purpose built for the role. Nothing more, the context from justincormack wasn't lost but there are a lot of uses for osx servers, for example compile farms. What I was referring to, which I thought was apparent but failed to convey, is that this perception of nobody doing it is a fallacy.
We are saying the same thing. My post wasn't meant to contradict yours, just clarify. > What I was referring to, which I thought was apparent but failed to convey, is that this perception of nobody doing it is a fallacy. I just think that in this context the "nobody" you are referring to and the "nobody" he is referring to are not equal sets. Yours is a superset of his, which is why both statements are true (in spiri…
True enough, think its been a long day for me then. Sorry for the confusion on my end.
I do believe that means it is beer o clock time. Cheers and no worries mate.
Re: Why Does Windows Have Terrible Battery Life?
#287Earlier quoted context omitted.
I already told you why not. Because anything that gives the Surface an advantage has that antitrust lawsuit smell. > Hyperbole much? Again, no. Any move to give preferential treatment to MS's own hardware is the push the OEMs need to convert their Windows Tablet initiative into an Android Tablet one. Not to mention having potential ripple effects in unrelated businesses lines like spooking HP into doing more Linux se…
>I already told you why not. Because anything that gives the Surface an advantage has that antitrust lawsuit smell. Who says it needs to be Surface only? Who says it needs to be limited to Microsoft hardware? If the changes need to be in the driver or hardware layer, all Microsoft needs to do is release specs and then setup a certifying service for OEMs. Something like "Battery Optimized" cert that the partner can th…
> all Microsoft needs to do is release specs and then setup a certifying service for OEMs
So this exists. It's called the Windows Logo Program for Hardware. The reason we are reading this article is that it failed to do the job.
What you seem not to be understanding is that in order to "match Apple hardware in battery life" one also has to "match Apple hardware" in the small number of distinct hardware configurations sold per year.
Taking that hardware configuration and calling it "a standard" doesn't actually do anything. If your standard is broad enough to support 100 hardware configurations, battery life will be poor. If your standard is narrow enough to only support 2 hardware configurations, OEMs will not build it, because Dell has no way to differentiate itself from Toshiba.
To match Apple, Microsoft needs to cut back to maybe 3 models of Windows tablets per year. You can make that into a standard if you like, but no OEM will ever adopt it. They will all (correctly) point out that such a standard is designed for Microsoft's hardware team to implement and to hell with all the third parties.
Re: Why Does Windows Have Terrible Battery Life?
#288Earlier quoted context omitted.
While you don't use the battery for code you don't execute, when your code is finely tuned to a single machine (as in CPU + auxiliary chips) architecture rather than able to run on a wider choice of hardware, you may be able to squeeze some extra juice from your battery.
Except MacOS X ships fat binaries for multiple CPU architectures and uses a kernel originally designed in the 1980's for an m68k machine.
Shipping fat binaries with different versions for every different Atom/Core/Xeon/FX/Phenom/Opteron Intel/AMD/Nvidia + chipset glue combination would be quite a feat.
This could go well beyond what compiling every package for your specific machine can do.
Re: Why Does Windows Have Terrible Battery Life?
#289Earlier quoted context omitted.
> provided I can still install Linux on it. The chance that that happens, is abut the as Microsoft giving the physical devices out for free. Lock-in is the common way today to get market control.
Here you go: http://www.geek.com/microsoft/how-to-install-ubuntu-on-the-s...
The Pro is just another PC. I'd like to see the ARM-based Surface running Linux.
Re: Why Does Windows Have Terrible Battery Life?
#290Windows and Linux are general purpose OSes. The same kernel runs on high throughput servers and low power tablets. The apps are written with little focus on battery life. The drivers too. Microsoft doesn't write their own drivers and then there's firmware too. It's the one area where Apple has really taken advantage of the vertical integration - they do everything from firmware to most apps people use. But both Windo…
>Windows and Linux are general purpose OSes. The same kernel runs on high throughput servers and low power tablets. The apps are written with little focus on battery life. What are you saying? That Microsoft can't build a consumer OS with great power-management because the kernel also needs to work on high throughput servers? Come on. >But both Windows and Linux are more than capable to get this all sorted. Bingo. So…
My bet: backwards compatibility. Better power management requires changes in behaviour of the OS and it is very hard to change behaviour without breaking things.
Suppose the USB sleep state handling code is suboptimal. Is that because programmers paid less attention to power usage a decade ago, or because some devices implement a power state incorrectly? If the latter, which devices? If Microsoft isn't 100% sure they know of all devices for which it is needed, they may choose to leave the less efficient code in place regardless of whether a deficient device is plugged in.
An example might be a pet peeve I have with Windows: its tendency to 'discover new hardware' when one plugs a bog standard mouse or keyboard into a USB port for the umpteenth time. That in itself is baffling, but it can take Windows half a minute or so to figure out that it has a driver for the device and start it. I do not have the faintest idea what it does in that time, but it must be unavoidable within the constraints microsoft sets itself, since it hasn't been fixed in a decade or so (but it has been improved quite a bit) and I bet it must have itched quite a few engineers.
Whatever the cause, plugging in a USB mouse must use way more power on Windiws than on a Mac.