Bill stop it. You are a regular here. You know from these threads that Apple charges $199 for a battery for the rMBP. You won't have to throw anything out.
The current is Xcode 4.3 XCode 4.4 beta is designed for Mountain Lion requires OS X 10.7.4 I believe that will be true through release. Xcode 4.5 beta is needed for iOS 6 and at least now doesn't run on Mountain Lion. Probably though the later versions will require it.
What do you mean worse than Microsoft? Microsoft is excellent on supporting old software and hardware. Apple has always been an aggressive upgrader of systems. There is no change in attitude here.
That's not quire fair. With Apple you have to be careful with upgrades and check. Sometimes they are quire reasonable, sometimes they are super expensive.
As a Mac user since 10.1 I gotta agree that's nuts. Excluding the whole Windows-8 move... Microsoft is excellent about supporting old hardware and software. Second only to the big systems guys like Dec (broke), Sun (broke) and IBM (charges a ton). Apple OTOH moves their whole infrastructure quickly:
2001 entire OS rewrite. 2005 changed CPU type 2007 dropped support for all classic applications 2011 dropped support for all PPC appellations
I own both the iPad 3 and the retina and the GP is right. More so on the retina than the iPad. Though 10.8 fixes a good bit of the issue with a more complex graphics subsystem.
And Apple's working to change it back to the old system where people upgraded. Consider their latest: >200 ppi, all SSD running at 450mb/sec, 16g ram, quad core (and fast)... The days of lagging hardware are coming to an end in the Apple world. And BTW Windows 8 is trying to bring that to the Microsoft consumer community as well.
I was running 10.6 until a month ago, because I didn't want to lose Rosetta and could live without 10.7. I'd say you are good for about 8 mo after a new OS and then things start to get slightly more painful. But it was never horrible or I wouldn't have ended up waiting. For example I wanted iCloud but iWork (iWorks syncing service built in, which might even have been better) still worked until I got my new machine.
The GPUs are exactly the reason Apple isn't supporting these older machines. Apple has a new graphical subsystem in 10.8 designed for retinas which is increasing the complexity of CPU/GPU communication. The older GPUs can't run the new graphical subsystem. So no they can't handle it.
Just to support that. The people who bought PPC computers in 06 were doing so to run legacy software, not infrequently 10.4 with the classic box or to take advantage of the G5s (the switch to Intel really was a downgrade for desktops).
Apple keeps updating the OS aggressively during the first 3 mo after the new OS comes out and then more slowly for another 9+ months. They offer security patches well beyond that. I have an old 12" g4, running 10.4 which got a security patch in 2011.
That being said though, Apple offers the advantage of moving their platform aggressively. While Apple equipment will last, you won't be on the latest and greatest after your first year. Just like it was in the 80's and 90's when technology improved rapidly.
Remember we are talking a phone here. But to be honest on my desktop I'd still want front task to be able to get 100% of CPU. The compile can wait until the Lady Gaga video, or whatever, is done rendering. Though even better for a desktop would be defaulting to that order and allowing me to set a background task as higher priority (something like Unix nice).
Where I wouldn't want that behavior is on a server where I'd want to wait rather than mess up potentially hundreds or thousands of other end users. And that was my original point. Desktops and now phones are using server kernels.
You gotta still work on the scheduler. The RTOS makes it possible but that's only the first step. Haven't used a Nokia in about 8 years so not talking from experience with Nokia though I have used RTOSes including a much earlier version of QNX.
I own the iPhone 4s and use it every day. I own the new Macbook Pro retina with 4 CPUs and 8 execution threads each one fast. I get lag on both. So using your very example no their kernel isn't holding up.
Of course RTOS are lower performance. The goal of an RTOS is to trade performance for responsiveness. The system feels zippy even if i actual worked performed is lower. That's the tradeoff. Most people vastly prefer 90% of things to be instantaneous even if the hardest 10% take 30% longer.
In terms of swapping an RTOS or a traditional scheduler are equally bad if one task is using close to 100% ram. There it doesn't matter. The gain is only when there are say 1/2 dozen tasks each one wanting 25%.
In terms of nothing being left, that's fine. If the front task gets 100% that's fine for any desktop / phone OS.
You are at 100% CPU and RAM usage. The user tries to do something that needs more CPU. Do you drop the old task, which is no good he needs that done, or the new task which cannot complete in time?
You schedule it this way.
1) The user always has a high degree of responsiveness. The system never lets itself get to 100% CPU and RAM unless the user hasn't been hitting anything for while. 2) The task the user is currently looking at gets priority and all the CPU and RAM it needs 3) Other tasks split up the remaining generally using something like a most recently used bias. Their may be a notification when a large task in the background completes.
RTOS don't magically create more CPU, they may even effectively decrease it, but that's not the point. What they do is make sure the system is always responsive to the user regardless of load. And absolutely things like postponing tasks are key.
Great post lots of content. I looked into your argument about the history of F# regarding Haskell (Haskell is one of my primary languages) and I don't see any comments to that effect. Lots of the big Haskell people work for Microsoft. There still are active projects to port Haskell to.NET but the issue was always clear that the type system in.NET isn't robust enough. There is still a lot of work in bringing ideas from Haskell into.NET, or whatever Microsoft's next compiler will be.
F# gets around that by limiting the scope of type manipulations which is easier because:
a) F#/OCaml isn't pure so you don't have to constantly be using Monads b) F# uses more C#ish idioms.
The lack of type inferences... is crippling for Haskell and just bad for F#. So I mostly agree with what you are saying. If you want to say it is more like ML with the C#/Java object system on top... I can live with that.
As for X# you were right I was wrong. There was some overlap in people on both teams especially Erik Meijer.
As for Scala my point was that Scala took the market F# should have had. Not that Scala had influence inside Microsoft.
I was talking about QNX. Real time helps them because it makes the system much more responsive. Phones because of weak CPUs, network interference and limited memory often have noticeable lags. A real time kernel allows the phone to always be responsive to the end user while handling those tasks effectively.. It also allows for vastly more sophisticated power management which can result in much longer battery life.
And you are right desktop OSes don't use them. All the desktop OSes since the days of OS9 have been designed for servers. Which means they focus on throughput not responsiveness, and then adjusted for the desktop to some extent.
There are lots of software solutions for securing Android and remote management along with 2 major strategies. If you are serious in wanting to discuss a remote management solution and/or outsourcing remote management send me an email at jbolden AT BlueLotusSIDC DOT com
No what happened in his world what that key Blackberry strengths like message compression stopped being important because network speeds increased drastically. Additionally functionality that wouldn't have been possible with lower network speeds like video and extensive browsing became possible.
Slashdot Mirror
Bill stop it. You are a regular here. You know from these threads that Apple charges $199 for a battery for the rMBP. You won't have to throw anything out.
The current is Xcode 4.3
XCode 4.4 beta is designed for Mountain Lion requires OS X 10.7.4 I believe that will be true through release.
Xcode 4.5 beta is needed for iOS 6 and at least now doesn't run on Mountain Lion. Probably though the later versions will require it.
I agree with you and am upgrading to 10.8.0... new rMBP and I really want the graphics. I'll let you know how it goes.
What do you mean worse than Microsoft? Microsoft is excellent on supporting old software and hardware. Apple has always been an aggressive upgrader of systems. There is no change in attitude here.
That's not quire fair. With Apple you have to be careful with upgrades and check. Sometimes they are quire reasonable, sometimes they are super expensive.
Vista was released in 2007. The only people who should have been buying XP after that point were:
a) Enterprise customers on enterprise upgrades
b) People buying used boxes
c) People buying netbooks.
It wouldn't shock me if Microsoft is still selling DOS systems somewhere. That doesn't mean they have to continue to support the OS.
As a Mac user since 10.1 I gotta agree that's nuts. Excluding the whole Windows-8 move... Microsoft is excellent about supporting old hardware and software. Second only to the big systems guys like Dec (broke), Sun (broke) and IBM (charges a ton). Apple OTOH moves their whole infrastructure quickly:
2001 entire OS rewrite.
2005 changed CPU type
2007 dropped support for all classic applications
2011 dropped support for all PPC appellations
I own both the iPad 3 and the retina and the GP is right. More so on the retina than the iPad. Though 10.8 fixes a good bit of the issue with a more complex graphics subsystem.
Which BTW is precisely the reason Apple is changing out the graphical subsystem in 10.8 and that requires dropping some of the lower end GPUs and...
The equivalent is Microsoft. And yeah people bitched here when Microsoft forced upgrades. They just haven't done it much in the last decade.
And Apple's working to change it back to the old system where people upgraded. Consider their latest: >200 ppi, all SSD running at 450mb/sec, 16g ram, quad core (and fast)... The days of lagging hardware are coming to an end in the Apple world. And BTW Windows 8 is trying to bring that to the Microsoft consumer community as well.
I was running 10.6 until a month ago, because I didn't want to lose Rosetta and could live without 10.7. I'd say you are good for about 8 mo after a new OS and then things start to get slightly more painful. But it was never horrible or I wouldn't have ended up waiting. For example I wanted iCloud but iWork (iWorks syncing service built in, which might even have been better) still worked until I got my new machine.
Why is it unacceptable. What do you want to do that you can't do with Lion?
The GPUs are exactly the reason Apple isn't supporting these older machines. Apple has a new graphical subsystem in 10.8 designed for retinas which is increasing the complexity of CPU/GPU communication. The older GPUs can't run the new graphical subsystem. So no they can't handle it.
Just to support that. The people who bought PPC computers in 06 were doing so to run legacy software, not infrequently 10.4 with the classic box or to take advantage of the G5s (the switch to Intel really was a downgrade for desktops).
Apple keeps updating the OS aggressively during the first 3 mo after the new OS comes out and then more slowly for another 9+ months. They offer security patches well beyond that. I have an old 12" g4, running 10.4 which got a security patch in 2011.
That being said though, Apple offers the advantage of moving their platform aggressively. While Apple equipment will last, you won't be on the latest and greatest after your first year. Just like it was in the 80's and 90's when technology improved rapidly.
Remember we are talking a phone here. But to be honest on my desktop I'd still want front task to be able to get 100% of CPU. The compile can wait until the Lady Gaga video, or whatever, is done rendering. Though even better for a desktop would be defaulting to that order and allowing me to set a background task as higher priority (something like Unix nice).
Where I wouldn't want that behavior is on a server where I'd want to wait rather than mess up potentially hundreds or thousands of other end users. And that was my original point. Desktops and now phones are using server kernels.
You gotta still work on the scheduler. The RTOS makes it possible but that's only the first step. Haven't used a Nokia in about 8 years so not talking from experience with Nokia though I have used RTOSes including a much earlier version of QNX.
I own the iPhone 4s and use it every day. I own the new Macbook Pro retina with 4 CPUs and 8 execution threads each one fast. I get lag on both. So using your very example no their kernel isn't holding up.
1-3 were meant as a group.
As for your responses:
Of course RTOS are lower performance. The goal of an RTOS is to trade performance for responsiveness. The system feels zippy even if i actual worked performed is lower. That's the tradeoff. Most people vastly prefer 90% of things to be instantaneous even if the hardest 10% take 30% longer.
In terms of swapping an RTOS or a traditional scheduler are equally bad if one task is using close to 100% ram. There it doesn't matter. The gain is only when there are say 1/2 dozen tasks each one wanting 25%.
In terms of nothing being left, that's fine. If the front task gets 100% that's fine for any desktop / phone OS.
You are at 100% CPU and RAM usage. The user tries to do something that needs more CPU. Do you drop the old task, which is no good he needs that done, or the new task which cannot complete in time?
You schedule it this way.
1) The user always has a high degree of responsiveness. The system never lets itself get to 100% CPU and RAM unless the user hasn't been hitting anything for while.
2) The task the user is currently looking at gets priority and all the CPU and RAM it needs
3) Other tasks split up the remaining generally using something like a most recently used bias. Their may be a notification when a large task in the background completes.
RTOS don't magically create more CPU, they may even effectively decrease it, but that's not the point. What they do is make sure the system is always responsive to the user regardless of load. And absolutely things like postponing tasks are key.
Great post lots of content. I looked into your argument about the history of F# regarding Haskell (Haskell is one of my primary languages) and I don't see any comments to that effect. Lots of the big Haskell people work for Microsoft. There still are active projects to port Haskell to .NET but the issue was always clear that the type system in .NET isn't robust enough. There is still a lot of work in bringing ideas from Haskell into .NET, or whatever Microsoft's next compiler will be.
F# gets around that by limiting the scope of type manipulations which is easier because:
a) F#/OCaml isn't pure so you don't have to constantly be using Monads
b) F# uses more C#ish idioms.
The lack of type inferences... is crippling for Haskell and just bad for F#. So I mostly agree with what you are saying. If you want to say it is more like ML with the C#/Java object system on top... I can live with that.
As for X# you were right I was wrong. There was some overlap in people on both teams especially Erik Meijer.
As for Scala my point was that Scala took the market F# should have had. Not that Scala had influence inside Microsoft.
I was talking about QNX. Real time helps them because it makes the system much more responsive. Phones because of weak CPUs, network interference and limited memory often have noticeable lags. A real time kernel allows the phone to always be responsive to the end user while handling those tasks effectively.. It also allows for vastly more sophisticated power management which can result in much longer battery life.
And you are right desktop OSes don't use them. All the desktop OSes since the days of OS9 have been designed for servers. Which means they focus on throughput not responsiveness, and then adjusted for the desktop to some extent.
There are lots of software solutions for securing Android and remote management along with 2 major strategies. If you are serious in wanting to discuss a remote management solution and/or outsourcing remote management send me an email at jbolden AT BlueLotusSIDC DOT com
No what happened in his world what that key Blackberry strengths like message compression stopped being important because network speeds increased drastically. Additionally functionality that wouldn't have been possible with lower network speeds like video and extensive browsing became possible.