If earlier versions of Linux are good enough for your old 386-25, why not keep using it?
Was - the 386 is long gone, although I have a great little 486 doing some minor chores right now. And then answer to your question was in my post, if you'd only read it - maintainence, mainly security updates. In comparison to proprietary alternatives, of course, Linux is great on this issue, but no distro and no kernel is maintained forever.
And just to be clear, Linux was my main desktop OS for several years too, and I'm not knocking it at that. The only reason I haven't used it for that is that my main desktop for work is now my TiBook. The windows box is and has always been a gaming machine. For every purpose the best tool... at the moment. I'd actually rather run LinuxPPC on my TiBook, but the applications I need for work won't run on it, so there you go.
But considering that the vast majority of Linux boxes are, and are likely to continue to be for the forseeable future, headless uniprocessor servers, doesn't it make more sense to, if not optimise for those, at the very least take care not to de-optimise for those installations? That really seems to be what's been happening.
While I most agree with you, and usually buy AMD, it has been my experience that AMDs are not as reliable. Reliable enough, usually, but... I've had two fail, while I've never had an Intel chip fail. And before you think that's just because I use more AMD chips, that's actually not true - I usually buy AMDs brand new, but I've used a lot of Intels, gotten secondhand for free or cheap. So all things being equal you'd think the Intels would have failed more often for me.
Oh well, anecdotal evidence of course, so not worth much... but Intel chips have had the capability to turn themselves off when they are in danger of heat damage, which last I heard AMD still won't do. For most purposes AMDs are still better value, but I think there's a reason to buy Intel sometimes as well.
This aspect is improved across the board in 2.6, as well as the SMP issues. Sure, the uniprocessor machine may be a little slower, but response latencies in X are a lot better, and this makes more of a difference to users.
I beg to differ. I couldn't care less about X, I haven't even used it in over a year. Like the vast majority of Linux boxes, mine runs in console mode only, and on a single processor. I, and the rest of the world that uses it like this, find it hard to see anything to get excited about in 2.6. It could be that misty thing that happens with your memory over time, but it certainly seems like my first linux box (slack 1 on a 386-25) had better performance than I get now with substantially more powerful hardware in fact. At the very least I'm certainly not seeing any dramatic improvements. I used to upgrade kernels as a matter of course, but now I just don't care, unless there is a security update involved. If it weren't that necessary maintainence work (security patches, in particular) were suspended long ago I'd be tempted to swap in a fresh drive and give it a try, in fact.
Like I say, it's nice to see SMP support getting better, I've got nothing against it, or any of the other features that have been introduced over the years, but when it starts interfering with performance on the machines that need performance the most, and coincidentally the ones that account for the vast majority of boxes running Linux as well, there is obviously something going wrong. Maybe the config scripts need more work, maybe there is nothing to do but fork large sections of the kernel, I don't know, but if Linux keeps getting worse at fulfilling its bread-and-butter role it will eventually have to be replaced with something else.
Do you really want to see Linux running on Minicomputer class machines (the kind that private citizens usually can't afford) exclusively, at the expense of being usable in its traditional role of turning cheap old boxes on their way out the door into powerful and stable servers? Does Linus?
I don't, and I predict there are enough programmers out there that agree with me that if the trajectory continues we'll eventually see either a kernel fork, or a mass migration to *BSD, or both.
It was actually used in a number of different designs.
It was designed as a terminal controller for CTC (later became Datapoint) but it seems they never actually used it. According to this post it was developed not by Intel but by CTC themselves, for use in the Datapoint 2200, which however wound up shipping without it and never used it. A firm called Traf-O-Data is said to have used it in a microcomputer designed to record highway traffic flow. The same year that this Canadian micro came out (1973), a French company called R2E used this in their Micral-N which has been credited as the first commercial, non-kit microcomputer. In the US, Scelbi Computer Consulting Company used it in Scelbi 8h, credited with being the first microcomputer available in the US. It was used in the Mark-8 micro, a design that was never mass produced but built instead by hobbyists from a published design - it appears less than 400 of them were ever made. MITS, described by one source as a dying calculator company, but apparently the same MITS that brought out the Altair a few years later, is said to have bought a large batch of them from Intel, planning to revive their business by building a large batch of cheap microcomputers with it, but I can't find any reference to them ever actually selling a computer based on this chip. Might be an interesting story for someone with the time to track it down. The NBI Hantu word processor used this chip.
Well that's enough for me, if you're interested this post should give you a ton of keywords to search for more data on.
I've got nothing against Linux improving at SMP in essence, but there is something very bad going on here it seems to me. Notice that while the new kernel 'kicks ass' on SMP systems, on uniprocessor systems the 2.4 kernel is the one kicking ass. Anyone benchmarked 2.4 against some of the pre-SMP kernels on a uniprocessor machine?
Face it, the vast majority of users are uniprocessor, and kernel performance is more of an issue on lower-end machines. Improving performance on big multiprocessor boxes is fine by itself, but not when it harms uniprocessor performance. I'm not a kernel hacker, but I've read many people that this would not happen, that the SMP code would not hurt performance on a uniprocessor machine when the kernel is compiled without it, but that's obviously not turning out to be the case. Anecdotal evidence, at least, suggests that this performance degradation has actually been going on for quite some time, at least back to when SMP code first started being added.
I'm not sure what all the factors here are, so naturally I'm not going to tell you the solution, but it certainly looks like a potential problem that should be discussed. Hopefully someone with more specifics than I have can chime in...
This is a common misconception. Do a little research. Fluoride as a topical treatment is effective, because when it comes in contact with the outer calcium material of the tooth it hardens it.
However, when swallowed, it is toxic to many of the bodies systems, in fact including the teeth.
That's all very nice, but Lindows is explicitly aimed at the folk that couldn't do that if you walked them through it. People that would figure all this out (or know that they needed to make a proper account in the first place, for that matter) aren't going to be using Lindows and are not the target audience for Lindows. They should ship it so that it runs with a user account and works properly that way out of the box.
That's your belief. Scientific evidence to support that belief is not in evidence, however.
Despite politically motivated statements to the contrary by some politically funded researchers with obvious interest in spinning things that way, the evidence suggests instead that human action has little, if any, net affect on the global temperature average. Humans produce greenhouse gasses, yes. Humans also do things with the opposite effect. One good volcanic eruption has a lot more effect than years of human activity.
We're in an interglacial period. Icepacks are receding. Natural, normal, and on the whole a good thing for humans and most other species as well. Why people want to spin this as some kind of disaster is beyond me, excepting those with an obvious political motivation of course.
Earths climate is never static. If the icepacks weren't receding, they'd be expanding, and that would be much more like a disaster.
In a way that's what already happened. The US government were the ones that gave Verisign their monopoly, after all.
Typical modus operandi, government action messes things up, more action will fix it! (And if you believe that, just check out how they've fixed the war on (some) drugs.)
I've known about this for some time actually. Library where I volunteered years ago couldn't pay these damn fees, and decided to categorise new books on their own and not pay. They got some really nasty letters claiming they had to pay anyway. I don't know what finally happened with it, but I've known for some time there's a group of lawyers claiming they own this crap and threatening to sue anyone that uses it and doesn't pay them.
While I agree the hotel should pay the back licensing fees
No they shouldn't. This is exactly the kind of crap that shows why 'IP' is a bad idea. How can someone own the idea of classifying books by subject hierarchically?
No, they are lying. NIST probably isn't lying, technically, because of lack of requisite intent, but they're wrong here.
In computer science, a kilobyte 2^10 bits, a megabyte 2^20 etc. Always has been, always will be.
This isn't contradictory to the SI use, our words are very often used in very different ways in different contexts. Is a megalopolis a million cities? A megalomaniac a million maniacs? Of course not. People of normal intelligence shouldn't really have to have this explained to them.
In the world of digital computers, base10 units don't make much sense, so they aren't used. The prefixes are used to refer instead to the base 2 numbers that are important, and very close.
I don't remember anyone getting confused over this until the hard drive manufacturers decided to inflate their capacity figures some years back. A cheap trick that they then had to defend, so they and their shills have started laying on this crap real thick instead of just admitting the obvious. And they've even managed to flummox the NIST into thinking there was confusion here and they needed to rig a fix. So you get the silly hack you reference that practically no one has ever used or even heard of. It's not needed - the only source of confusion here is the harddisk manufacturers, and the solution is simple - they need to quit lying.
He already explained it, it's not magic, it's mostly memory bandwidth. The size of that internal bus doesn't mean squat when it's sitting waiting for data from main memory.
Take a read. It's true, because the case was settled out of court, there isn't a formal ruling that it's public domain. But neither the law nor the facts have changed. Well of course the law has, copyright law has really gone to hell, but the changes don't apply - if AT&T had no copyright to begin with, as the judge in this case seems to have been convinced.
There are other routes to Public Domain, of course. But this is the one SCO is preparing to trod. Idiots.
I can't believe they're planning to go that far. I expect Darl will grab his performance bonus and dump his stocks and head for the hills long before any of this gets to trial.
Actually the code is not public domain, but it has been released under the BSD license by SCO.
That's actually incorrect. Caldera aka SCO did indeed release the ancient Unix codes under, not the proper BSD license, but a 'BSD style' license. It's more like the old BSD license, with the advertising clause, so it's not a GPL compatible license, although it certainly puts the kibbosh on any trade secret claims related to that code.
However 32V code in particular is a different case. The Judge in the AT&T vs Berkley suit essentially said that the evidence presented there would compel him to declare 32V public domain. At the time, there were certain things that one had to do to hold a copyright (back in the days of sensible copyright law) and AT&T clearly had not fulfilled its obligations in that matter.
Now of course the case was settled, so it's not technically public domain in a formal sense, but the law and the evidence stand as they did then. The copyright law changes won't help because the copyright was lost before the new laws were written. So if SCO tries to press an actual copyright case, all the defendant has to do is bring in the same evidence that was used in the Berkley case and SCO loses all copyright claims whatsoever over 32V, which means there won't be much in later versions, including SysV stuff, they can actually claim a copyright on.
I keep pointing this one out, and being told I'm an idiot in various ways, but the fact of the matter is that UNIX code has already been judicially reviewed and the result of that review suggests that SCO's magic bag of intellectual property is, and always was, empty.
I guess I missed someone calling you an idiot, but you're almost completely correct. 32V is public domain, so their copyright bag isn't totally empty, but it's pretty damn bare. It really only covers later code that is not derivative of the ancient stuff, which means that most of it is not copyrightable.
I thought ERS was contacted by an "associate" of the alleged perpetrator?
He wasn't that specific. He said "SCO/Caldera's site is being hit by a massive denial-of-service attack
today. The timing, the scuttlebutt on Slashdot and elsewhere, and the
contents of my mailbox all suggest strongly that the DOS attack was
triggered by Darl McBride's slanderous interview[2] accusing the
community of being IBM's sock puppets, and my response[3] to it."
Did Perens, in fact, say that? I don't remember reading it.
No, not at all. The code is clearly not protected by SysV copyright, it goes back much further, to an ancient public domain version of Unix. He did say it shouldn't have been there to begin with, which is true of course, that file was a hack in the negative sense of the word and had been removed from the tree for being 'too ugly to live' long before anyone knew that this was one of SCOs examples. You can read the full analysis if you want the details.
Darl crossed the line between deceptive and manipulative misuse of quotes to flat out verifiable lying there.
Obviously any ISP with such a policy should change it. It's a stupid policy that's losing them more money than it saves. But a friend of mine did decide to set up one when I wasn't available to help her and the manufacturer of the router provided the support, so she didn't need to call her ISP.
That said, my router was so easy to setup I honestly think even Ma and Pa outta be able to handle it fine - the only reason my (not-so-great-with computers) friend needed to call anyone as it turned out was because her router was defective. You plug it in like the card shows, point your internet browser to the number the card gives, and the 'setup wizard' has you going in minutes. Things only get complicated in any way when you need to open unusual ports, and even then I've never had much of a problem.
I think the bigger problem is that Ma and Pa just don't know about these things, or that they need one.
But the general public is not quite so stupid as you make them out to be either. After these folks get hit once, the start to care. They can fix the problem quite simply, with a $50 hardware firewall/nat router they should probably have anyway, or a free software firewall like Kerio. All the ISPs really need to do is a little education.
Slashdot Mirror
Was - the 386 is long gone, although I have a great little 486 doing some minor chores right now. And then answer to your question was in my post, if you'd only read it - maintainence, mainly security updates. In comparison to proprietary alternatives, of course, Linux is great on this issue, but no distro and no kernel is maintained forever.
And just to be clear, Linux was my main desktop OS for several years too, and I'm not knocking it at that. The only reason I haven't used it for that is that my main desktop for work is now my TiBook. The windows box is and has always been a gaming machine. For every purpose the best tool... at the moment. I'd actually rather run LinuxPPC on my TiBook, but the applications I need for work won't run on it, so there you go.
But considering that the vast majority of Linux boxes are, and are likely to continue to be for the forseeable future, headless uniprocessor servers, doesn't it make more sense to, if not optimise for those, at the very least take care not to de-optimise for those installations? That really seems to be what's been happening.
While I most agree with you, and usually buy AMD, it has been my experience that AMDs are not as reliable. Reliable enough, usually, but... I've had two fail, while I've never had an Intel chip fail. And before you think that's just because I use more AMD chips, that's actually not true - I usually buy AMDs brand new, but I've used a lot of Intels, gotten secondhand for free or cheap. So all things being equal you'd think the Intels would have failed more often for me.
Oh well, anecdotal evidence of course, so not worth much... but Intel chips have had the capability to turn themselves off when they are in danger of heat damage, which last I heard AMD still won't do. For most purposes AMDs are still better value, but I think there's a reason to buy Intel sometimes as well.
I beg to differ. I couldn't care less about X, I haven't even used it in over a year. Like the vast majority of Linux boxes, mine runs in console mode only, and on a single processor. I, and the rest of the world that uses it like this, find it hard to see anything to get excited about in 2.6. It could be that misty thing that happens with your memory over time, but it certainly seems like my first linux box (slack 1 on a 386-25) had better performance than I get now with substantially more powerful hardware in fact. At the very least I'm certainly not seeing any dramatic improvements. I used to upgrade kernels as a matter of course, but now I just don't care, unless there is a security update involved. If it weren't that necessary maintainence work (security patches, in particular) were suspended long ago I'd be tempted to swap in a fresh drive and give it a try, in fact.
Like I say, it's nice to see SMP support getting better, I've got nothing against it, or any of the other features that have been introduced over the years, but when it starts interfering with performance on the machines that need performance the most, and coincidentally the ones that account for the vast majority of boxes running Linux as well, there is obviously something going wrong. Maybe the config scripts need more work, maybe there is nothing to do but fork large sections of the kernel, I don't know, but if Linux keeps getting worse at fulfilling its bread-and-butter role it will eventually have to be replaced with something else.
Do you really want to see Linux running on Minicomputer class machines (the kind that private citizens usually can't afford) exclusively, at the expense of being usable in its traditional role of turning cheap old boxes on their way out the door into powerful and stable servers? Does Linus?
I don't, and I predict there are enough programmers out there that agree with me that if the trajectory continues we'll eventually see either a kernel fork, or a mass migration to *BSD, or both.
It was actually used in a number of different designs.
It was designed as a terminal controller for CTC (later became Datapoint) but it seems they never actually used it. According to this post it was developed not by Intel but by CTC themselves, for use in the Datapoint 2200, which however wound up shipping without it and never used it. A firm called Traf-O-Data is said to have used it in a microcomputer designed to record highway traffic flow. The same year that this Canadian micro came out (1973), a French company called R2E used this in their Micral-N which has been credited as the first commercial, non-kit microcomputer. In the US, Scelbi Computer Consulting Company used it in Scelbi 8h, credited with being the first microcomputer available in the US. It was used in the Mark-8 micro, a design that was never mass produced but built instead by hobbyists from a published design - it appears less than 400 of them were ever made. MITS, described by one source as a dying calculator company, but apparently the same MITS that brought out the Altair a few years later, is said to have bought a large batch of them from Intel, planning to revive their business by building a large batch of cheap microcomputers with it, but I can't find any reference to them ever actually selling a computer based on this chip. Might be an interesting story for someone with the time to track it down. The NBI Hantu word processor used this chip.
Well that's enough for me, if you're interested this post should give you a ton of keywords to search for more data on.
I've got nothing against Linux improving at SMP in essence, but there is something very bad going on here it seems to me. Notice that while the new kernel 'kicks ass' on SMP systems, on uniprocessor systems the 2.4 kernel is the one kicking ass. Anyone benchmarked 2.4 against some of the pre-SMP kernels on a uniprocessor machine?
Face it, the vast majority of users are uniprocessor, and kernel performance is more of an issue on lower-end machines. Improving performance on big multiprocessor boxes is fine by itself, but not when it harms uniprocessor performance. I'm not a kernel hacker, but I've read many people that this would not happen, that the SMP code would not hurt performance on a uniprocessor machine when the kernel is compiled without it, but that's obviously not turning out to be the case. Anecdotal evidence, at least, suggests that this performance degradation has actually been going on for quite some time, at least back to when SMP code first started being added.
I'm not sure what all the factors here are, so naturally I'm not going to tell you the solution, but it certainly looks like a potential problem that should be discussed. Hopefully someone with more specifics than I have can chime in...
This is a common misconception. Do a little research. Fluoride as a topical treatment is effective, because when it comes in contact with the outer calcium material of the tooth it hardens it.
However, when swallowed, it is toxic to many of the bodies systems, in fact including the teeth.
That's all very nice, but Lindows is explicitly aimed at the folk that couldn't do that if you walked them through it. People that would figure all this out (or know that they needed to make a proper account in the first place, for that matter) aren't going to be using Lindows and are not the target audience for Lindows. They should ship it so that it runs with a user account and works properly that way out of the box.
Flouride rinses and toothpastes that are not meant to be swallowed are preventative measures.
Flouride in the water supply, where people do swallow it, is an entirely different matter.
That's your belief. Scientific evidence to support that belief is not in evidence, however.
Despite politically motivated statements to the contrary by some politically funded researchers with obvious interest in spinning things that way, the evidence suggests instead that human action has little, if any, net affect on the global temperature average. Humans produce greenhouse gasses, yes. Humans also do things with the opposite effect. One good volcanic eruption has a lot more effect than years of human activity.
We're in an interglacial period. Icepacks are receding. Natural, normal, and on the whole a good thing for humans and most other species as well. Why people want to spin this as some kind of disaster is beyond me, excepting those with an obvious political motivation of course.
Earths climate is never static. If the icepacks weren't receding, they'd be expanding, and that would be much more like a disaster.
In a way that's what already happened. The US government were the ones that gave Verisign their monopoly, after all.
Typical modus operandi, government action messes things up, more action will fix it! (And if you believe that, just check out how they've fixed the war on (some) drugs.)
I've known about this for some time actually. Library where I volunteered years ago couldn't pay these damn fees, and decided to categorise new books on their own and not pay. They got some really nasty letters claiming they had to pay anyway. I don't know what finally happened with it, but I've known for some time there's a group of lawyers claiming they own this crap and threatening to sue anyone that uses it and doesn't pay them.
With a linux distro anyone can download and burn it for you, either as a friend or for a small fee.
The import part was the second paragraph which you ignored, however.
And what he did not say, you can't modify it.
No they shouldn't. This is exactly the kind of crap that shows why 'IP' is a bad idea. How can someone own the idea of classifying books by subject hierarchically?
No, they are lying. NIST probably isn't lying, technically, because of lack of requisite intent, but they're wrong here.
In computer science, a kilobyte 2^10 bits, a megabyte 2^20 etc. Always has been, always will be.
This isn't contradictory to the SI use, our words are very often used in very different ways in different contexts. Is a megalopolis a million cities? A megalomaniac a million maniacs? Of course not. People of normal intelligence shouldn't really have to have this explained to them.
In the world of digital computers, base10 units don't make much sense, so they aren't used. The prefixes are used to refer instead to the base 2 numbers that are important, and very close.
I don't remember anyone getting confused over this until the hard drive manufacturers decided to inflate their capacity figures some years back. A cheap trick that they then had to defend, so they and their shills have started laying on this crap real thick instead of just admitting the obvious. And they've even managed to flummox the NIST into thinking there was confusion here and they needed to rig a fix. So you get the silly hack you reference that practically no one has ever used or even heard of. It's not needed - the only source of confusion here is the harddisk manufacturers, and the solution is simple - they need to quit lying.
Why is it taking long to boot up? That's not my experience. Loading a lot of services?
I guess someone has a use for this, or they wouldn't have spent the time working on it. But I don't see it.
I never noticed Linux taking very long to load, and even if it did I doubt I would care very much, as reboots are so rare anyway.
He already explained it, it's not magic, it's mostly memory bandwidth. The size of that internal bus doesn't mean squat when it's sitting waiting for data from main memory.
Take a read. It's true, because the case was settled out of court, there isn't a formal ruling that it's public domain. But neither the law nor the facts have changed. Well of course the law has, copyright law has really gone to hell, but the changes don't apply - if AT&T had no copyright to begin with, as the judge in this case seems to have been convinced.
I can't believe they're planning to go that far. I expect Darl will grab his performance bonus and dump his stocks and head for the hills long before any of this gets to trial.
That's actually incorrect. Caldera aka SCO did indeed release the ancient Unix codes under, not the proper BSD license, but a 'BSD style' license. It's more like the old BSD license, with the advertising clause, so it's not a GPL compatible license, although it certainly puts the kibbosh on any trade secret claims related to that code.
However 32V code in particular is a different case. The Judge in the AT&T vs Berkley suit essentially said that the evidence presented there would compel him to declare 32V public domain. At the time, there were certain things that one had to do to hold a copyright (back in the days of sensible copyright law) and AT&T clearly had not fulfilled its obligations in that matter.
Now of course the case was settled, so it's not technically public domain in a formal sense, but the law and the evidence stand as they did then. The copyright law changes won't help because the copyright was lost before the new laws were written. So if SCO tries to press an actual copyright case, all the defendant has to do is bring in the same evidence that was used in the Berkley case and SCO loses all copyright claims whatsoever over 32V, which means there won't be much in later versions, including SysV stuff, they can actually claim a copyright on.
I guess I missed someone calling you an idiot, but you're almost completely correct. 32V is public domain, so their copyright bag isn't totally empty, but it's pretty damn bare. It really only covers later code that is not derivative of the ancient stuff, which means that most of it is not copyrightable.
Here.
He wasn't that specific. He said "SCO/Caldera's site is being hit by a massive denial-of-service attack today. The timing, the scuttlebutt on Slashdot and elsewhere, and the contents of my mailbox all suggest strongly that the DOS attack was triggered by Darl McBride's slanderous interview[2] accusing the community of being IBM's sock puppets, and my response[3] to it."
No, not at all. The code is clearly not protected by SysV copyright, it goes back much further, to an ancient public domain version of Unix. He did say it shouldn't have been there to begin with, which is true of course, that file was a hack in the negative sense of the word and had been removed from the tree for being 'too ugly to live' long before anyone knew that this was one of SCOs examples. You can read the full analysis if you want the details.
Darl crossed the line between deceptive and manipulative misuse of quotes to flat out verifiable lying there.
Management is a scourge. Their own worst enemy, and everyone elses too. Possibly even worse than the lawyers.
Obviously any ISP with such a policy should change it. It's a stupid policy that's losing them more money than it saves. But a friend of mine did decide to set up one when I wasn't available to help her and the manufacturer of the router provided the support, so she didn't need to call her ISP.
That said, my router was so easy to setup I honestly think even Ma and Pa outta be able to handle it fine - the only reason my (not-so-great-with computers) friend needed to call anyone as it turned out was because her router was defective. You plug it in like the card shows, point your internet browser to the number the card gives, and the 'setup wizard' has you going in minutes. Things only get complicated in any way when you need to open unusual ports, and even then I've never had much of a problem.
I think the bigger problem is that Ma and Pa just don't know about these things, or that they need one.
But the general public is not quite so stupid as you make them out to be either. After these folks get hit once, the start to care. They can fix the problem quite simply, with a $50 hardware firewall/nat router they should probably have anyway, or a free software firewall like Kerio. All the ISPs really need to do is a little education.