See my post here. Firmware shouldn't be able to cause permanent damage to the hardware, and the user should be able to recover the device from a botched firmware upgrade (or a bad hack job), without a JTAG. Not ensuring those two things will cause problems for Apple, even if they can discourage people from trying to hack the iPhone.
Have you ever used a PDA or graphing calculator that required a JTAG to un-brick after a failed update? It's simply unacceptable in those markets. Why should Apple get away with it in the iPhone?
In addition to the Opera browser that has already been mentioned, I'd like to point out that ELinks has pretty good CSS support for a browser that doesn't even do graphics.
That's kind of the point. On a device like this, the bootloader and OS update code should be in ROM, not Flash. That's standard practice for most companies, but apparently Apple doesn't like having failsafe procedures for their stuff.
Smart is irrelevant. It's the morality of it. If you went out and bought an iPhone and didn't plan on using att, this is what you get. They clearly state that the iphone will only work on their network. If you decide to prove that wrong and mess up your phone why should Apple and/or the credit card companies exchange your money/replace your iphone? Because in the field of consumer electronics, software should never, ever be able to destroy the hardware. And because Apple knew full well that people would want to hack the iPhone, and they should have tried to make the system safely hackable, even if they didn't want any users doing it.
There certainly aren't any technical reasons to remove support for 32-bit, uniprocessor, or Altivec. After all, that's mature, stable, working code we're talking about. It isn't like Apple is having to devote many resources to making sure those things don't bit-rot. It's all low-level stuff, and very little of the code in the OS is affected by the presence or absence of support for those older architectures.
Also, SMP kernels run just fine on single-processor machines, and Altivec support is trivial when SSEx support is included with some abstraction.
So, you think the "give us the specs and we'll do the rest" bit is a fantasy? Has it occured to you that all those reverse-engineered drivers would have been done 100 times faster with specs, resulting in working drivers while the products were still fairly new?
Look at the resources the r300 and nouveau projects have. If the manufacturers simply dumped the specs on them, they would be able to produce high quality drivers quickly. Even without the specs, they've proven their abilities to make decent drivers the hard way. Or do you have some reason to believe that they wouldn't be significantly more productive with specs? Is there something magic about ATI's programmers that makes them vastly more productive with the same specs to work from?
3D hardware acceleration still works for my Voodoo 3 card years after 3dfx went bankrupt and got absorbed into NVidia. It has even gained some features since 3dfx disappeared. The specs are open, so the community keeps the code working.
In general, drivers that are open-source and included in the main distribution (be it the kernel, X, or whatever) don't bitrot, even if the manufacturer stops maintaining them. So what does it matter whether it was written by the community or started as a binary blob and got open-sourced by the manufacturer?
In the long run, I think you'll find that the kind of customer who won't trust a community-written open source driver to be very high quality won't be using Linux (or BSD or any other Unix) at all.
Congratulations. You've made the all-to-common, stupid mistake of equating UI look and feel. They are two very different things. Almost everything you listed could be preserved while still satisfying most customers by rolling the look back to something less gaudy.
However, most people would disagree that the feel of the UI is really any better, let alone worth the hassle of an upgrade and the requisite re-learning. And even if the mechanics of the UI are an improvement for you, it still doesn't deserve praise because of the vast number of obvious, easily fixed flaws.
When carbon fiber composites break, they tend to shatter. When aluminium is overly stressed, it dents or rips. The thing is that it takes a lot more force to break the carbon composite than to dent the aluminum enough to compromise its strength.
nice isn't all that's required for good gaming performance, but right now, it's the only way to exceed the performance from the default CFS and SD.
As for your comments about clean code: Cleaner code will be easier to maintain and thus more secure. A unified server/desktop kernel will allow desktops to benefit from optimizations made with servers in mind. This happens all the time, as desktops are constantly catching up with the servers that went before them.
Imagine where Linux desktop performance would be today if it weren't for the decade of SMP development that preceded the arrival of dual-core desktop processors. Now, in retrospect, would you say that it was worth it, given that none of the SMP code ever slowed down your UP kernels?
Forking the kernel is a complete waste of time when all that is necessary is for distros to use their own.config file when compiling their kernels. Desktop-oriented distros can, and do, tweak their kernel configurations to enable the optimizations the help the desktops most.
There are approximately 2 kernel configuration changes required to switch from a throughput-optimized system to a latency-optimized system. They work. Any questions?
Do any desktop users give a damn whether their games run faster due to a scheduler hack or a nice level boost? No.
So why not just let the desktop distros throw a nice command into their X init scripts? The resulting performance is the same, but the code stays cleaner and more maintainable.
I'm quite familiar with all the CFS vs. SD issues.
My point was that no forking or pluggable schedulers are necessary because all the important ideas, if not the actual code, from Con's SD (and more recently, Roman's RFS) have been incorporated into the mainline scheduler.
Forking would only be justified if the work done by the likes of Con and Roman wouldn't be accepted into the mainline kernel. Even though there code hasn't been merged, the kernel has undeniably benefitted from their design work (which is far more important than the actual implementation). Using pluggable schedulers would only be justified if the single scheduler were forced to incorporate some fundamental tradeoffs that weren't acceptable to all users. That obviously hasn't happened: CFS and SD are both better than the previous O(1) scheduler all-around. Neither scheduler sacrifices desktop performance for server performance, or vice versa.
You're missing the point. A pluggable scheduler is not necessary for desktop usage, because nobody (not even Con) has been able to come up with a scheduler that is significantly better than CFS for desktop usage, except by doing things that amount to hard-coded nice levels. All of the meaningful performance improvements have made it into the default scheduler.
Sure, linux kernel modules don't have any significant execution speed overhead, wheras darwin does because of excess context switches. The overhead I was referring to on linux was just that a modular kernel (with all the modules loaded) can take up more memory. If you know you will always need all your drivers (usually for server and embedded workloads), compiling in everything and leaving out loadable module support can cut down on your RAM usage (though this typically only matters for embedded systems).
Which algorithms are bottlenecking your desktop? Is it the I/O scheduler? You can swap between one of four choices, at runtime. Is it the CPU scheduler? If so, you're a liar. Nobody had produced repeatable benchmarks that show a significant shortcoming in CFS for desktop and gaming use. Is the memory allocator really bad for your workload? Try using the new SLUB allocator, instead of the older SLAB allocator. Is the system not as responsive as you want? Turn on forced preemption and set the tick speed to 1000Hz.
The linux kernel already does this, with modules that can be loaded and unloaded at runtime. Whole subsystems (things like SCSI and DRI) can be loaded on demand. You can also enable or disable kernel preemption at compile time, and you can swap out I/O schedulers at run-time.
However, the modular approach can have some overhead of its own (though not as much on linux as on darwin). If you really need a small kernel, you can actually disable loadable module support at compile-time, if you know exactly which drivers you need.
Have you got any examples where there is significant overhead that can't be removed with a make config but could be removed with a specific, less scalable algorithm that isn't available in the kernel source?
I'm pretty sure your comment is mostly BS. The vanilla kernel source includes a lot of configuration options for embedded systems. Low on RAM? Turn off CONFIG_BASE_FULL to use several smaller, slower data structures. Don't have swap space? Turn off things like CONFIG_SHMEM. Using uClibc? For now, you might as well throw out CONFIG_FUTEX as well.
Slashdot Mirror
See my post here. Firmware shouldn't be able to cause permanent damage to the hardware, and the user should be able to recover the device from a botched firmware upgrade (or a bad hack job), without a JTAG. Not ensuring those two things will cause problems for Apple, even if they can discourage people from trying to hack the iPhone.
Have you ever used a PDA or graphing calculator that required a JTAG to un-brick after a failed update? It's simply unacceptable in those markets. Why should Apple get away with it in the iPhone?
In addition to the Opera browser that has already been mentioned, I'd like to point out that ELinks has pretty good CSS support for a browser that doesn't even do graphics.
That's kind of the point. On a device like this, the bootloader and OS update code should be in ROM, not Flash. That's standard practice for most companies, but apparently Apple doesn't like having failsafe procedures for their stuff.
Perhaps. I tried to test it out, but the hard drive with the swapfile caught fire before Excel finished loading.
Why?
There certainly aren't any technical reasons to remove support for 32-bit, uniprocessor, or Altivec. After all, that's mature, stable, working code we're talking about. It isn't like Apple is having to devote many resources to making sure those things don't bit-rot. It's all low-level stuff, and very little of the code in the OS is affected by the presence or absence of support for those older architectures.
Also, SMP kernels run just fine on single-processor machines, and Altivec support is trivial when SSEx support is included with some abstraction.
... Goliath actually manages to kill David.
So, you think the "give us the specs and we'll do the rest" bit is a fantasy? Has it occured to you that all those reverse-engineered drivers would have been done 100 times faster with specs, resulting in working drivers while the products were still fairly new?
Look at the resources the r300 and nouveau projects have. If the manufacturers simply dumped the specs on them, they would be able to produce high quality drivers quickly. Even without the specs, they've proven their abilities to make decent drivers the hard way. Or do you have some reason to believe that they wouldn't be significantly more productive with specs? Is there something magic about ATI's programmers that makes them vastly more productive with the same specs to work from?
3D hardware acceleration still works for my Voodoo 3 card years after 3dfx went bankrupt and got absorbed into NVidia. It has even gained some features since 3dfx disappeared. The specs are open, so the community keeps the code working.
In general, drivers that are open-source and included in the main distribution (be it the kernel, X, or whatever) don't bitrot, even if the manufacturer stops maintaining them. So what does it matter whether it was written by the community or started as a binary blob and got open-sourced by the manufacturer?
In the long run, I think you'll find that the kind of customer who won't trust a community-written open source driver to be very high quality won't be using Linux (or BSD or any other Unix) at all.
Congratulations. You've made the all-to-common, stupid mistake of equating UI look and feel. They are two very different things. Almost everything you listed could be preserved while still satisfying most customers by rolling the look back to something less gaudy.
However, most people would disagree that the feel of the UI is really any better, let alone worth the hassle of an upgrade and the requisite re-learning. And even if the mechanics of the UI are an improvement for you, it still doesn't deserve praise because of the vast number of obvious, easily fixed flaws.
It's more like we understand that no real terrorist bomb would be studded with LEDs. Or worn on the outside of a sweatshirt.
When carbon fiber composites break, they tend to shatter. When aluminium is overly stressed, it dents or rips. The thing is that it takes a lot more force to break the carbon composite than to dent the aluminum enough to compromise its strength.
CONFIG_PREEMPT and CONFIG_HZ are pretty much all you need to worry about.
nice isn't all that's required for good gaming performance, but right now, it's the only way to exceed the performance from the default CFS and SD.
As for your comments about clean code: Cleaner code will be easier to maintain and thus more secure. A unified server/desktop kernel will allow desktops to benefit from optimizations made with servers in mind. This happens all the time, as desktops are constantly catching up with the servers that went before them.
Imagine where Linux desktop performance would be today if it weren't for the decade of SMP development that preceded the arrival of dual-core desktop processors. Now, in retrospect, would you say that it was worth it, given that none of the SMP code ever slowed down your UP kernels?
Forking the kernel is a complete waste of time when all that is necessary is for distros to use their own .config file when compiling their kernels. Desktop-oriented distros can, and do, tweak their kernel configurations to enable the optimizations the help the desktops most.
There are approximately 2 kernel configuration changes required to switch from a throughput-optimized system to a latency-optimized system. They work. Any questions?
I'll turn the question back around to you:
Do any desktop users give a damn whether their games run faster due to a scheduler hack or a nice level boost? No.
So why not just let the desktop distros throw a nice command into their X init scripts? The resulting performance is the same, but the code stays cleaner and more maintainable.
I'm quite familiar with all the CFS vs. SD issues.
My point was that no forking or pluggable schedulers are necessary because all the important ideas, if not the actual code, from Con's SD (and more recently, Roman's RFS) have been incorporated into the mainline scheduler.
Forking would only be justified if the work done by the likes of Con and Roman wouldn't be accepted into the mainline kernel. Even though there code hasn't been merged, the kernel has undeniably benefitted from their design work (which is far more important than the actual implementation). Using pluggable schedulers would only be justified if the single scheduler were forced to incorporate some fundamental tradeoffs that weren't acceptable to all users. That obviously hasn't happened: CFS and SD are both better than the previous O(1) scheduler all-around. Neither scheduler sacrifices desktop performance for server performance, or vice versa.
You're missing the point. A pluggable scheduler is not necessary for desktop usage, because nobody (not even Con) has been able to come up with a scheduler that is significantly better than CFS for desktop usage, except by doing things that amount to hard-coded nice levels. All of the meaningful performance improvements have made it into the default scheduler.
Sure, linux kernel modules don't have any significant execution speed overhead, wheras darwin does because of excess context switches. The overhead I was referring to on linux was just that a modular kernel (with all the modules loaded) can take up more memory. If you know you will always need all your drivers (usually for server and embedded workloads), compiling in everything and leaving out loadable module support can cut down on your RAM usage (though this typically only matters for embedded systems).
Which algorithms are bottlenecking your desktop? Is it the I/O scheduler? You can swap between one of four choices, at runtime.
Is it the CPU scheduler? If so, you're a liar. Nobody had produced repeatable benchmarks that show a significant shortcoming in CFS for desktop and gaming use.
Is the memory allocator really bad for your workload? Try using the new SLUB allocator, instead of the older SLAB allocator.
Is the system not as responsive as you want? Turn on forced preemption and set the tick speed to 1000Hz.
The linux kernel already does this, with modules that can be loaded and unloaded at runtime. Whole subsystems (things like SCSI and DRI) can be loaded on demand. You can also enable or disable kernel preemption at compile time, and you can swap out I/O schedulers at run-time.
However, the modular approach can have some overhead of its own (though not as much on linux as on darwin). If you really need a small kernel, you can actually disable loadable module support at compile-time, if you know exactly which drivers you need.
Have you got any examples where there is significant overhead that can't be removed with a make config but could be removed with a specific, less scalable algorithm that isn't available in the kernel source?
I'm pretty sure your comment is mostly BS. The vanilla kernel source includes a lot of configuration options for embedded systems. Low on RAM? Turn off CONFIG_BASE_FULL to use several smaller, slower data structures. Don't have swap space? Turn off things like CONFIG_SHMEM. Using uClibc? For now, you might as well throw out CONFIG_FUTEX as well.