IE 10 cannot be uninstalled and is required to enable the new 'Metro'-style apps.
Thanks Captain Obvious, 'Metro' apps are HTML5-based so what did you think was going to happen? That they would have 2 separate rendering engines? What would be the point of that? So you turn IE10 off and you don't see it, then you install whatever browser you want for web browsing, what's wrong with that?
Wouldn't the Apple stuff be subject to something similar? Safari comes bundled too...
They do have significant market power, but whether that's enough to subject them to anti-trust laws is debatable. In the end it shouldn't really matter because these days you expect a web browser to be bundled with pretty much any consumer-oriented operating system and if you don't want to use that then you just install something else.
Are those first two items really possible? If so, I'll have my words a la mode, thanks - I really haven't tinkered with OS X in a while, and last time I did I couldn't even get focus-follows-mouse to work.
Of course they are, I'm not sure what would make you think otherwise given the basis of the system and the availability of kernel source.
As far as the battery changing issue goes, the point is I don't have (the level of) control with an OS X macbook that I do with a linux (non-mac) laptop, because I can't change out the battery without tools, which doesn't seem like an unrealistic requirement.
It's nothing to do with linux or with non-mac, for example the Acer S3 has a non-removable battery, as does the Dell Vostro v13, v130, etc... It's not an unrealistic requirement but if that is a requirement for you then you have to dodge more than just Apple laptops.
Switch out the window manager.
Re-compile the kernel.
What exactly is stopping you from doing those things?
And since this about "an OSX Macbook", not just OSX, replace the battery without using any tools.
That's not about control, that's just a design choice based on the chassis construction. Can you replace the battery? Yes. If your requirement is that you can't use tools to do it then obviously that's not the choice for you.
Why would they do that? They have a solid OS like Sony does that they likely would not re-write significantly for a new Xbox. They have a good setup now where it is easy to develop titles for both the PC and XBox, they have their 'Zune' (or whatever they are naming it) brand for music and movies, they've got licensing deals with major content providers for TV, they also have Kinect as the kind of 'alternative controller' wherever it is more suitable than a traditional controller, it's clearly in their interest to continue the way they are going. They've done the hard work - and spent the big money - in establishing a platform so now the next generation console is just a hardware improvement, unlike previous generations where the entire platform is traditionally changed and there is a massive cost involved.
Xbox 360 has 512 MB of RAM and integrated graphics. PS3 has 256 MB of RAM and 256 MB of dedicated VRAM. Why again doesn't the PS3 have enough RAM?
The OS is larger on the PS3 and it doesn't have an embedded frame buffer like the 360 has so that uses up memory as well. That memory on the PS3 is also dedicated whereas on the 360 it is shared so by reducing your use of main memory you can effectively increase your VRAM, on the PS3 main memory and VRAM are separate so even if you reduce your usage of one both are still stuck with 256MB each.
If that were true they wouldn't be able to port it to consoles.
Why not? The range of PC hardware that this will be playable on pretty much encompasses console hardware anyway.
The engine would be optimized for PC's and the polygon counts far too high for consoles' limited resources to handle.
Console hardware isn't that dissimilar to PC hardware and there's nothing to stop them from scaling back the polygon count - in fact todays tools make that extremely easy - and/or scaling down or optimizing shaders for console GPUs.
If you're playing single-player games, you want raw speed. If you're playing two-player console games, you want absolute smoothness between the threads.
What is this 'smoothness between threads'? What technical concept are you referring to? You always want to get your threads to run the ideal amount of time based on the time available, amount of threads and thread priority, this does not change between single and multi player and is a job taken care of by the scheduler.
Raw speed vs real-time (the two are not the same and are often mutually exclusive).
You always want the perception of realtime in gaming and you always want as many frames as possible - to keep it smooth - while the game pace keeps real time.
That's what I was thinking too, perhaps if we knew exactly why an OSX Macbook was unsuitable this would be easier, based on all of the listed requirements that seems like the ideal choice. Like is there any specific reason for GNU/Linux?
That would be like me asking you to specifically state exactly why Android needs a 16 GB build environment.
Well you claim to be able to cut that usage to 50% so you must know some specifics surely, that's a big claim if you know nothing about it.
What I have stated is not that they are doing it wrong but the fact that if it truly requires 16 GB to build reasonably then they can probably do a better job of organizing the source and/or build environment. Considering most projects, even larger than Android, build fine with far less resources I don't think that's too much of a stretch.
You don't need 16GB to build it, you just need that much to build all the targets in ~25mins, i thought that was pretty clear.
I'll meet you half way, say instead of a 16 GB or a 640K environment we use an 8 GB build environment?
Of course you could use 8GB, it would just take longer as either the data would have to be swapped to disk or you would end up running less parallel processes.
Nothing arbitrary about it, deliberate would be a better word to use.
Ok then, if it isn't just a baseless suggestion then how is it specifically that you would re-organize the Android project to achieve a no-compromise solution wrt RAM utilization and compilation time? You clearly think they're doing it wrong so what would you do differently?
The downside is that I don't trust MS not to abuse the feature to make it harder to load other operating systems on your machine.
MS only controls the operating system, not the UEFI options, that is controlled by the motherboard manufacturers and OEMs. If MS actually wanted to prevent other OSes from being loaded onto systems shipped by their OEM partners and could manage to convince those manufacturers to go along with it they would have done so long ago. UEFI doesn't change anything in that respect.
Organize the project better, and you won't have to make that decision or compromise.
Yes of course, if you arbitrarily 'organize it better' you'll be able to build it instantly on 640k of RAM too, how? You know, just 'organize it better'.
My "smart" answer would be not much more than the host operating system itself needs.
And just thrash your HDD, yeah you could do that in fact you could do that with everything and never need much more RAM than the host operating system, it would of course be extremely slow.
However, yes, RAM can affect the number of parallel compiles
Well no, in this case the amount of RAM required is affected by the number of parallel builds.
but I think its safe to say in this case we are not optimally limiting the number of symbols and objects that the compiler needs to work at any given time.
Conserve RAM or conserve time? I think the latter given the nature of the task.
I can't think of any good reason that it would take 16 GB to compile anything.
Well how much RAM would you think should be needed to compile Android? If you're taking 5 hours of CPU time to ~25mins wall time then obviously your parallel compiles are going to be chewing up a lot of RAM. If you reduced the amount of parallel builds it would reduce the amount of RAM required - and also take a lot longer.
Agreed. For only $11,899 you too could own Visual Studio 2010 Ultimate. Either that, or you could pay your rent, buy a nice boat, or a decent car.
Except, if you read the link you posted, that's for a full MSDN subscription that includes multiple licenses to all their operating systems, all their office applications, virtualization, dynamics, small business, expression suites, all their developer tools, all of their servers (exchange, sharepoint, lync, biztalk, sql, etc...) and a lot of other software, not just VS2010 ultimate.
And it will soon be mandatory for employers to take the student debt repayments from your salary before paying you. I expect the U.S. will probably enact similar laws to preserve the system.
And that's a great way of doing it. We have that system in Australia, once you earn a bit over minimum wage (can't remember how much) you start paying a small percentage of your wage off your student debt, it comes out of your pay with your tax (PAYG) and that percentage goes up the more you earn (i think it's capped at about 8% or something). That way if you're making enough money to live you're paying off your loan and it's a percentage of what you earn, if you're not making money you're not paying it off and it only accumulates a very small amount of interest (it might just be CPI, not sure).
Or until you leave the country. I know a couple that intends to leave for Romania as soon as they graduate. They'll have accumulated a little shy of 1 million dollars in student loans.
Clearly you do given the simple fact that you dismally failed to comprehend what was clearly written: In fact they would be no higher than supporting multiple android devices and versions which they are already having to do anyway
To which you've replied: The costs are of course higher for supporting both QNX and Android. I'm not going to bother explaining that perfectly obvious point. But your contesting it shows that you're not being realistic
So, anyone who has basic reading comprehension skills would be able to see that i agreed that they would be higher, however they would be the same (or 'no higher than') as the scenario with them going Android where multiple devices and OS versions would have to be supported anyway. It's pretty clear, not difficult to understand. For someone who claims to have experience you seem extremely ignorant of the simple fact that on android you do need to support multiple versions and multiple devices and doing so has a cost.
Rubbish, multiple versions of the OS across multiple device hardware configurations, or are you unclear on the meaning of 'fragmented'?
But QNX + a limited Android runtime is clearly fragmented: some apps are Android, some Android apps won't run, and some apps are QNX and work different from the runnable Android apps.
That's not fragmentation, you target QNX native or the Android runtime and it runs on all of the QNX devices.
And not all devices run Android apps at all. That's fragmented.
And not all android devices run all android apps, in fact not all devices on the same version of android run all the same apps because of the differences in hardware, that's fragmented.
The costs are of course higher for supporting both QNX and Android. I'm not going to bother explaining that perfectly obvious point. But your contesting it shows that you're not being realistic, you're looking for arguments to support a preconceived decision.
No, it shows you have a reading comprehension problem. Of course the cost for supporting them is higher, but no higher than supporting multiple different hardware configurations on multiple versions of android, the Android runtime on a QNX device is simply another version of android on another hardware configuration, very very simple, not sure how you're having so much trouble understanding it.
The other side of that is "why not just do something different". The reasons to do what others are doing, when it's working, are better than the reasons to do something different.
Their market is the corporate market so building on a rock-solid OS like QNX as opposed to just taking the existing consumer offering of Android is clearly more beneficial.
They've already tapped into that community to a degree.
But not really. And their costs are higher for supporting both.
How do you figure? In fact they would be no higher than supporting multiple android devices and versions which they are already having to do anyway because of the nature of android, it's pretty obvious if you've actually developed for android why this is the case.
Without getting much, if anything, of benefit from it. But getting drawbacks, like a fragmented platform and incomplete coverage of the more popular platform.
The fragmented platform is Android, you already need to support multiple devices and versions so supporting an Android BB would be no different to supporting a QNX BB with the Android BB runtime.
Slashdot Mirror
IE 10 cannot be uninstalled and is required to enable the new 'Metro'-style apps.
Thanks Captain Obvious, 'Metro' apps are HTML5-based so what did you think was going to happen? That they would have 2 separate rendering engines? What would be the point of that? So you turn IE10 off and you don't see it, then you install whatever browser you want for web browsing, what's wrong with that?
Wouldn't the Apple stuff be subject to something similar? Safari comes bundled too ...
They do have significant market power, but whether that's enough to subject them to anti-trust laws is debatable. In the end it shouldn't really matter because these days you expect a web browser to be bundled with pretty much any consumer-oriented operating system and if you don't want to use that then you just install something else.
Only reason I went to windows 7 was because Xp won't recognize more than 4Gb or memory.
XP 64bit did that fine.
Are those first two items really possible? If so, I'll have my words a la mode, thanks - I really haven't tinkered with OS X in a while, and last time I did I couldn't even get focus-follows-mouse to work.
Of course they are, I'm not sure what would make you think otherwise given the basis of the system and the availability of kernel source.
As far as the battery changing issue goes, the point is I don't have (the level of) control with an OS X macbook that I do with a linux (non-mac) laptop, because I can't change out the battery without tools, which doesn't seem like an unrealistic requirement.
It's nothing to do with linux or with non-mac, for example the Acer S3 has a non-removable battery, as does the Dell Vostro v13, v130, etc... It's not an unrealistic requirement but if that is a requirement for you then you have to dodge more than just Apple laptops.
Switch out the window manager.
Re-compile the kernel.
What exactly is stopping you from doing those things?
And since this about "an OSX Macbook", not just OSX, replace the battery without using any tools.
That's not about control, that's just a design choice based on the chassis construction. Can you replace the battery? Yes. If your requirement is that you can't use tools to do it then obviously that's not the choice for you.
Control.
What don't you have control over on OSX?
MS will likely copy Nintendo with the next Xbox.
Why would they do that? They have a solid OS like Sony does that they likely would not re-write significantly for a new Xbox. They have a good setup now where it is easy to develop titles for both the PC and XBox, they have their 'Zune' (or whatever they are naming it) brand for music and movies, they've got licensing deals with major content providers for TV, they also have Kinect as the kind of 'alternative controller' wherever it is more suitable than a traditional controller, it's clearly in their interest to continue the way they are going. They've done the hard work - and spent the big money - in establishing a platform so now the next generation console is just a hardware improvement, unlike previous generations where the entire platform is traditionally changed and there is a massive cost involved.
Xbox 360 has 512 MB of RAM and integrated graphics. PS3 has 256 MB of RAM and 256 MB of dedicated VRAM. Why again doesn't the PS3 have enough RAM?
The OS is larger on the PS3 and it doesn't have an embedded frame buffer like the 360 has so that uses up memory as well. That memory on the PS3 is also dedicated whereas on the 360 it is shared so by reducing your use of main memory you can effectively increase your VRAM, on the PS3 main memory and VRAM are separate so even if you reduce your usage of one both are still stuck with 256MB each.
If that were true they wouldn't be able to port it to consoles.
Why not? The range of PC hardware that this will be playable on pretty much encompasses console hardware anyway.
The engine would be optimized for PC's and the polygon counts far too high for consoles' limited resources to handle.
Console hardware isn't that dissimilar to PC hardware and there's nothing to stop them from scaling back the polygon count - in fact todays tools make that extremely easy - and/or scaling down or optimizing shaders for console GPUs.
If you're playing single-player games, you want raw speed. If you're playing two-player console games, you want absolute smoothness between the threads.
What is this 'smoothness between threads'? What technical concept are you referring to? You always want to get your threads to run the ideal amount of time based on the time available, amount of threads and thread priority, this does not change between single and multi player and is a job taken care of by the scheduler.
Raw speed vs real-time (the two are not the same and are often mutually exclusive).
You always want the perception of realtime in gaming and you always want as many frames as possible - to keep it smooth - while the game pace keeps real time.
he wants to fit in with the cool gang at Slashdot
also,
IT"S THE YEAR OF THE LINUX DESKTOP
yeah but he wants a linux laptop ;)
That's what I was thinking too, perhaps if we knew exactly why an OSX Macbook was unsuitable this would be easier, based on all of the listed requirements that seems like the ideal choice. Like is there any specific reason for GNU/Linux?
That would be like me asking you to specifically state exactly why Android needs a 16 GB build environment.
Well you claim to be able to cut that usage to 50% so you must know some specifics surely, that's a big claim if you know nothing about it.
What I have stated is not that they are doing it wrong but the fact that if it truly requires 16 GB to build reasonably then they can probably do a better job of organizing the source and/or build environment. Considering most projects, even larger than Android, build fine with far less resources I don't think that's too much of a stretch.
You don't need 16GB to build it, you just need that much to build all the targets in ~25mins, i thought that was pretty clear.
I'll meet you half way, say instead of a 16 GB or a 640K environment we use an 8 GB build environment?
Of course you could use 8GB, it would just take longer as either the data would have to be swapped to disk or you would end up running less parallel processes.
Nothing arbitrary about it, deliberate would be a better word to use.
Ok then, if it isn't just a baseless suggestion then how is it specifically that you would re-organize the Android project to achieve a no-compromise solution wrt RAM utilization and compilation time? You clearly think they're doing it wrong so what would you do differently?
The downside is that I don't trust MS not to abuse the feature to make it harder to load other operating systems on your machine.
MS only controls the operating system, not the UEFI options, that is controlled by the motherboard manufacturers and OEMs. If MS actually wanted to prevent other OSes from being loaded onto systems shipped by their OEM partners and could manage to convince those manufacturers to go along with it they would have done so long ago. UEFI doesn't change anything in that respect.
Organize the project better, and you won't have to make that decision or compromise.
Yes of course, if you arbitrarily 'organize it better' you'll be able to build it instantly on 640k of RAM too, how? You know, just 'organize it better'.
My "smart" answer would be not much more than the host operating system itself needs.
And just thrash your HDD, yeah you could do that in fact you could do that with everything and never need much more RAM than the host operating system, it would of course be extremely slow.
However, yes, RAM can affect the number of parallel compiles
Well no, in this case the amount of RAM required is affected by the number of parallel builds.
but I think its safe to say in this case we are not optimally limiting the number of symbols and objects that the compiler needs to work at any given time.
Conserve RAM or conserve time? I think the latter given the nature of the task.
I can't think of any good reason that it would take 16 GB to compile anything.
Well how much RAM would you think should be needed to compile Android? If you're taking 5 hours of CPU time to ~25mins wall time then obviously your parallel compiles are going to be chewing up a lot of RAM. If you reduced the amount of parallel builds it would reduce the amount of RAM required - and also take a lot longer.
Agreed. For only $11,899 you too could own Visual Studio 2010 Ultimate. Either that, or you could pay your rent, buy a nice boat, or a decent car.
Except, if you read the link you posted, that's for a full MSDN subscription that includes multiple licenses to all their operating systems, all their office applications, virtualization, dynamics, small business, expression suites, all their developer tools, all of their servers (exchange, sharepoint, lync, biztalk, sql, etc...) and a lot of other software, not just VS2010 ultimate.
This is the reason why gcc (or any other compiler) should never be installed on any production Linux machine.
So anything that uses JIT is out then?
And it will soon be mandatory for employers to take the student debt repayments from your salary before paying you. I expect the U.S. will probably enact similar laws to preserve the system.
And that's a great way of doing it. We have that system in Australia, once you earn a bit over minimum wage (can't remember how much) you start paying a small percentage of your wage off your student debt, it comes out of your pay with your tax (PAYG) and that percentage goes up the more you earn (i think it's capped at about 8% or something). That way if you're making enough money to live you're paying off your loan and it's a percentage of what you earn, if you're not making money you're not paying it off and it only accumulates a very small amount of interest (it might just be CPI, not sure).
Or until you leave the country. I know a couple that intends to leave for Romania as soon as they graduate. They'll have accumulated a little shy of 1 million dollars in student loans.
Real quality citizens.
I don't have any reading comp problem.
Clearly you do given the simple fact that you dismally failed to comprehend what was clearly written:
In fact they would be no higher than supporting multiple android devices and versions which they are already having to do anyway
To which you've replied:
The costs are of course higher for supporting both QNX and Android. I'm not going to bother explaining that perfectly obvious point. But your contesting it shows that you're not being realistic
So, anyone who has basic reading comprehension skills would be able to see that i agreed that they would be higher, however they would be the same (or 'no higher than') as the scenario with them going Android where multiple devices and OS versions would have to be supported anyway. It's pretty clear, not difficult to understand. For someone who claims to have experience you seem extremely ignorant of the simple fact that on android you do need to support multiple versions and multiple devices and doing so has a cost.
Android is not fragmented for a given carrier
Rubbish, multiple versions of the OS across multiple device hardware configurations, or are you unclear on the meaning of 'fragmented'?
But QNX + a limited Android runtime is clearly fragmented: some apps are Android, some Android apps won't run, and some apps are QNX and work different from the runnable Android apps.
That's not fragmentation, you target QNX native or the Android runtime and it runs on all of the QNX devices.
And not all devices run Android apps at all. That's fragmented.
And not all android devices run all android apps, in fact not all devices on the same version of android run all the same apps because of the differences in hardware, that's fragmented.
The costs are of course higher for supporting both QNX and Android. I'm not going to bother explaining that perfectly obvious point. But your contesting it shows that you're not being realistic, you're looking for arguments to support a preconceived decision.
No, it shows you have a reading comprehension problem. Of course the cost for supporting them is higher, but no higher than supporting multiple different hardware configurations on multiple versions of android, the Android runtime on a QNX device is simply another version of android on another hardware configuration, very very simple, not sure how you're having so much trouble understanding it.
The other side of that is "why not just do something different". The reasons to do what others are doing, when it's working, are better than the reasons to do something different.
Their market is the corporate market so building on a rock-solid OS like QNX as opposed to just taking the existing consumer offering of Android is clearly more beneficial.
But not really. And their costs are higher for supporting both.
How do you figure? In fact they would be no higher than supporting multiple android devices and versions which they are already having to do anyway because of the nature of android, it's pretty obvious if you've actually developed for android why this is the case.
Without getting much, if anything, of benefit from it. But getting drawbacks, like a fragmented platform and incomplete coverage of the more popular platform.
The fragmented platform is Android, you already need to support multiple devices and versions so supporting an Android BB would be no different to supporting a QNX BB with the Android BB runtime.