It seems to me that there is confusion about *source* compatibility and *binary* compatibility.
Source compatibility of Linux has been pretty good, with changes only occurring when Linus waves his hand on an even numbered release (for the most part.)
Binary compatibility with Linux is *horrible*. Structures change all the time. Pretty much you need to recompile your drivers even when a *patch* to the kernel is made. Yech!
Open Source developers usually don't care, and Linus has made some pretty vocal arguments against having anything *but* Open Source in the kernel.
Now folks complain when certain hardware developers don't release *open source* drivers. Well, let me tell you, a lot of times there is a lot of proprietary information in those drivers, and the vendors have a vested interest in keeping the drivers closed. In the specific case of WLAN mentioned here, they might even be legally obligated to stick with binary drivers (e.g. due to FCC regulations about software radios.)
Well, the answer to getting better hardware support is quite simple, but it requires the Linux people to change their way of thinking. That is that you need to support a robust kernel API, that provides support for binary compatibility. Its not hard to do -- Solaris has had it for many years. I can have a single source, single binary, that works across a decade or so of Solaris releases without any problem at all, as long as I stick to the documented DDI. Sun has even provided compliance tests to prove this (DDICT).
How you get to binary compatibility involves declaring certain structures off limit for direct access (use accessor routines), stabilizing at least parts of others, and possibly adding versioning interfaces in key places.
Easy to do? Yes, not trivial, but not exactly hard either. Will it happen? Not likely, as long as the GPL fanboys/fangirls insist that binary device drivers are evil.
Now for WLAN stuff, you have another problem, which is supporting userland tools. There are a variety of userland tools for WLAN configuration on Linux, and frankly they were all horrible the last time I checked. Any company that wants to support "Linux" (as opposed to "RedHat 5.2" or somesuch) is going to have to either test a wide range of tools, or supply their own. In this case, choice really has amounted to duplication of effort, and it would be far better to have a single, robust, friendly toolset than the half-dozen odd pieces of junk we have today.
Seems like you could actually use the idea of a particle accelerator to send up pods, and you could probably do it safely for human transport by just making the rail long enough. I don't know exactly what the escape velocity at the surface needs to be, but I'd imagine that a rail of a couple miles would be able to get you up to said velocity without g-forces much different than what the shuttle experiences today. (How *many* miles the track has to be is the question.)
A problem is the shape of the curve because I assume the track isn't going to be 5 miles straight up. So you have a very, very long straight away, with a large 90 degree turn to go from the horizontal to vertical.
Another option is to have a very small inclination, say 20 degrees, but you have to have a higher vecolity to pull it off.
An interesting problem for undergrad physics students: what is the diameter of a turn needed to reach escape velocity at the end of the arc, given the constraints:
1) maximum linear acceleration of 5G 2) maximum centripetal acceleration of 5G 3) escape velocity at end of arc 4) assume any inbound velocity that meets the requirements 5) maybe different arc angles -- 90 degress, 45 degrees, etc. Useful minimum is probably about 10 degrees.
Then if the arc turns out to be quite large, but it is within say tunneling range (perhaps using a mountain face to aid with the ascent), you can go underground to build it.
Imagine that as the pods near their intended orbital velocity they blow some kind of external shell to deploy low energy thrusters.
I'll split the grant money with the parent. (I think there should be two grants, one for the mass accelerator idea, and another one for making it safe for human transport.:-)
But you never addressed my original question, which is why would you even waste your time trying to *install* a new OS on this ancient hardware? For pennies on the original new cost dollar, you can easily pick up systems with 64-bit processors, that still run all those old 32-bit apps, and several times faster (and more responsive to boot).
The obsolence of the sun4d/sun4m archs has been a well known/planned/documented thing. Sun warned folks about this *years* ago. (Go back to some S9 release notes for proof.)
And supporting the older platforms (just keeping the old code) does cost real time and resources. Everything from the time it takes to pull the extra source files (which on a given pull isn't much, but over the course of thousands of developers and a couple of years, it adds up!), to the time it takes to build it, to whether or not it is going be tested.
And if an interface needs to be updated/changed, you may find yourself going into this old code to "update" it so that it won't break a compile.
This all takes time, and it is not trivial. Believe me, as a former Sun kernel developer, I was quite gleeful whenever I got blessings from management that I didn't need to worry about one form or another of backwards compatibility. It usually meant one less set of #ifdef's I had to sustain.
Actually, in the case of the sun4m and sun4d hardware, it was really a consequence that the kernel memory guys wanted to move away from a 32-bit kernel. There were various problems with larger configurations and 32-bit kernels, and it just made things a lot cleaner/easier if they could assume a 64-bit memory model. The only way to cleanly do this was to remove support for the systems that couldn't run 64-bit kernels (sun4m/sun4d, and some Ultra-1s with early processors with defective 64-bit CPUs.)
The decision to remove 32-bit sparc support was made a long, long time ago -- long before OpenSolaris was ever conceived. So at the time there was no thought that anyone in the open source community would want to maintain support for the older platforms. Even though the source is open, I still suspect a lot of the decisions that drive its development are going to center around what corporate customers want, and support for ancient 32-bit sun4m hardware just isn't likely to rate very high.
Why would possibly want to have developers working on sun4m hardware? These days you can pick up an UltraSparc based machine with an UltraSparc-IIi for dirt cheap -- just check out ebay. For not much beyond the cost of shipping you can pick up an Ultra 30, 60, 10, or 5 workstation. You can pick up servers for a little more -- e.g. Ultra 450, etc. And any of these machines with a nearly 10 year old processor will blow the doors off of any sun4m machine.
S/Bus was used in early UltraSPARC designs (Ultra-1 systems, mainly), and killing S/Bus will indeed happen at some point in the future, but there are still a lot of Ultra/1 systems out there. (And indeed, the UltraSPARC-1 based systems, with processors less than 200MHz, are already not supported due to a CPU bug that made them insecure in 64-bit mode.)
Conversely, there is a huge amount of effort required to support both a 32-bit kernel and 64-bit kernel on SPARC, and the distraction really takes resources away from other cool things that we'd like to see Sun continue to improve upon (e.g. ZFS, network performance, etc.)
Now if you have some old *sun4d* hardware, I'd understand why you wouldn't want to just toss the machine out. But even that is a very aging arch.
I think you folks with Ross modules need to update to the new millenium.:-)
Slashdot Mirror
It seems to me that there is confusion about *source* compatibility and *binary* compatibility.
Source compatibility of Linux has been pretty good, with changes only occurring when Linus waves his hand on an even numbered release (for the most part.)
Binary compatibility with Linux is *horrible*. Structures change all the time. Pretty much you need to recompile your drivers even when a *patch* to the kernel is made. Yech!
Open Source developers usually don't care, and Linus has made some pretty vocal arguments against having anything *but* Open Source in the kernel.
Now folks complain when certain hardware developers don't release *open source* drivers. Well, let me tell you, a lot of times there is a lot of proprietary information in those drivers, and the vendors have a vested interest in keeping the drivers closed. In the specific case of WLAN mentioned here, they might even be legally obligated to stick with binary drivers (e.g. due to FCC regulations about software radios.)
Well, the answer to getting better hardware support is quite simple, but it requires the Linux people to change their way of thinking. That is that you need to support a robust kernel API, that provides support for binary compatibility. Its not hard to do -- Solaris has had it for many years. I can have a single source, single binary, that works across a decade or so of Solaris releases without any problem at all, as long as I stick to the documented DDI. Sun has even provided compliance tests to prove this (DDICT).
How you get to binary compatibility involves declaring certain structures off limit for direct access (use accessor routines), stabilizing at least parts of others, and possibly adding versioning interfaces in key places.
Easy to do? Yes, not trivial, but not exactly hard either. Will it happen? Not likely, as long as the GPL fanboys/fangirls insist that binary device drivers are evil.
Now for WLAN stuff, you have another problem, which is supporting userland tools. There are a variety of userland tools for WLAN configuration on Linux, and frankly they were all horrible the last time I checked. Any company that wants to support "Linux" (as opposed to "RedHat 5.2" or somesuch) is going to have to either test a wide range of tools, or supply their own. In this case, choice really has amounted to duplication of effort, and it would be far better to have a single, robust, friendly toolset than the half-dozen odd pieces of junk we have today.
Seems like you could actually use the idea of a particle accelerator to send up pods, and you could probably do it safely for human transport by just making the rail long enough. I don't know exactly what the escape velocity at the surface needs to be, but I'd imagine that a rail of a couple miles would be able to get you up to said velocity without g-forces much different than what the shuttle experiences today. (How *many* miles the track has to be is the question.)
:-)
A problem is the shape of the curve because I assume the track isn't going to be 5 miles straight up. So you have a very, very long straight away, with a large 90 degree turn to go from the horizontal to vertical.
Another option is to have a very small inclination, say 20 degrees, but you have to have a higher vecolity to pull it off.
An interesting problem for undergrad physics students: what is the diameter of a turn needed to reach escape velocity at the end of the arc, given the constraints:
1) maximum linear acceleration of 5G
2) maximum centripetal acceleration of 5G
3) escape velocity at end of arc
4) assume any inbound velocity that meets the requirements
5) maybe different arc angles -- 90 degress, 45 degrees, etc. Useful minimum is probably about 10 degrees.
Then if the arc turns out to be quite large, but it is within say tunneling range (perhaps using a mountain face to aid with the ascent), you can go underground to build it.
Imagine that as the pods near their intended orbital velocity they blow some kind of external shell to deploy low energy thrusters.
I'll split the grant money with the parent. (I think there should be two grants, one for the mass accelerator idea, and another one for making it safe for human transport.
But you never addressed my original question, which is why would you even waste your time trying to *install* a new OS on this ancient hardware? For pennies on the original new cost dollar, you can easily pick up systems with 64-bit processors, that still run all those old 32-bit apps, and several times faster (and more responsive to boot).
The obsolence of the sun4d/sun4m archs has been a well known/planned/documented thing. Sun warned folks about this *years* ago. (Go back to some S9 release notes for proof.)
And supporting the older platforms (just keeping the old code) does cost real time and resources. Everything from the time it takes to pull the extra source files (which on a given pull isn't much, but over the course of thousands of developers and a couple of years, it adds up!), to the time it takes to build it, to whether or not it is going be tested.
And if an interface needs to be updated/changed, you may find yourself going into this old code to "update" it so that it won't break a compile.
This all takes time, and it is not trivial. Believe me, as a former Sun kernel developer, I was quite gleeful whenever I got blessings from management that I didn't need to worry about one form or another of backwards compatibility. It usually meant one less set of #ifdef's I had to sustain.
Actually, in the case of the sun4m and sun4d hardware, it was really a consequence that the kernel memory guys wanted to move away from a 32-bit kernel. There were various problems with larger configurations and 32-bit kernels, and it just made things a lot cleaner/easier if they could assume a 64-bit memory model. The only way to cleanly do this was to remove support for the systems that couldn't run 64-bit kernels (sun4m/sun4d, and some Ultra-1s with early processors with defective 64-bit CPUs.)
The decision to remove 32-bit sparc support was made a long, long time ago -- long before OpenSolaris was ever conceived. So at the time there was no thought that anyone in the open source community would want to maintain support for the older platforms. Even though the source is open, I still suspect a lot of the decisions that drive its development are going to center around what corporate customers want, and support for ancient 32-bit sun4m hardware just isn't likely to rate very high.
Why would possibly want to have developers working on sun4m hardware? These days you can pick up an UltraSparc based machine with an UltraSparc-IIi for dirt cheap -- just check out ebay. For not much beyond the cost of shipping you can pick up an Ultra 30, 60, 10, or 5 workstation. You can pick up servers for a little more -- e.g. Ultra 450, etc. And any of these machines with a nearly 10 year old processor will blow the doors off of any sun4m machine. S/Bus was used in early UltraSPARC designs (Ultra-1 systems, mainly), and killing S/Bus will indeed happen at some point in the future, but there are still a lot of Ultra/1 systems out there. (And indeed, the UltraSPARC-1 based systems, with processors less than 200MHz, are already not supported due to a CPU bug that made them insecure in 64-bit mode.) Conversely, there is a huge amount of effort required to support both a 32-bit kernel and 64-bit kernel on SPARC, and the distraction really takes resources away from other cool things that we'd like to see Sun continue to improve upon (e.g. ZFS, network performance, etc.) Now if you have some old *sun4d* hardware, I'd understand why you wouldn't want to just toss the machine out. But even that is a very aging arch. I think you folks with Ross modules need to update to the new millenium. :-)