There are good technical reasons for there not being a driver 'ABI' for Linux. Reason #1 is that even the source 'API' is not set in stone (so the ABI has/0/ chance), to be able to update interfaces when needed rather than leaving bad interfaces in place for the sake of compatibility can be a good thing.
Oh, I see you bought that GoodFact(tm). on the same sort of level as "Ignorance is Strength" etc. (Read George Orwell's "1984" if you missed the reference.)
Hmm.. it's a great spin on the fact that there's neither the political will nor the appetite to paw over the kernel device driver interface and create a full, strict, detailed and fully thought out interface document to which the kernel and device drivers can be written and verified against and have it imposed on the kernel and driver developers.
Basically, it's an excuse to try to hide that the current kernel development is avoiding the problems of doing proper software engineering and is showing its hobbist roots, unfortunately.
I would like to see Linux succeed. However, the way it's going at the moment I can see it becoming an interesting footnote in history.
I'm sorry to burst your utopian bubble, but this will never ever happen.
Linux is too small a market for them to worry about and it will forever be so when Aunt May can't just plug in and go. The companies who prefer closed source will just ignore the small loss of ernings from the Linux crowd.
As for the reason for not designing a properly thought out, documented, standardised and unchanging (during the life of a major sub-version) driver interface just in case a commercial, closed source company may write a driver for it: Isn't this throwing the baby out with the bath water?
I'm afraid you're mistaken in this in the following way:-
If there were a standard ABI for drivers within a major release of Linux you could essentially disociate the drivers from the kernel. The driver development could then run on a totally different timescale to the core kernel with release dates as they wish.
It would also mean that the driver maintainers could release a binary version of their driver, which they have tested themselves (as well as releasing the source code for those who wish to look at the nitty gritty) so that the users can just install and go.
It would help the driver developers with support no end if one binary fits all kernel sub-versions and configurations.
On the point of closed-source/commercial drivers. They would only need to produce one version for everyone (rather than having to compile 15 different ones for each distribution and kernel release for each of those). This would make them FAR more likely to throw support at the problem as the money/time (same thing) they'd have to devote to the wasteful compile and package part of the business would be a whole lot less.
The problem is that some people in the free software business place idiology and self-interest over practicality (from the user viewpoint). The idiology being "if we make an ABI then the evil propriatory people will use it" and the self-interest being "if we don't specify an ABI then we can change out API on a whim." The second of those is probably the more important to the Linux developers as they seem to change the driver API within major releases quite a bit. (A number of drivers which compile on older 2.6 kernels won't anymore because the API has changed radically within the last few sub-releases.)
For the uptake and maintainability of Linux, this driver nightmare is the biggest drawback and it's nothing really to do with closed source at all.
I was talking more about scientific computing where there's no redraws or user interaction. Quite often in this sort of code the act of calling a subroutine/functionother than an intrinsic one (in FORTRAN) has such a high penalty that you wouldn't do it if you could help it. Some of these codes can run for months at a time, mostly in these sorts of tight computational loops, so you can see how optimising the hell out of them can shave days off a run.
When you're talking about GUI programming then, yes, doing intelligent redraws and updates will save huge amounts of work for the graphics system and hence speed things up. This is to do with the basc design of the code to begin with, mostly, rather than optimisation as such.
The only code segments you really have to worry about hand optimising are loops which happen a huge number of times.
In scientific computing, a loop which does most of the calculation and runs hundreds of thousands or maybe millions of times is the most critical to get right. After all, one millisecond lost per loop may mean a day's extra computation time.
A great deal of the optimisation has to be within the algorithm, making sure that you don't do unnecessary computation. However, some of it is to do with knowing how CPUs work. If you order the calculations in the correct way you can aid the compiler in its optimisation buy helping to work on data which is likely to be kept within the registers rather than flitting about and having to swap the values out to cache, or even worse, main memory.
I'm afraid I don't have a link. I was told about this system during my MSc in Comp Sci in '88-'89. Just a tad before the web became popular.:-)
As for the NOPs etc. I believe the exception causes CPU state data loss, hence you couldn't (easily) recover using a single processor. Also, yes, memory was VERY expensive, far more so than the cost of another processor.
From what I remember, AmigaDOS was originally based on many of the ideas of Tripos. Indeed, at the commandline it's hard to tell the difference. (I've hacked about on a Tripos system using only my knowledge of AmigaDOS.)
However, AmigaDOS isn't a direct decendant of Tripos, though early versions of AmigaDOS were partly written in BCPL by Metacomco in Bristol, UK. on Sinclair QLs.
This early code was very quickly replaced subsiquently.
And the Sinclair QL had pre-emptive multitasking in 1984..:-)
As for memory protection, the early 680xx (where xx is either 08, 00 or 10) series chips didn't have memory protection (for user processes) but they did have a rudimentry one for preventing user level code from accessing supervisor mode protected memory. However, this didn't help much as the 68000 and 68008 couldn't restart instructions after a memory fault exception. (There was one UNIX Version 7 system which used tandem 68000's which had one processor lag one intruction behind the first so that it could be used to restart the processing in the case of a memory fault.)
The 68010 had the ability to restart an instruction but no real MMU interface. it wasn't until the 68020 came out that, with the aid of an external MMU chip, a fully memory protected OS could be written. This was the basis of the very first Sun Microsystems machine.
Of course, it wasn't until the late 80's that anyone thought about putting these higher chips into mainstream machines and even later before anyone thought that memory protection and virtual was a really good idea on the desktop. (Even NT 4.0 had a single, shared flat memory space, though with memory protection and virtual paged memory extension.)
Well, it's very interesting about how the Amiga has managed to continue on in the back waters of computing for the last few years. However, it's not the only one!
Thos of you who remember the Sinclair QL (ie. people such as Linus Torvalds and some of the early AmigaDOS authors who worked at Metacomco) might like to know that some people are continuing the development of both the hardware and the operating system..
eg. Q40 and their latest Q60 motherboard designed to fit in a PC case.
Although for some, non-memory intensive, highly threaded applications multiple cores can be a boon, for many applications this won't be a boost in performance at all.
Remember that each of these processing cores will have to share their memory bandwidth and possibly level 2 cache as well. As it is Intel's EM64T Xeon processors really feel the bandwidth bottleneck in their memory interface and can easily saturate it.
I can see a dual core Xeon being able to saturate its memory bus on its own. Similarly, the dual core Opteron, unlike a dual processor Opteron, will have to share a single memory bus and hence be slower than a dual processor machine.
Adding extra cores merely moves the computing bottleneck elsewhere, it's not a panacea.
I agree that what I posted was a very great simplification (maybe over simplification? That's up to the reader to decide). However, it's not, in general a bad rule of thumb.
Of course, the cheapest type of camera, the pin-hole camera, has a huge depth of field (the image quality only dependent upon the circularity and size of the hole).:-)
The Nikon D70 is often used by professionals as their second camera for doing "snap" type photographs.
Relative to the Canon 300D, the D70 is far less crippled than its stable mate. The main "cripple" points are the lack of the option to have an extended battery and portrait grip, "only" ISO 200 mode and a set of mirrors rather than prisms for the viewfinder. Oh, and the "kit" lens in the D70 kit is a pretty nice lens, unlike the toy lens in the 300D kit.
It is true that the D70/300D aren't in the same league as the D2X etc. but then again they're a third of the price. That doesn't make them bad cameras in the same way that the old Olympus OM10 was a pretty good hobbyist's camera and able to take pictures as good as an OM1 in the right hands.
I got a little way through this piece and came across a gross error which, for me, made the rest of the article of very dubious worth.
One of the reasons extolled at length for choosing one type against abother is that a DSLR has a narrow depth of field and a "standard" digital camera has a greater depth. As anyone who knows about photography would know this is total tosh.
The depth of field depends upon the aperture of the iris. A small aperture acts rather like a pinhole camera and hence will give a great depth of field. A large aperture relys upon the lens for focus and hence depends greatly on the focal length of the lens system giving critical focus and a very narrow depth of field.
Cheap "standard" digital cameras will usually have a small lens and small (fixed?) aperture hence a large depth of field. More expensive "standard" digital cameras are more sophisticated and allow the user to change the aperture and have a larger lens, so they can have a narrow depth of field.
Digital SLRs are totally dependant upon the lens system. However, because they have a variable iris within the lens systems they can have either a very wide depth of field (if they're stopped right down) or a very narrow depth of field (iris wide open). Both the end points of these will depend entirely on the characteristics of the lens systems.
How many people would accept an article which said that you shouldn't buy a 35mm SLR because you only get a narrow depth of field?
Dell have a problem in the HPC/multi-processor server market. The latest generation of Xeons, the EM64T 64bit capable x86 class processors can only currently go 2 way as Intel don't actually produce a 4 way chipset for these processors yet. Not only this but because the EM64T processors share a memory bus they soon run out of bandwidth.
This is a real problem for Dell as they can't produce machines with large, flat memory architectures with more than 2 processors, and even then the HPC (High Performance Computing) crowd are just laughing that their machines because of the price and memory bottleneck.
Dell are now seeing large cluster purchases abandoning them for other companies who can supply fat nodes which 16-32GB of RAM and 4 processors which have copious amounts of memory bandwidth 'cos of the cunning way AMD built the Opterons.
This is why, I believe, Dell are looking at adding AMD to their line. It may also be a cynical move to get Intel to do something but in the cluster space Intel's processors produce too much heat and just can't do 4 way+big memory and Dell are hurting.
The problem with MUDs/MUSHs/etc.etc.etc. these days is that players don't have to wait up 'til 2am to try to connect to an obscure computer housed in the south east of England via an X25 PAD using a long string of numbers and then try to use the small number of suspended connections before someone else did.
Hmmm..
PAD> CALL 0000 4960 0000 1 [2653,2653] MIST
Ahhhh..:-)
If newbies had this they'd be very happy with all the long-term good inovations.. as long as they didn't get instantly killed by an archwiz with a chip on their shoulder, that is.
I can only see the merging of WiFi and GSM if hell freezes over or when the telcos can charge for both the use of the GSM part of the connection and the WiFi.
With further thought, it will probably happen, but only for "public" access points being run by the telcos themselves allowing their slaves^H^H^H^H^H^Hcustomers to access higher speed data and possibly VoIP services when in range of their own hotspots.
The problems of hand-over of an IP connection to a cellular network are non-trivial as well, which would make it far more likely that it will only be teleco owned and run hotspots which will be able to do this.. at a large per megabyte cost, no doubt. (Probably the same as they charge for GSM data transfer. In the UK that's about £3 a megabyte!)
I believe that it is the law in England (and Wales) that if you know of a criminal act taking place then if you do not report it to the police then you are deemed to be an accessory after the fact and have hence committed a criminal act yourself.
Therefore, once the University was informed of the criminal acts (breach of the Computer Misuse Act) they had to inform the police. They had no choice in the matter.
If programme distributors, such as Rupert Murdoch's BSkyB operation in the UK, were forced to sell their wears on a channel by channel basis they would hike their charges hugely.
What most people don't realise is that the distributing companies get paid by the channel operators to transmit thier content. Less channels == less income for BSkyB.
Not only this, but by bundling the costs of the charging infrastructure are greatly reduced. It doesn't matter if the viewers don't want 200 knitting channels which spend 18 hours of the day as shopping or text a scantilly clad woman programmes as the advertising blurb can tell the punters that there are n channels available to them (where n is a large number). They can make the excuse for their high subscription charges as "Well, you are getting hundreds of channels for that money."
It's not in anyone in the media's interest, other than the old, higher quality channels, to restrict this "growth."
In the end the growth will be curtailed once the advertising revenue is spread so thinly and evenly that no more money is available to run any new services. It will also mean that over the x00 stations there will be nothing worth watching unless you're into cheap shows displaying the base values of the lowest common denominator. No-one will be able to afford to make any good programmes anymore, well, unless they're a premium channel only the rich can afford.
Thankfully, in the UK we do have the BBC which, although it has gone more for ratings than for quality over the last 15 or so years, is at least keeping the base quality level for the "main" channels higher. I'm sure that without it there would be far more programmes such as "The World's Greatest Dog Poo" on the other channels.
Slashdot Mirror
There are good technical reasons for there not being a driver 'ABI' for Linux. Reason #1 is that even the source 'API' is not set in stone (so the ABI has /0/ chance), to be able to update interfaces when needed rather than leaving bad interfaces in place for the sake of compatibility can be a good thing.
Oh, I see you bought that GoodFact(tm). on the same sort of level as "Ignorance is Strength" etc. (Read George Orwell's "1984" if you missed the reference.)
Hmm.. it's a great spin on the fact that there's neither the political will nor the appetite to paw over the kernel device driver interface and create a full, strict, detailed and fully thought out interface document to which the kernel and device drivers can be written and verified against and have it imposed on the kernel and driver developers.
Basically, it's an excuse to try to hide that the current kernel development is avoiding the problems of doing proper software engineering and is showing its hobbist roots, unfortunately.
I would like to see Linux succeed. However, the way it's going at the moment I can see it becoming an interesting footnote in history.
I'm sorry to burst your utopian bubble, but this will never ever happen.
Linux is too small a market for them to worry about and it will forever be so when Aunt May can't just plug in and go. The companies who prefer closed source will just ignore the small loss of ernings from the Linux crowd.
As for the reason for not designing a properly thought out, documented, standardised and unchanging (during the life of a major sub-version) driver interface just in case a commercial, closed source company may write a driver for it: Isn't this throwing the baby out with the bath water?
I'm afraid you're mistaken in this in the following way:-
If there were a standard ABI for drivers within a major release of Linux you could essentially disociate the drivers from the kernel. The driver development could then run on a totally different timescale to the core kernel with release dates as they wish.
It would also mean that the driver maintainers could release a binary version of their driver, which they have tested themselves (as well as releasing the source code for those who wish to look at the nitty gritty) so that the users can just install and go.
It would help the driver developers with support no end if one binary fits all kernel sub-versions and configurations.
On the point of closed-source/commercial drivers. They would only need to produce one version for everyone (rather than having to compile 15 different ones for each distribution and kernel release for each of those). This would make them FAR more likely to throw support at the problem as the money/time (same thing) they'd have to devote to the wasteful compile and package part of the business would be a whole lot less.
The problem is that some people in the free software business place idiology and self-interest over practicality (from the user viewpoint). The idiology being "if we make an ABI then the evil propriatory people will use it" and the self-interest being "if we don't specify an ABI then we can change out API on a whim." The second of those is probably the more important to the Linux developers as they seem to change the driver API within major releases quite a bit. (A number of drivers which compile on older 2.6 kernels won't anymore because the API has changed radically within the last few sub-releases.)
For the uptake and maintainability of Linux, this driver nightmare is the biggest drawback and it's nothing really to do with closed source at all.
I was talking more about scientific computing where there's no redraws or user interaction. Quite often in this sort of code the act of calling a subroutine/functionother than an intrinsic one (in FORTRAN) has such a high penalty that you wouldn't do it if you could help it. Some of these codes can run for months at a time, mostly in these sorts of tight computational loops, so you can see how optimising the hell out of them can shave days off a run.
When you're talking about GUI programming then, yes, doing intelligent redraws and updates will save huge amounts of work for the graphics system and hence speed things up. This is to do with the basc design of the code to begin with, mostly, rather than optimisation as such.
The only code segments you really have to worry about hand optimising are loops which happen a huge number of times.
In scientific computing, a loop which does most of the calculation and runs hundreds of thousands or maybe millions of times is the most critical to get right. After all, one millisecond lost per loop may mean a day's extra computation time.
A great deal of the optimisation has to be within the algorithm, making sure that you don't do unnecessary computation. However, some of it is to do with knowing how CPUs work. If you order the calculations in the correct way you can aid the compiler in its optimisation buy helping to work on data which is likely to be kept within the registers rather than flitting about and having to swap the values out to cache, or even worse, main memory.
I'm afraid I don't have a link. I was told about this system during my MSc in Comp Sci in '88-'89. Just a tad before the web became popular. :-)
As for the NOPs etc. I believe the exception causes CPU state data loss, hence you couldn't (easily) recover using a single processor. Also, yes, memory was VERY expensive, far more so than the cost of another processor.
I'm afraid that's pretty well all the information I have other than the board also runs Linux!
From what I remember, AmigaDOS was originally based on many of the ideas of Tripos. Indeed, at the commandline it's hard to tell the difference. (I've hacked about on a Tripos system using only my knowledge of AmigaDOS.)
However, AmigaDOS isn't a direct decendant of Tripos, though early versions of AmigaDOS were partly written in BCPL by Metacomco in Bristol, UK. on Sinclair QLs.
This early code was very quickly replaced subsiquently.
And the Sinclair QL had pre-emptive multitasking in 1984.. :-)
As for memory protection, the early 680xx (where xx is either 08, 00 or 10) series chips didn't have memory protection (for user processes) but they did have a rudimentry one for preventing user level code from accessing supervisor mode protected memory. However, this didn't help much as the 68000 and 68008 couldn't restart instructions after a memory fault exception. (There was one UNIX Version 7 system which used tandem 68000's which had one processor lag one intruction behind the first so that it could be used to restart the processing in the case of a memory fault.)
The 68010 had the ability to restart an instruction but no real MMU interface. it wasn't until the 68020 came out that, with the aid of an external MMU chip, a fully memory protected OS could be written. This was the basis of the very first Sun Microsystems machine.
Of course, it wasn't until the late 80's that anyone thought about putting these higher chips into mainstream machines and even later before anyone thought that memory protection and virtual was a really good idea on the desktop. (Even NT 4.0 had a single, shared flat memory space, though with memory protection and virtual paged memory extension.)
So, how modern is "modern"?
Well, it's very interesting about how the Amiga has managed to continue on in the back waters of computing for the last few years. However, it's not the only one!
Thos of you who remember the Sinclair QL (ie. people such as Linus Torvalds and some of the early AmigaDOS authors who worked at Metacomco) might like to know that some people are continuing the development of both the hardware and the operating system..
eg. Q40 and their latest Q60 motherboard designed to fit in a PC case.
What's old is new again!
Although for some, non-memory intensive, highly threaded applications multiple cores can be a boon, for many applications this won't be a boost in performance at all.
Remember that each of these processing cores will have to share their memory bandwidth and possibly level 2 cache as well. As it is Intel's EM64T Xeon processors really feel the bandwidth bottleneck in their memory interface and can easily saturate it.
I can see a dual core Xeon being able to saturate its memory bus on its own. Similarly, the dual core Opteron, unlike a dual processor Opteron, will have to share a single memory bus and hence be slower than a dual processor machine.
Adding extra cores merely moves the computing bottleneck elsewhere, it's not a panacea.
Ah, but that's witht he anti-crippling, warrenty busting firmware. And that still doesn't save the kit lens which is a bit naff. :-)
I agree that what I posted was a very great simplification (maybe over simplification? That's up to the reader to decide). However, it's not, in general a bad rule of thumb.
:-)
Of course, the cheapest type of camera, the pin-hole camera, has a huge depth of field (the image quality only dependent upon the circularity and size of the hole).
The Nikon D70 is often used by professionals as their second camera for doing "snap" type photographs.
Relative to the Canon 300D, the D70 is far less crippled than its stable mate. The main "cripple" points are the lack of the option to have an extended battery and portrait grip, "only" ISO 200 mode and a set of mirrors rather than prisms for the viewfinder. Oh, and the "kit" lens in the D70 kit is a pretty nice lens, unlike the toy lens in the 300D kit.
It is true that the D70/300D aren't in the same league as the D2X etc. but then again they're a third of the price. That doesn't make them bad cameras in the same way that the old Olympus OM10 was a pretty good hobbyist's camera and able to take pictures as good as an OM1 in the right hands.
I got a little way through this piece and came across a gross error which, for me, made the rest of the article of very dubious worth.
One of the reasons extolled at length for choosing one type against abother is that a DSLR has a narrow depth of field and a "standard" digital camera has a greater depth. As anyone who knows about photography would know this is total tosh.
The depth of field depends upon the aperture of the iris. A small aperture acts rather like a pinhole camera and hence will give a great depth of field. A large aperture relys upon the lens for focus and hence depends greatly on the focal length of the lens system giving critical focus and a very narrow depth of field.
Cheap "standard" digital cameras will usually have a small lens and small (fixed?) aperture hence a large depth of field. More expensive "standard" digital cameras are more sophisticated and allow the user to change the aperture and have a larger lens, so they can have a narrow depth of field.
Digital SLRs are totally dependant upon the lens system. However, because they have a variable iris within the lens systems they can have either a very wide depth of field (if they're stopped right down) or a very narrow depth of field (iris wide open). Both the end points of these will depend entirely on the characteristics of the lens systems.
How many people would accept an article which said that you shouldn't buy a 35mm SLR because you only get a narrow depth of field?
I think you've been playing Half-Life too long ;-)
So, what happens if you buy the game and don't have a phoneline or modem or any other way to connect to the authentication server?
I know it's not a usual situation but it is possible. Are you denied access to your property because you don't have internet access?
Dell have a problem in the HPC/multi-processor server market. The latest generation of Xeons, the EM64T 64bit capable x86 class processors can only currently go 2 way as Intel don't actually produce a 4 way chipset for these processors yet. Not only this but because the EM64T processors share a memory bus they soon run out of bandwidth.
This is a real problem for Dell as they can't produce machines with large, flat memory architectures with more than 2 processors, and even then the HPC (High Performance Computing) crowd are just laughing that their machines because of the price and memory bottleneck.
Dell are now seeing large cluster purchases abandoning them for other companies who can supply fat nodes which 16-32GB of RAM and 4 processors which have copious amounts of memory bandwidth 'cos of the cunning way AMD built the Opterons.
This is why, I believe, Dell are looking at adding AMD to their line. It may also be a cynical move to get Intel to do something but in the cluster space Intel's processors produce too much heat and just can't do 4 way+big memory and Dell are hurting.
The problem with MUDs/MUSHs/etc.etc.etc. these days is that players don't have to wait up 'til 2am to try to connect to an obscure computer housed in the south east of England via an X25 PAD using a long string of numbers and then try to use the small number of suspended connections before someone else did.
:-)
Hmmm..
PAD> CALL 0000 4960 0000 1
[2653,2653]
MIST
Ahhhh..
If newbies had this they'd be very happy with all the long-term good inovations.. as long as they didn't get instantly killed by an archwiz with a chip on their shoulder, that is.
I can only see the merging of WiFi and GSM if hell freezes over or when the telcos can charge for both the use of the GSM part of the connection and the WiFi.
With further thought, it will probably happen, but only for "public" access points being run by the telcos themselves allowing their slaves^H^H^H^H^H^Hcustomers to access higher speed data and possibly VoIP services when in range of their own hotspots.
The problems of hand-over of an IP connection to a cellular network are non-trivial as well, which would make it far more likely that it will only be teleco owned and run hotspots which will be able to do this.. at a large per megabyte cost, no doubt. (Probably the same as they charge for GSM data transfer. In the UK that's about £3 a megabyte!)
I believe that it is the law in England (and Wales) that if you know of a criminal act taking place then if you do not report it to the police then you are deemed to be an accessory after the fact and have hence committed a criminal act yourself.
Therefore, once the University was informed of the criminal acts (breach of the Computer Misuse Act) they had to inform the police. They had no choice in the matter.
Well, who would have known that such a great oak would grow from such as small acorn
Maybe it was due to all those electrons and atoms with a little help from archimedes.
Of course, you can merely get Solaris 10 x86 when it comes out then you can use the Opteron box if you want to.
I wonder if there'll be a convenient toilet break in the middle so they can change media.
That's the best bit of the Extended Edition DVDs.
If programme distributors, such as Rupert Murdoch's BSkyB operation in the UK, were forced to sell their wears on a channel by channel basis they would hike their charges hugely.
What most people don't realise is that the distributing companies get paid by the channel operators to transmit thier content. Less channels == less income for BSkyB.
Not only this, but by bundling the costs of the charging infrastructure are greatly reduced. It doesn't matter if the viewers don't want 200 knitting channels which spend 18 hours of the day as shopping or text a scantilly clad woman programmes as the advertising blurb can tell the punters that there are n channels available to them (where n is a large number). They can make the excuse for their high subscription charges as "Well, you are getting hundreds of channels for that money."
It's not in anyone in the media's interest, other than the old, higher quality channels, to restrict this "growth."
In the end the growth will be curtailed once the advertising revenue is spread so thinly and evenly that no more money is available to run any new services. It will also mean that over the x00 stations there will be nothing worth watching unless you're into cheap shows displaying the base values of the lowest common denominator. No-one will be able to afford to make any good programmes anymore, well, unless they're a premium channel only the rich can afford.
Thankfully, in the UK we do have the BBC which, although it has gone more for ratings than for quality over the last 15 or so years, is at least keeping the base quality level for the "main" channels higher. I'm sure that without it there would be far more programmes such as "The World's Greatest Dog Poo" on the other channels.