Start with the CONFIG_EMBEDDED option - it allows you to excise a significant amnount of stuff from the kernel image that would otherwise remain unused. If you want more savings, there is a tinykernel tree somewhere that has patches which allows you to remove even more stuff. IIRC the kernels built from this tree can comfortably run with as little as 4MB of RAM.
Sorry, but what you envision is never going to pass. Linus has repeatedly stated that he will not permit the modification of the Linux kernel source in order to cater to the maintainers of binary-only modules. If they refuse to *PL their code, then they must shoulder the burden of maintainership until such time that they do decide to *PL it.
It would be nice if the code allowed this, but since it doesn't, all we can do is carefully research the support and drivers that do exist and are available for the latest and greatest hardware, before we buy them.
Sorry, but it's not gonna happen. Linus has repeatedly stated that he will never modify the internal APIs of the kernel to make the maintainership of binary-only modules easier for hardware manufacturers. While this attitude may seem unfair and self-serving, it makes sense, and is not likely to change.
Right now 3D graphics drivers for ATi and NVIDIA cards are the only sticking point in hardware support IMO. Just about every other major component has Linux support, if you do careful research before buying.
I didn't even though this was still a viable technology. I thought it had been discarded as one of those pieces of innovation that could have been useful but never truly was.
If the FCC is writing rules for its use, that must mean that it is viable - why write rules for a dead technology?
Hopefully he can build up enough inertia that any of his successors who do get bought out won't be able to turn the tide back with aforementioned crippling regulations. They way you describe him is very reassuring.
A new download manager. Bugfixes. Improvements in tabbed browsing. Bugfixes. A new Help dialog. More bugfixes. Changes in the Gecko rendering engine. Even more bugfixes.
This is because the authors of the themes have not updated their themes to support Firefox 0.8. In between Firebird 0.7 and Firefox 0.8 there were several changes made to the internal APIs which broke many themes. Because the theme authors do not want to waste time on a moving target, they collectively decided to wait until Firefox 0.8 was released. As a result, you will either have to wait for your theme to be updated or bug the theme author to fix their theme.
Some of the MozillaZine forum members share the dismay of earlier posters over how this may damage evangelism efforts, because of the effort required in explaining the similarities and differences between Firebird and Firefox. Either way, because Firebird is beta software, these types of name changes can happen with minimal disruption. Imagine what would have happened if this was Firefox 1.0, not Firefox 0.8.
My biggest beef with Prescott is that Intel rather foolishly lengthened the pipleine and monkeyed with the core design without making the subsequent changes needed to increase clock speed. AMD had it right all along - efficient IPC and low clock speed.
This situation is shaping up, in my eyes, to be a repeat of the release of the Willamette P4 - an inefficient IPC coupled with a low clock speed nearly killed the P4 before Intel could increase the clock speed. The same thing is happening here - another inefficient IPC design with a clock speed equal to the current Northwoods, with subsequent losses in performance. And like another poster here said, the A64 3400+ still beats the Prescott in a number of benchmarks, or ties evenly with it. Despite Anand's statements about how higher clockspeeds increase the efficiency of the Prescott core, I still think that this processor is an expensive upgrade that doesn't do very much.
If Intel can't get the clock speed up on Prescott, I have a feeling that it's going to tank until the LGA775 packaging is finally brought out, which is going to mean more business for AMD and a lot of eggs on Intel's face.
IMO your description of your experiences and thoughts on this matter is exactly the sort of material that the developers of the Linux desktop and distro need to see. You need to get a website somewhere, put this up and point people to it - this mini-essay should NOT get lost in the bowels of Slashdot.
That would be an excellent idea - have you tried advertising this on some of the more general-purpose mailinglists and forums to see if anyone would be willing to do a translation?
Whoa - your friend just proved that despite the efforts of IBM, Red Hat and others to defend Linux against the FUD being spread by its competitors, that some of it is still getting through to the enduser. Her comment about Linux being swallowed by the corporations is a frightening one, and proves (at least to me) that we need to be much more proactive when it comes to explaining the philosophy and history of the Linux distribution, so that people don't continue to make this mistake in their thinking.
Check the Changes file in the kernel source. Basically any modern distro like Fedora Core 1, Mandrake 9.2, SuSE 9, Gentoo, Debian-unstable or whatever can all compile and boot 2.6 kernels without any real problems.
From the sound of it, this new spec appears to deliver far too much bandwidth to really make it cost-effective for the average consumer. IMO this is best for fixed-wireless installations where installing cabling is too cost-prohibitive - especially if the range of the radio tech used in this spec is decent enough.
The Ethernet/LAN driver issue is no longer a major problem - if you can find a distro which bundles a 2.4.23/2.6.0 or later kernel, it will include the new forcedeth driver, which is a clean-room reverse-engineered driver for NVIDIA Ethernet devices. It works very well, and I've seen lots of positive feedback.
Right now, though, you're probably right about the immaturity of 64bit Linux distros - IMO Gentoo is the one distro that is most likely to mature soonest on the AMD64 platform.
Not even the entry price is that much of an issue now; the release of the Clawhammer-based Athlon 64 3000+ for the sale price of only $215 significantly lowers the barrier to entry. Sure, all the necessary parts for a completely new system may still run all the way up to approx. $850, but having a low-spec processor like the 3000+ available only helps AMD"s product adoption.
The 939pin processors, which will be sold in single and dual-channel variants, will not require registered memory like the Opteron does. This means that they will be able to operate much faster and be much more overclockable.
Slashdot Mirror
Start with the CONFIG_EMBEDDED option - it allows you to excise a significant amnount of stuff from the kernel image that would otherwise remain unused. If you want more savings, there is a tinykernel tree somewhere that has patches which allows you to remove even more stuff. IIRC the kernels built from this tree can comfortably run with as little as 4MB of RAM.
Sorry, but what you envision is never going to pass. Linus has repeatedly stated that he will not permit the modification of the Linux kernel source in order to cater to the maintainers of binary-only modules. If they refuse to *PL their code, then they must shoulder the burden of maintainership until such time that they do decide to *PL it.
It would be nice if the code allowed this, but since it doesn't, all we can do is carefully research the support and drivers that do exist and are available for the latest and greatest hardware, before we buy them.
Sorry, but it's not gonna happen. Linus has repeatedly stated that he will never modify the internal APIs of the kernel to make the maintainership of binary-only modules easier for hardware manufacturers. While this attitude may seem unfair and self-serving, it makes sense, and is not likely to change.
Right now 3D graphics drivers for ATi and NVIDIA cards are the only sticking point in hardware support IMO. Just about every other major component has Linux support, if you do careful research before buying.
I didn't even though this was still a viable technology. I thought it had been discarded as one of those pieces of innovation that could have been useful but never truly was.
If the FCC is writing rules for its use, that must mean that it is viable - why write rules for a dead technology?
Hopefully he can build up enough inertia that any of his successors who do get bought out won't be able to turn the tide back with aforementioned crippling regulations. They way you describe him is very reassuring.
Would this service be almost impossible to provide if the FCC regulated it as a telecom?
A new download manager.
Bugfixes.
Improvements in tabbed browsing.
Bugfixes.
A new Help dialog.
More bugfixes.
Changes in the Gecko rendering engine.
Even more bugfixes.
Seriously, I'd upgrade.
This is because the authors of the themes have not updated their themes to support Firefox 0.8. In between Firebird 0.7 and Firefox 0.8 there were several changes made to the internal APIs which broke many themes. Because the theme authors do not want to waste time on a moving target, they collectively decided to wait until Firefox 0.8 was released. As a result, you will either have to wait for your theme to be updated or bug the theme author to fix their theme.
Ben Goodger made a blog entry where he explained the entire rationale behind the name change to Firefox: http://www.bengoodger.com/weblog/archives/cat_mozb log.shtml
Some of the MozillaZine forum members share the dismay of earlier posters over how this may damage evangelism efforts, because of the effort required in explaining the similarities and differences between Firebird and Firefox. Either way, because Firebird is beta software, these types of name changes can happen with minimal disruption. Imagine what would have happened if this was Firefox 1.0, not Firefox 0.8.
Indeed. I've seen kernel.org use 275Mbit/s of a 250Mbit/s connection ;-)
Instead of actually doing something useful, they sit around and argue over the right font to use.
Dear God.
XFS will probably be relicensed as Dual BSD/GPL - choose your license if you want to work with the code.
BWAhahahahahahahahahahahahahaha!!!!!!!!!!!!
If it wasn't from google.com I'd be convinced it was a spoof!
My biggest beef with Prescott is that Intel rather foolishly lengthened the pipleine and monkeyed with the core design without making the subsequent changes needed to increase clock speed. AMD had it right all along - efficient IPC and low clock speed.
This situation is shaping up, in my eyes, to be a repeat of the release of the Willamette P4 - an inefficient IPC coupled with a low clock speed nearly killed the P4 before Intel could increase the clock speed. The same thing is happening here - another inefficient IPC design with a clock speed equal to the current Northwoods, with subsequent losses in performance. And like another poster here said, the A64 3400+ still beats the Prescott in a number of benchmarks, or ties evenly with it. Despite Anand's statements about how higher clockspeeds increase the efficiency of the Prescott core, I still think that this processor is an expensive upgrade that doesn't do very much.
If Intel can't get the clock speed up on Prescott, I have a feeling that it's going to tank until the LGA775 packaging is finally brought out, which is going to mean more business for AMD and a lot of eggs on Intel's face.
Indeed - I welcome our undead SCO-immune BSD overlords as well ;)
Sir, you have NAILED IT!!!
IMO your description of your experiences and thoughts on this matter is exactly the sort of material that the developers of the Linux desktop and distro need to see. You need to get a website somewhere, put this up and point people to it - this mini-essay should NOT get lost in the bowels of Slashdot.
That would be an excellent idea - have you tried advertising this on some of the more general-purpose mailinglists and forums to see if anyone would be willing to do a translation?
Whoa - your friend just proved that despite the efforts of IBM, Red Hat and others to defend Linux against the FUD being spread by its competitors, that some of it is still getting through to the enduser. Her comment about Linux being swallowed by the corporations is a frightening one, and proves (at least to me) that we need to be much more proactive when it comes to explaining the philosophy and history of the Linux distribution, so that people don't continue to make this mistake in their thinking.
Check the Changes file in the kernel source. Basically any modern distro like Fedora Core 1, Mandrake 9.2, SuSE 9, Gentoo, Debian-unstable or whatever can all compile and boot 2.6 kernels without any real problems.
It doesn't say anywhere what chipset they used for this shootout...
Although 35 miles with 802.11 is pretty damn good, IMO - scroll to the bottom and have a look at the monster antenna they used.
From the sound of it, this new spec appears to deliver far too much bandwidth to really make it cost-effective for the average consumer. IMO this is best for fixed-wireless installations where installing cabling is too cost-prohibitive - especially if the range of the radio tech used in this spec is decent enough.
The Ethernet/LAN driver issue is no longer a major problem - if you can find a distro which bundles a 2.4.23/2.6.0 or later kernel, it will include the new forcedeth driver, which is a clean-room reverse-engineered driver for NVIDIA Ethernet devices. It works very well, and I've seen lots of positive feedback.
Right now, though, you're probably right about the immaturity of 64bit Linux distros - IMO Gentoo is the one distro that is most likely to mature soonest on the AMD64 platform.
Not even the entry price is that much of an issue now; the release of the Clawhammer-based Athlon 64 3000+ for the sale price of only $215 significantly lowers the barrier to entry. Sure, all the necessary parts for a completely new system may still run all the way up to approx. $850, but having a low-spec processor like the 3000+ available only helps AMD"s product adoption.
The 939pin processors, which will be sold in single and dual-channel variants, will not require registered memory like the Opteron does. This means that they will be able to operate much faster and be much more overclockable.
So? It's just basic clock drift. Why is this an issue?