Except when the kernel driver is ophaned, such as happened with the Advansys SCSI host adaptor. All that happened was that it was removed from the standard build configuration and the code didn't compile anymore.
The problem with a kernel driver interface which changes between major versions is the problem of having to udate huge numbers of drivers AT THE SAME TIME possibly adding typographical bugs in that codebase. The more you have to change, the more likely such errors will creep in.
I'm not saying never change the kernel driver interface but only change it with major kernel version change.
(And no, I don't buy the arguments in the document referenced in the grandparent posting.)
Actually, the BBC and Panorama in particular *USED* to be OK a very long time ago in the 1970's and early 80s, before Margaret Thatcher decided that the BBC should take note of ratings (because otherwise the license fee paying public weren't getting what they wanted, which translates to "because the BBC aren't catering for the lowest common denominator).
Similarly, before the BBC started making "Horizon" programmes with the direct intent to sell them to US cable "infotainment" channels and to make them populatist (oh, and giving editorial control to lovies rather than those with a scientific background) that programme was informative, for me interesting and useful. Today it's a formula of "crank up the disaster, build up the problem's solution, knock the solution down" all in nice 5 minute bites with much repetition and flashy graphics (and usually dodgy, nausiating camera work) and with the total content which could be given in 10 minutes spread out over the 45 minute length.
I've given up on the BBC's "factual" programming I'm afraid.
This was a time when there were huge numbers of different network address formats which had to have mail routed to/from/between. That's why it's all about rewriting addresses and not about processing the message. It is also why it's so complex as it had to be flexible enough to handle IP, Usenet (i.e. bang paths), reversed domain-type addressing so you needed a complex language to deal with it.)
Remember also, this was an age before the virus and when the most malicious thing was the war dialler or phone phreaker with his trusty 300baud accoustic coupler modem. Built in security and thinking about buffer overflows weren't really even in the background of the programmers minds back then.
Times have changed, hence Sendmail just isn't an appropriate tool anymore, just like the stage coach. It doesn't mean that it's bad software.
You have to feel for the poor mobile telcos.. They have to work so hard supporting a number of operating systems on phones so that they can hobble them and make sure that their customers are wrung of every penny they can be.
Now, instead of crying about possible missed new lock-ins because it's too much effort to write the shackling software they should just shut-up and let the phone makers produce phones that the public want rather than those designed purely for the mobile telco's mean, narrow minded, penny pinching marketing departments.
There are two segments of the iPone's potential market who will now think again about purchasing this device if they can't load their own apps onto it:
(1) Businesses.
Many big businesses would like to load bespoke apps and/or specific (say Cisco only) VPN clients etc. onto the devices their field operatives use so that they can access the corporate network applications securely etc. If they're not allowed to develop and/or install these then they'll go elsewhere, however pretty and useable the device.
(2) Sysadmins
Sysadmins generally use their smartphones slightly differently to the rest of the smartphone community. For one they'd want/need a terminal program (ANSI complient) with full shell access or at least a working ssh client. If they can't install on of these then they'll probably think twice, even if it is shiney-shiney.
Still, I'm not sure that this is the target audience Apple is looking for, but then again it's the audience who are currently buying smartphones!
Of course, if the target audience is the fashion concious "iPod Generation(tm)" then I'm sure that a device onto which they can load 3rd party games would also be more attractive.
In some ways, yes, I can see the hand of the mobile telco possibly in this. The trouble with the phone industry is that the customers who are always right are not to poor saps who buy and use the devices, it's the telcos. What the telcos don't want the users don't get. Not only this but there's self censorship within the manufacturers so they only produce what they *THINK* the telcos will want to promote and sell.
The iPhone *MAY* help with changing the phone market's competition, but I only see it doing so with respect to the user interface. It's definitely not going to change the market so that it's user driven. The customers the manufacturers will have to please will still be the telcos and not the users of the devices.
The biggest problem I see for Apple (other than getting to use the trademark "iPhone") is to change the current general consumer culture/expectation.
At least in the UK the vast majority of mobile phone users expect to get their phone for "free" and change it every year. With the iPhone costing rather more than "free" by a couple of magnitudes it poses a problem.
What Apple does have in its favour is that it has a high profile consumer brand which is perceived as "cool" by just the sort of person who "buys" the disposable phones currently. This same consumer group would probably pay of a convergent device if (and only if) it is seen as a new "cool" product which is a fashion item. That it's compatible with their old iPod is a major bonus.
The big problem for Apple in Europe is the lack of 3G and MMS and the extortionate data call prices the telcos charge their customers. Unless they can fix these problem before the European launch it would make seeling the device here extremely difficult.
The problem with all these sedimentological studies is that the statistical period between large meteorite impacts and the systematic error in the dating of the sediments (using isotopic geochemistry) in addition to the ambiguity in the fossil record (and the dating errors in those sediments) means that it's guaranteed that you will find a correlation between any mass extinction and a large meteorite impact event.
Around the K-T boundery there is not only the Chixalub impact but a large one in Germany and a couple of others which have been discovered, all within the dating error. Add to this that there's also the Decan Traps flood basalts being errupted, ocean currents changing as the north atlantic starts to open and the amount of flooded continental shelf decreasing hugely and you have several possible smoking guns.
The evidence just isn't there currently to say why most of the dinosaur lineages died out (along with many sea reptiles and other oceanic creatures). In fact there is still a doubt as to when it actually happened and over how long a period. Ammonites, it seems, saw the meteorite coming.. about a million years before it hit.
It depends upon which Nikon DSLR you're looking at as to whether they will accept the type of lens that you have.
The D70 will take all AI lenses and newer, the D200 will also allow you to use your old manual focus lenses (up to a point). I think the cut-off point is generally the lenes made around 1970.
(The Canon cameras will also take older SLR lenses but I believe that the ones that they accept are more restrictive.)
As for the RAW formats, well, each camera seems to have a new revision of the specification, this is both Nikon and Canon. The newer Nikon specifications encrypt their light balance data for some unknown reason and the latest version adds a cryptographic signature to "prove" that the image hasn't been tampered with. There is also, since the D200, a compressed raw format which uses a slightly lossy compression.
You should also note that what each of the manufacturers consider as raw data from their camera is different. The Canon cameras do far more image processing on the camera before writing the raw file than the Nikon cameras, such as sharpening and colour "enhancement" whereas the Nikons generally strip the bottom 4 bits off the bottom of the 16 bit output from the sensor (which is below the noise threshhold of the Sony sensor) before creating the NEF file without any other processing.
Someone above said that Canon use 32bits per pixel per channel in their raw format.. well, at the moment there are no 32bit sensors out there, so I think he's a bit of a Canon fan-boy. Even Canon's sensor only really generates 12-14 bits of usable image data.
I'm afraid that the situation over here in Europe is almost as locked down as in the 'states.
The mobile phone companies sell their own locked phones to the consumers at discounted prices, with hobbled firmware on board, just as you describe. There is a big market for phone unlocking here to allow people to use their phone on other networks.
You can buy the generic, unlocked products but you will have to go to a speciallist retailer on the 'net to do so. The firmware will still be knobbled but only to the generic brokenness that the manufacturers know that all phone companies will demand. (Why build a phone which can do X if you know that there will be no big customers which will allow X to be used?)
As for the iPhone, well unless it's sold without a contract at a price the bloke in the pub will want to pay (probably no more than the price of a normal iPod, or less as consumers expect phones to almost cost nothing) then it's dead in the water as far as mass sales are concerned.
Most of the original games from the early 80's will not hold up to much scrutiny at all, mostly due to the limitations of the systems at the time and hence the limitations of game play. (e.g. Space Invaders, each level was basically the same but faster, etc.)
A few really ground breaking ones still shine a light into the darkness, e.g. Elite.
Now, on a BBC micro (2MHz? 6502) with about 10-12K free after the video memory had eaten into the 32K of RAM you had an open ended, fully 3D space faring and trading game (with one or two "missions"). Now that was a miracle.
Today, in this time of tightly scripted games where your complete journey from the point you boot the game up until the end titles is so firmly in the hands of the developers that it feels like a straight jacket I miss that freedom.
Of course, today you could do the game better, maybe multi-player and using the strong anthopic principle to generate the universe (at the detail necessary at the time) on the fly.. add inter-user commerce and it'd be a whole world of its own. The important thing though would be that other than the possibility of a large backstory arc taking place in the background, there should be no scripted story.
Further, remember, playability (and one or two people's vision) were the key. Today it's a boardroom committee and accountants who are pulling the strings in the publishers with the games software houses picking up the crumbs and begging at the master's table. Hence, forget about innovation, it's just like the film industry, sequals and regurgitation rule.
If a citizen in one of the other countries is accused by the U.S.A. of committing a crime which isn't illegal in their country the same rules apply.
Even worse, in the U.K. they could be extradited without the evidence even having to be disclosed to a judge or anyone else due to a treaty (supposedly to be only for terrorist cases but recently used on a fraud charge) with the U.S.A. which the U.K. has ratified but the U.S.A. has refused to. Now, that's scary!
Or you could say "Anything you can run on Solaris you can run on Linux to some extent (DNS, DHCP, LDAP, Firewall, Apache, MySQL)." seeing as Solaris is older than Linux.:-)
Though on the subject at hand, I run a cluster of Sun v20z's (and 2 v40z's) which run Solaris 10 x86_64. On the whole it's no different to running one with Linux other than the Sun system management tools for clusters are not as advanced as some of the Linux cluster tools sold (yes, sold for lots of money and are closed source) by the Linux cluster specialists.
The Sun compilers generally produce faster than GCC and are pretty bullet-proof and can also cope with automatic parallelisation (if you're lucky). The only problem is that the majority of open source software these days has a great deal of GCC+Linux code in it which makes compilation "interesting." (It used to be in the early-mid 90's that lots of code had SunOS-isms in it which meant compiling it on early versions of Linux was "interesting." How times have changed.:-))
On the whole, though, once you have set up the login environment properly, have installed all the GNU utilities etc. a user won't see much, if any, difference at the shell or general scientific programming level.
I've just bought an Apple refurbished iBook G4 12" (1.3GHz) in preference to the new Macbook. I had the following reasons:
(1) I hate the current crop of glossy screens. When you are in a location with multiple bright light sources close to eye level it's very difficult to use the screen. (2) I'm not keen on the "Casio calculator" keyboard. (3) The iBook's smaller, has a slightly better battery life and runs cooler. (4) I don't need processor speed for what I want to do with the machine. (5) I don't trust first generation Apple machines.:-) (6) They are more expensive.
At least in the laptop/notebook arena, speed isn't everything.
Well, there should have been a way to clean it up. i.e.
(1) Boot into another OS which can read and write to the infected filesystem but is immune to the malware. (2) Do a complete check of all the OS files and any drivers/DLLs called during boot and delete/replace as necessary. (3) Do a complete virus/malware scan on the rest of the files. (4) Clean the registry thoroughly. (5) Reboot the newly cleansed system.
It's a pity that Microsoft don't produce a bootable image with a version of MSDOS containing a basic NTFS filesystem driver and some automated tools to do all of the above. It's technically possible.
Trying to clean a compromised OS while it's running is a losing battle. It's not even worth bothering to try.
Considering everyone wants faster CPUs and higher benchmarks, the answer is "yes"
Not everyone.
I'd prefer a smaller, slower, cooler, quieter machine over a desktop replacement which roasts your thighs.
For that the old iBook 12" was ideal. It did most things sufficiently quickly, especially if you put enough memory into it, had an extended battery life, was compact and was cool and quiet. Oh and it didn't have a calculator keyboard or a highly reflective screen.
Firstly, it's bigger than the old iBook 12" which makes this machine far less attractive to me for what I'd use it for. (And it's got a shorter battery life than the iBook 12" another minus point.)
Secondly, the screen. If it's anything like the Sony Vaio ones I've seen then this is the biggest step backward in screen design in years. In the lab I've been (trying) to use the machine which has multiple windows on three sides it's hard to see anything usefully and I'd definitely not want to use it for long periods. It's a a headache waiting to happen.
Thirdly, the keyboard. OK, it may look more stylish (or do I mean stylised?). It definitely looks cheaper to make.
I've been hoping that the iBook wasn't replaced until I had saved up enough to get one for a trip I'm taking in September where I merely need a small laptop which could be used as a digital photo repository and some net use. I don't need extra horsepower but I do need a compact machine with a good battery life and a screen which can be used outside. I know the old 12" iBook can satisfy those goals (I've borrowed one and tried) but from what I've seen the new machine can't. Oh well.
Laptop ACPI tables are the buggiest seen. It's quite common that the laptop designers have used the Microsoft com[iler which has let a whole slew of things which should have been syntax errors get through. Because the Microsoft interpretor is as lax as the compiler Windows will work with it but Linux will often barf on it. This can be anywhere from a mere annoyance to making power management or hardwre operation difficult/buggy/broken.
(2) WiFi
MiniPCI cards, even with the same chipset, may not work with the same driver. If you have a chipset which works under ndiswrapper make sure that you use the Windows driver which comes with your machine and not a generic one.
(3) Power management
It pretty likely that the Linux suspend/resume to disk or memory won't work. Again, the manufacturers play fast and loose and only test to see if it works the Windows way and not the correct way.
(4) The big manufacturers don't care about Linux
If you give bug reports about their hardware they'll just laugh and tell you that it works with Windows.
Linux on a laptop will generally work as long as you don't mind missing out on a few things, such as suspend to disk or memory etc.
If I were you and wanted a *nix for the road I'd not choose Linux I'd go for a MacBook as the OS and hardware are well integrated... oh and most Linux distributions' WiFi administration is a pain to use (unless you like hacking text files for each hotspot).
The main problem is that there are so many different drivers in the kernel tree, each of which has to be tweeked every time there's an internal API change with each tweek giving the possibility of a typo or some other bug creeping in. Large numbers of drivers in the kernel tree will currently either not compile or won't work properly because their maintainers either can't keep up or aren't there any more.
If the API is stable then the overall number of edits to the kernel source will go down with the consiquence of the number of potential new bugs being introduced going down as well. Not only this, but a driver, once fully debugged, need not be messed with until the next major release of the kernel which adds to both stability and the lessening of the workload on the kernel maintainers.
Commercial, binary-only drivers (which this wasn't about) or even open sourced drivers are the least of the worries.
There needs to be a stable API for drivers PER MAJOR RELEASE so that the driver maintainers can keep stable, well tested and debugged drivers.
The API should be allowed to change with every major kernel revision but any change should be made with a great deal of thought and, unless it's very difficult to do, the old API should be supported for backward compatability.
Not only this, but I would argue that it would be good hygene to separate the core kernel from the drivers. Doing this would make developers think hard about the bounderies between the two and not have one polluting the other. It would also make the developers think long and hard about whether changing the API for something is such a good idea just because it would be useful for the "ACME USB SLi Graphics card programming port widget" interface.
The the kernel is the kernel, the drivers are merely plug-ins to virtualise the hardware, the two should be as separate and distinct as they are logically.
Slashdot Mirror
Except when the kernel driver is ophaned, such as happened with the Advansys SCSI host adaptor. All that happened was that it was removed from the standard build configuration and the code didn't compile anymore.
The problem with a kernel driver interface which changes between major versions is the problem of having to udate huge numbers of drivers AT THE SAME TIME possibly adding typographical bugs in that codebase. The more you have to change, the more likely such errors will creep in.
I'm not saying never change the kernel driver interface but only change it with major kernel version change.
(And no, I don't buy the arguments in the document referenced in the grandparent posting.)
Actually, the BBC and Panorama in particular *USED* to be OK a very long time ago in the 1970's and early 80s, before Margaret Thatcher decided that the BBC should take note of ratings (because otherwise the license fee paying public weren't getting what they wanted, which translates to "because the BBC aren't catering for the lowest common denominator).
Similarly, before the BBC started making "Horizon" programmes with the direct intent to sell them to US cable "infotainment" channels and to make them populatist (oh, and giving editorial control to lovies rather than those with a scientific background) that programme was informative, for me interesting and useful. Today it's a formula of "crank up the disaster, build up the problem's solution, knock the solution down" all in nice 5 minute bites with much repetition and flashy graphics (and usually dodgy, nausiating camera work) and with the total content which could be given in 10 minutes spread out over the 45 minute length.
I've given up on the BBC's "factual" programming I'm afraid.
Sendmail was the right tool for its time.
This was a time when there were huge numbers of different network address formats which had to have mail routed to/from/between. That's why it's all about rewriting addresses and not about processing the message. It is also why it's so complex as it had to be flexible enough to handle IP, Usenet (i.e. bang paths), reversed domain-type addressing so you needed a complex language to deal with it.)
Remember also, this was an age before the virus and when the most malicious thing was the war dialler or phone phreaker with his trusty 300baud accoustic coupler modem. Built in security and thinking about buffer overflows weren't really even in the background of the programmers minds back then.
Times have changed, hence Sendmail just isn't an appropriate tool anymore, just like the stage coach. It doesn't mean that it's bad software.
Ah, but to begin with it was more a fight between the SIC^H^H^HVIC-20 fanboys and the Spectrum fanboys as the C-64 came along a little later. :-)
You have to feel for the poor mobile telcos.. They have to work so hard supporting a number of operating systems on phones so that they can hobble them and make sure that their customers are wrung of every penny they can be.
Now, instead of crying about possible missed new lock-ins because it's too much effort to write the shackling software they should just shut-up and let the phone makers produce phones that the public want rather than those designed purely for the mobile telco's mean, narrow minded, penny pinching marketing departments.
The actual announcment of these films was a few months back and they're going to be TV movies for the SciFi channel. For more details browse ISN.
There are two segments of the iPone's potential market who will now think again about purchasing this device if they can't load their own apps onto it:
(1) Businesses.
Many big businesses would like to load bespoke apps and/or specific (say Cisco only) VPN clients etc. onto the devices their field operatives use so that they can access the corporate network applications securely etc. If they're not allowed to develop and/or install these then they'll go elsewhere, however pretty and useable the device.
(2) Sysadmins
Sysadmins generally use their smartphones slightly differently to the rest of the smartphone community. For one they'd want/need a terminal program (ANSI complient) with full shell access or at least a working ssh client. If they can't install on of these then they'll probably think twice, even if it is shiney-shiney.
Still, I'm not sure that this is the target audience Apple is looking for, but then again it's the audience who are currently buying smartphones!
Of course, if the target audience is the fashion concious "iPod Generation(tm)" then I'm sure that a device onto which they can load 3rd party games would also be more attractive.
In some ways, yes, I can see the hand of the mobile telco possibly in this. The trouble with the phone industry is that the customers who are always right are not to poor saps who buy and use the devices, it's the telcos. What the telcos don't want the users don't get. Not only this but there's self censorship within the manufacturers so they only produce what they *THINK* the telcos will want to promote and sell.
The iPhone *MAY* help with changing the phone market's competition, but I only see it doing so with respect to the user interface. It's definitely not going to change the market so that it's user driven. The customers the manufacturers will have to please will still be the telcos and not the users of the devices.
The biggest problem I see for Apple (other than getting to use the trademark "iPhone") is to change the current general consumer culture/expectation.
At least in the UK the vast majority of mobile phone users expect to get their phone for "free" and change it every year. With the iPhone costing rather more than "free" by a couple of magnitudes it poses a problem.
What Apple does have in its favour is that it has a high profile consumer brand which is perceived as "cool" by just the sort of person who "buys" the disposable phones currently. This same consumer group would probably pay of a convergent device if (and only if) it is seen as a new "cool" product which is a fashion item. That it's compatible with their old iPod is a major bonus.
The big problem for Apple in Europe is the lack of 3G and MMS and the extortionate data call prices the telcos charge their customers. Unless they can fix these problem before the European launch it would make seeling the device here extremely difficult.
The problem with all these sedimentological studies is that the statistical period between large meteorite impacts and the systematic error in the dating of the sediments (using isotopic geochemistry) in addition to the ambiguity in the fossil record (and the dating errors in those sediments) means that it's guaranteed that you will find a correlation between any mass extinction and a large meteorite impact event.
Around the K-T boundery there is not only the Chixalub impact but a large one in Germany and a couple of others which have been discovered, all within the dating error. Add to this that there's also the Decan Traps flood basalts being errupted, ocean currents changing as the north atlantic starts to open and the amount of flooded continental shelf decreasing hugely and you have several possible smoking guns.
The evidence just isn't there currently to say why most of the dinosaur lineages died out (along with many sea reptiles and other oceanic creatures). In fact there is still a doubt as to when it actually happened and over how long a period. Ammonites, it seems, saw the meteorite coming.. about a million years before it hit.
It depends upon which Nikon DSLR you're looking at as to whether they will accept the type of lens that you have.
The D70 will take all AI lenses and newer, the D200 will also allow you to use your old manual focus lenses (up to a point). I think the cut-off point is generally the lenes made around 1970.
(The Canon cameras will also take older SLR lenses but I believe that the ones that they accept are more restrictive.)
As for the RAW formats, well, each camera seems to have a new revision of the specification, this is both Nikon and Canon. The newer Nikon specifications encrypt their light balance data for some unknown reason and the latest version adds a cryptographic signature to "prove" that the image hasn't been tampered with. There is also, since the D200, a compressed raw format which uses a slightly lossy compression.
You should also note that what each of the manufacturers consider as raw data from their camera is different. The Canon cameras do far more image processing on the camera before writing the raw file than the Nikon cameras, such as sharpening and colour "enhancement" whereas the Nikons generally strip the bottom 4 bits off the bottom of the 16 bit output from the sensor (which is below the noise threshhold of the Sony sensor) before creating the NEF file without any other processing.
Someone above said that Canon use 32bits per pixel per channel in their raw format.. well, at the moment there are no 32bit sensors out there, so I think he's a bit of a Canon fan-boy. Even Canon's sensor only really generates 12-14 bits of usable image data.
I hope that this helps.
A good forum for all digital camera stuff is Digital Photography Review, or at least the site's forums. The people who use it are all pretty helpful.
Nah.. Slashdot isn't unbalanced it's dynamically stabilised, just like a Segway!
I'm afraid that the situation over here in Europe is almost as locked down as in the 'states.
The mobile phone companies sell their own locked phones to the consumers at discounted prices, with hobbled firmware on board, just as you describe. There is a big market for phone unlocking here to allow people to use their phone on other networks.
You can buy the generic, unlocked products but you will have to go to a speciallist retailer on the 'net to do so. The firmware will still be knobbled but only to the generic brokenness that the manufacturers know that all phone companies will demand. (Why build a phone which can do X if you know that there will be no big customers which will allow X to be used?)
As for the iPhone, well unless it's sold without a contract at a price the bloke in the pub will want to pay (probably no more than the price of a normal iPod, or less as consumers expect phones to almost cost nothing) then it's dead in the water as far as mass sales are concerned.
Ah, yes, FORTH.... what a wonderful write-only language that is! I remember it on the venerable Camputers Jupiter Ace.
;-)
Anyway, there's the obligatory Slashdot...
May the FORTH be with you!
Most of the original games from the early 80's will not hold up to much scrutiny at all, mostly due to the limitations of the systems at the time and hence the limitations of game play. (e.g. Space Invaders, each level was basically the same but faster, etc.)
A few really ground breaking ones still shine a light into the darkness, e.g. Elite.
Now, on a BBC micro (2MHz? 6502) with about 10-12K free after the video memory had eaten into the 32K of RAM you had an open ended, fully 3D space faring and trading game (with one or two "missions"). Now that was a miracle.
Today, in this time of tightly scripted games where your complete journey from the point you boot the game up until the end titles is so firmly in the hands of the developers that it feels like a straight jacket I miss that freedom.
Of course, today you could do the game better, maybe multi-player and using the strong anthopic principle to generate the universe (at the detail necessary at the time) on the fly.. add inter-user commerce and it'd be a whole world of its own. The important thing though would be that other than the possibility of a large backstory arc taking place in the background, there should be no scripted story.
Further, remember, playability (and one or two people's vision) were the key. Today it's a boardroom committee and accountants who are pulling the strings in the publishers with the games software houses picking up the crumbs and begging at the master's table. Hence, forget about innovation, it's just like the film industry, sequals and regurgitation rule.
If a citizen in one of the other countries is accused by the U.S.A. of committing a crime which isn't illegal in their country the same rules apply.
Even worse, in the U.K. they could be extradited without the evidence even having to be disclosed to a judge or anyone else due to a treaty (supposedly to be only for terrorist cases but recently used on a fraud charge) with the U.S.A. which the U.K. has ratified but the U.S.A. has refused to. Now, that's scary!
Or you could say "Anything you can run on Solaris you can run on Linux to some extent (DNS, DHCP, LDAP, Firewall, Apache, MySQL)." seeing as Solaris is older than Linux. :-)
:-))
Though on the subject at hand, I run a cluster of Sun v20z's (and 2 v40z's) which run Solaris 10 x86_64. On the whole it's no different to running one with Linux other than the Sun system management tools for clusters are not as advanced as some of the Linux cluster tools sold (yes, sold for lots of money and are closed source) by the Linux cluster specialists.
The Sun compilers generally produce faster than GCC and are pretty bullet-proof and can also cope with automatic parallelisation (if you're lucky). The only problem is that the majority of open source software these days has a great deal of GCC+Linux code in it which makes compilation "interesting." (It used to be in the early-mid 90's that lots of code had SunOS-isms in it which meant compiling it on early versions of Linux was "interesting." How times have changed.
On the whole, though, once you have set up the login environment properly, have installed all the GNU utilities etc. a user won't see much, if any, difference at the shell or general scientific programming level.
I've just bought an Apple refurbished iBook G4 12" (1.3GHz) in preference to the new Macbook. I had the following reasons:
:-)
(1) I hate the current crop of glossy screens. When you are in a location with multiple bright light sources close to eye level it's very difficult to use the screen.
(2) I'm not keen on the "Casio calculator" keyboard.
(3) The iBook's smaller, has a slightly better battery life and runs cooler.
(4) I don't need processor speed for what I want to do with the machine.
(5) I don't trust first generation Apple machines.
(6) They are more expensive.
At least in the laptop/notebook arena, speed isn't everything.
Well, there should have been a way to clean it up. i.e.
(1) Boot into another OS which can read and write to the infected filesystem but is immune to the malware.
(2) Do a complete check of all the OS files and any drivers/DLLs called during boot and delete/replace as necessary.
(3) Do a complete virus/malware scan on the rest of the files.
(4) Clean the registry thoroughly.
(5) Reboot the newly cleansed system.
It's a pity that Microsoft don't produce a bootable image with a version of MSDOS containing a basic NTFS filesystem driver and some automated tools to do all of the above. It's technically possible.
Trying to clean a compromised OS while it's running is a losing battle. It's not even worth bothering to try.
Yes, but more importantly, how do you emulate the far more useful centre button? :-)
Considering everyone wants faster CPUs and higher benchmarks, the answer is "yes"
Not everyone.
I'd prefer a smaller, slower, cooler, quieter machine over a desktop replacement which roasts your thighs.
For that the old iBook 12" was ideal. It did most things sufficiently quickly, especially if you put enough memory into it, had an extended battery life, was compact and was cool and quiet. Oh and it didn't have a calculator keyboard or a highly reflective screen.
So am I. (Disappointed that is.)
Firstly, it's bigger than the old iBook 12" which makes this machine far less attractive to me for what I'd use it for. (And it's got a shorter battery life than the iBook 12" another minus point.)
Secondly, the screen. If it's anything like the Sony Vaio ones I've seen then this is the biggest step backward in screen design in years. In the lab I've been (trying) to use the machine which has multiple windows on three sides it's hard to see anything usefully and I'd definitely not want to use it for long periods. It's a a headache waiting to happen.
Thirdly, the keyboard. OK, it may look more stylish (or do I mean stylised?). It definitely looks cheaper to make.
I've been hoping that the iBook wasn't replaced until I had saved up enough to get one for a trip I'm taking in September where I merely need a small laptop which could be used as a digital photo repository and some net use. I don't need extra horsepower but I do need a compact machine with a good battery life and a screen which can be used outside. I know the old 12" iBook can satisfy those goals (I've borrowed one and tried) but from what I've seen the new machine can't. Oh well.
(1) ACPI
Laptop ACPI tables are the buggiest seen. It's quite common that the laptop designers have used the Microsoft com[iler which has let a whole slew of things which should have been syntax errors get through. Because the Microsoft interpretor is as lax as the compiler Windows will work with it but Linux will often barf on it. This can be anywhere from a mere annoyance to making power management or hardwre operation difficult/buggy/broken.
(2) WiFi
MiniPCI cards, even with the same chipset, may not work with the same driver. If you have a chipset which works under ndiswrapper make sure that you use the Windows driver which comes with your machine and not a generic one.
(3) Power management
It pretty likely that the Linux suspend/resume to disk or memory won't work. Again, the manufacturers play fast and loose and only test to see if it works the Windows way and not the correct way.
(4) The big manufacturers don't care about Linux
If you give bug reports about their hardware they'll just laugh and tell you that it works with Windows.
Linux on a laptop will generally work as long as you don't mind missing out on a few things, such as suspend to disk or memory etc.
If I were you and wanted a *nix for the road I'd not choose Linux I'd go for a MacBook as the OS and hardware are well integrated... oh and most Linux distributions' WiFi administration is a pain to use (unless you like hacking text files for each hotspot).
The main problem is that there are so many different drivers in the kernel tree, each of which has to be tweeked every time there's an internal API change with each tweek giving the possibility of a typo or some other bug creeping in. Large numbers of drivers in the kernel tree will currently either not compile or won't work properly because their maintainers either can't keep up or aren't there any more.
If the API is stable then the overall number of edits to the kernel source will go down with the consiquence of the number of potential new bugs being introduced going down as well. Not only this, but a driver, once fully debugged, need not be messed with until the next major release of the kernel which adds to both stability and the lessening of the workload on the kernel maintainers.
Commercial, binary-only drivers (which this wasn't about) or even open sourced drivers are the least of the worries.
I disagree.. mostly.
There needs to be a stable API for drivers PER MAJOR RELEASE so that the driver maintainers can keep stable, well tested and debugged drivers.
The API should be allowed to change with every major kernel revision but any change should be made with a great deal of thought and, unless it's very difficult to do, the old API should be supported for backward compatability.
Not only this, but I would argue that it would be good hygene to separate the core kernel from the drivers. Doing this would make developers think hard about the bounderies between the two and not have one polluting the other. It would also make the developers think long and hard about whether changing the API for something is such a good idea just because it would be useful for the "ACME USB SLi Graphics card programming port widget" interface.
The the kernel is the kernel, the drivers are merely plug-ins to virtualise the hardware, the two should be as separate and distinct as they are logically.