My sound card was supported with redhat 6.1. It
wasn't supported in redhat 6.2. It is again
supported in redhat 7.0. That's good.
My video card, an older ATI model, still doesn't
work at 32bpp - it crashes often at 32bpp. At
16bpp it's mostly ok. So that hasn't changed.
The Blackdown java 1.1.8 that I had been using
to run cgoban 2.x, now segfaults.
My kermit executable (libc5) doesn't work at all.
AbiWord 0.7.something, probably 0.7.9, segfaults.
I had to recompile gtk-xemacs, because the requisite version of ncurses was no longer present.
When I logged into my account the first time after the reinstall, it asked me if I wanted to ditch my old drawers and stuff. I now wish I'd kept them. I have to wonder just how much was added by ditching them.
It's pretty different: xinetd, lprng, xfree86 4.0, library differences. We're probably going to have to start yet another copy of our software library for another version of redhat at work. And we're probably going to put off adopting 7.x at work for a while.
I don't mind that they dropped libc5. It's about time actually. If nothing else, libc5 executables appear to hate $LD_PRELOAD, and I make fairly heavy use of that.
I applaud the decision to have most things turned off by default. My security role at work will probably eventually be a less-large part of my job as a result. It's been tough teaching people who don't care about computers, that they -need- to do maintenance or they're endangering other people on our network.
I'm glad I have redhat 7.0 at home. I don't mind having something a little bleeding edge at home. But at work, things have to work; we're paid to make sure things work.
Go is a very deep game, rich in strategy. Entire books have been written about how go strategy compares to business strategy.
Microsoft business tactics are very much like intermediate go strategy - give your opponent a "heavy" group, one that's too awkward to be of much use, but you leave it living anyway so you have something to chase around and make solid territory (profit) from as you chase it.
The heavy group is the weakling business, apple or corel. Your goal isn't to make it thrive and overwhelm one of your groups, but to keep it just barely alive, because businesses and weak groups on life support have their uses.
Are you sure Mt. Xinu's MSD 2.6 didn't inherit from any unix variants?
I really thought it was BSD 4.x overtop of Mach. It certainly felt BSD, not that I was aware of BSD vs SysV that much back then. That was only the 3rd unix I'd touched at the time.
Or are you referring to something else when you say "XINU"?
Linux sort of split off from the 386 version of minix, and sort of didn't.
Linux was bootstrapped from minix 386. Also, linux had a complete reimplementation of the minix filesystem to make bootstrapping easier - hence it was cake to set up a filesystem for use with linux - just mkfs under minix and copy your cross-compiled binaries over.
It's good you realize the value of customer support. I can't believe the number of linux people who just don't get this.
However, to get good support for linux you need to not only run linux, but a _supported_distribution_ of linux. Much as people want all linuxes to be the same, they aren't. As you've discovered.
We looked at VA also, and probably would have gone with them if they hadn't required their own distribution of linux. We require stock redhat, and definitely don't want our vendor differentiating by using weird drivers that may or may not end up integrated into the _baseline_ kernel tree at a later date.
Some of the folks here have been having good luck with PSSC for hardware with linux support. I gather one of our clients just purchased a Coppermine machine from them that requires no funky drivers - which'll help keep our costs down when it's time to upgrade the machine.
You see, soon novice users will have the power to do some of things you *can't* on the command-line. And that makes you mad. And makes you label Nautilus a Windows clone. Grow up.
Yes, that does make me mad (er, just annoyed enough at the shortsightedness of it to speak up). No it's not immaturity at all.
Linux/unix's big strength relative to other operating systems is its scriptability. Don't get me wrong, I'm appreciating GUI's more all the time, in fact sometimes I feel grumpy if I have to open an rxvt to get something done.
So bring on the GUI, but most definitely, don't give up the scriptability. The ideal system allows you to do everything from a GUI and everything from a CLI, and to easily find out how doing something in one could have been done in the other.
Of course unix can handle it - a LOT of people do this sort of thing on Solaris/sparc, for example.
I expect Linux would be able to handle it to, but don't expect the same throughput per MIPS from Linux/x86 as you'd get from Linux/sparc or Linux/alpha. Intel and AMD have great CPU performance for the price, but they aren't that much of a server architecture.
>> I think the real problem is going to be getting the end-user machines upgraded to IPv6.
This is right on target. It'll be pulling teeth getting people to upgrade. So I don't think there will be much of a push to get people to upgrade.
>If anything, ISPs (who these end-users are connecting to) can mass e-mail their customers and say, "Look, we're moving over to IPv6. If you're running this version of this operating system, be sure to upgrade with files found here."
No, it really won't work this way. There is a much smoother migration path than this. We're just going to have to live with dual stacks and other kludges for quite a while.
> The whole, "Older users will be alienated!" is a cry of the alarmist.
Mostly true. For a long time, we'll have dual stacks or gateway machines and such, so old stack users won't be alienated. But there will come a day when servers start doing ipv6 alone (not just security conscious sites which will come sooner, but fairly generic sites like search engines and about.com), and then the last ipv4 holdouts will be alienated.
People predict the end of the internet all the time.
So far, it's been a lot of... well, not worth paying much attention to.
IMO, if the internet dies, it'll be because some slimeball company replaces it with something proprietary (that doesn't gateway), or because somebody decides it'd be a really neato marketing campaign to have a big chunk of the internet called something other than "the internet" in order to drive up sales.
Consider the "internet2" project, intended to give people experience with higher bandwidth than the internet. It's still basically the internet, just by another name.
I used to use bogomips for benchmarking. Not because I thought it was a great benchmark, but because it was so easy to set up a job to collect bogomips data from all of our unix/linux boxes. I didn't have to worry that any of our users would get upset that we were running an obtrusive benchmark program - bogomips completed very quickly.
Then I noticed that my K6/2 450 had a significantly higher bogomips rating than my Athlon 550 (both AMD, Athlon being a higher end CPU line than K6/2 - so if anything, I'd expect the Athlon to outperform a K6/2 at the same MHz).
Hence, I gave up on bogomips and switched to nbench, the Byte benchmark thingy. I doubt this is a perfect benchmark either, but it does seem to be better correlated with reality than bogomips. Alas, this one pegs the CPU for a while, so I no longer rest easy about users not complaining about it.
I'm typing this sitting in front of an athlon 550 with FIC SD11 motherboard. It's been working great with both redhat 5.2 (plus security patches, including an updated Xfree86 3.x) and redhat 6.2 (plus security patches, not including an updated XFree). I had to fiddle a bit to get X running on 5.2, but 6.2 worked right out of the box.
The video card is an AGP Matrox Millenium G400.
I haven't tried 3d on it at all.
I got it from LinuxIt! computers in San Diego.
On the other hand, the celeron system next to me that we built from scratch has been having problems, one of which is preventing me from using it for its primary purpose.
My K6/2 at home crashes infrequently (or at least it did running 6.1; it hasn't crashed since I upgraded to 6.2, but it was such an infrequent crash that it could still be waiting to surprise me:)
So in my experience, of the x86 compatible machines I'm currently closest to, the athlon has been the most reliable.
++@_[0]; isn't only an example of something grandmothers think is implausible - your average language designer is likely going to have fits over it too.
And it's definitely not cute. It's reminiscent of sendmail. It's pretty ugly.
I'm planning to learn perl basics, but not because it's a good language. I'll be doing it because there are so vastly many misguided souls who insist on using it, and I can no longer avoid their code.
In short, there are entirely too many programmers in the world who think that if their code is hard to read, that makes them clever - when in fact the reverse is true. A truly excellent programmer takes a difficult problem, and writes code to implement it in a way that makes it relatively easy for maintainers to understand.
The problem is, by making something easy, you give that thing an air of legitimacy.
"If it were a bad thing to do, why would the intelligent, benevolent Microsoft make it so easy to do? So it _must_ be ok to run executable attachments!"
To make things worse, I fully expect that a lot of the less-than-clueful microsoft users out there don't even know the difference between an executable attachment, and a nonexecutable attachment.
And microsoft has facilitated that lack of understanding, tried to make people feel that it's ok to have that lack of understanding.
I don't object at all to microsoft telling people that they shouldn't have to know what's under the hood of their computers.
But I do vehemently object to microsoft telling people it's ok not to bother to learn the rules of the road - not to turn left on red, as it were.
I think one way of combatting this problem is to have easy software interfaces to the intended speed of the processor, and the current speed of the processor.
People can still overclock and sell, but they may be less likely to think they can get away with it.
I don't buy for a second that 80% of intrusions are internal in origin. I've seen this many times, and I think it's getting to be past time that people questioned this.
I work as a sysad at a university campus. We get portscanned at -least- a few times a week, and deal with breakins a couple of times a month.
So far, I have not been made aware of a single internal breakin. Every one I've gotten involved with has been external. Ok, except that student who forged a faculty member's e-mail recently, but that doesn't count as a breakin by a long shot.
The only way most breakins are internal (for us, and probably for you too), is if we've had a lot of internal crackers breaking into remote machines, and from there breaking back into internal machines.
I mean think about it: if you're on the internet, just how much huger is the internet than the population of your business or government agency or university?
Once, in a fit of pique about this oft-quoted bit of unlikely "wisdom", I did a survey. The number of respondents was small, but it did show that most respondents had suffered more external breakins than internal.
I think one of the reasons that linux viruses haven't been widespread is likely to be cultural.
At one time, computer viruses were things that only existed in theory. The attitude was "wow, if you can write a (microsoft) virus, you must be a really incredible programmer".
So writing a microsoft virus was a (to some braindead virus authors' thinking) "way to prove how smart you are".
But linux viruses aren't the same kind of technical challenge. They tend not to involve bits and bytes, or attaching yourself to an executable, or wedging into the boot process. They tend to be these idiot-simple little shell scripts that nearly anyone could write.
And to the person lacking in perspective enough to think that writing a virus is a way to prove how skilled they are, this just isn't a very good way of proving anything.
I think this is related to why there are so many script bunnies (aka script kiddies) running around breaking into computers - early on, the press decided these idiotic kids were "too smart for their own good", so the kids got the idea they could prove how smart they are by breaking into something.
Of course, in reality, writing even a microsoft virus isn't all that technically interesting, and hunting down a computer to break into is a piece of cake. Neither really proves much. But these seem to be some attitudes that contribute to their being as popular as they are.
PS: As a kid, there was much the same attitude about breaking the copy protection on commercial software. I fell prey to doing this for kicks for a while, but eventually I read this tiny blurb by Electronic Arts saying "Look, if you can break our copy protection, why the hell don't you use your skills to write something and sell it." IMO, that was the most effective copy protection they could buy - I never took the locks off another program.
As others have said, this is slightly innovative. However, a good researcher credits his or her sources, and Microsoft has failed to do that - this was obviously inspired by unix's symlinks
More importantly however, let's consider an algorithmic analysis of this "innovation". Imagine copying N files into a filesystem of this type - for example, restoring a filesystem from backup after doing a reinstall.
In a tree-based implementation, the running time is suddenly O(NlogN) on average ( O(N^2) in the worst case), and that would probably hit the disk a lot.
In a memory based implementation, say one that uses MD5 or SHA-1 to avoid lots of disk accesses, it seems the running time would O(N^2).
So let's give them the benefit of the doubt for a sec, and say they have an incredibly well tuned hashing algorithm that makes it O(cN). But wouldn't this end up taking up just tons of memory, to have a hash table sparse enough to get that good of a running time? Imagine doing it for a news server's filesystems!
So it seems this may be the kind of innovation that sinks ships. And if it is, I hope they don't notice it until the "innovation" is already in the field and can't be retracted...
Microsoft was unwilling to divulge the specifics of their proprietary extensions, making it potentially very difficult for an opensource server to present all required information to a microsoft client.
A unix KDC could be used by microsoft clients, if an adjunct database of some sort was set up on a microsoft server to provide the proprietary bits to the microsoft clients. This appears to be in contradiction with what's in the kerberos FAQ, so I have to wonder how accurate this really is.
These are just rumors though, and I don't recall where I heard these.
If you think that's bad, wait until you examine some of the blecherous cruft automatically generated by the AI technique, Genetic Programming. Basically they define a function that determines if a randomly generated program does what's desired, and then throw tons of randomly generated programs into the mix until you get something that works well enough. (I'm simplifying, actually the random programs exchange genes and mutate so it's a faster convergence than a truly random process).
I'm not making this up.
I don't mean to slam it too much though - the technique's already produced some results that programmers had a very difficult time with.
Slashdot Mirror
I put 7.0 on one machine at home.
My sound card was supported with redhat 6.1. It
wasn't supported in redhat 6.2. It is again
supported in redhat 7.0. That's good.
My video card, an older ATI model, still doesn't
work at 32bpp - it crashes often at 32bpp. At
16bpp it's mostly ok. So that hasn't changed.
The Blackdown java 1.1.8 that I had been using
to run cgoban 2.x, now segfaults.
My kermit executable (libc5) doesn't work at all.
AbiWord 0.7.something, probably 0.7.9, segfaults.
I had to recompile gtk-xemacs, because the requisite version of ncurses was no longer present.
When I logged into my account the first time after the reinstall, it asked me if I wanted to ditch my old drawers and stuff. I now wish I'd kept them. I have to wonder just how much was added by ditching them.
It's pretty different: xinetd, lprng, xfree86 4.0, library differences. We're probably going to have to start yet another copy of our software library for another version of redhat at work. And we're probably going to put off adopting 7.x at work for a while.
I don't mind that they dropped libc5. It's about time actually. If nothing else, libc5 executables appear to hate $LD_PRELOAD, and I make fairly heavy use of that.
I applaud the decision to have most things turned off by default. My security role at work will probably eventually be a less-large part of my job as a result. It's been tough teaching people who don't care about computers, that they -need- to do maintenance or they're endangering other people on our network.
I'm glad I have redhat 7.0 at home. I don't mind having something a little bleeding edge at home. But at work, things have to work; we're paid to make sure things work.
Go is a very deep game, rich in strategy. Entire books have been written about how go strategy compares to business strategy.
Microsoft business tactics are very much like intermediate go strategy - give your opponent a "heavy" group, one that's too awkward to be of much use, but you leave it living anyway so you have something to chase around and make solid territory (profit) from as you chase it.
The heavy group is the weakling business, apple or corel. Your goal isn't to make it thrive and overwhelm one of your groups, but to keep it just barely alive, because businesses and weak groups on life support have their uses.
I'm quite sure I heard that CD's don't last decades, let alone millenia. Perhaps I heard wrong.
Are you sure Mt. Xinu's MSD 2.6 didn't inherit from any unix variants?
I really thought it was BSD 4.x overtop of Mach. It certainly felt BSD, not that I was aware of BSD vs SysV that much back then. That was only the 3rd unix I'd touched at the time.
Or are you referring to something else when you say "XINU"?
Linux sort of split off from the 386 version of minix, and sort of didn't.
Linux was bootstrapped from minix 386. Also, linux had a complete reimplementation of the minix filesystem to make bootstrapping easier - hence it was cake to set up a filesystem for use with linux - just mkfs under minix and copy your cross-compiled binaries over.
It's good you realize the value of customer support. I can't believe the number of linux people who just don't get this.
However, to get good support for linux you need to not only run linux, but a _supported_distribution_ of linux. Much as people want all linuxes to be the same, they aren't. As you've discovered.
We looked at VA also, and probably would have gone with them if they hadn't required their own distribution of linux. We require stock redhat, and definitely don't want our vendor differentiating by using weird drivers that may or may not end up integrated into the _baseline_ kernel tree at a later date.
Some of the folks here have been having good luck with PSSC for hardware with linux support. I gather one of our clients just purchased a Coppermine machine from them that requires no funky drivers - which'll help keep our costs down when it's time to upgrade the machine.
You see, soon novice users will have the power to do some of things you *can't* on the command-line. And that makes you mad. And makes you label Nautilus a Windows clone. Grow up.
Yes, that does make me mad (er, just annoyed enough at the shortsightedness of it to speak up). No it's not immaturity at all.
Linux/unix's big strength relative to other operating systems is its scriptability. Don't get me wrong, I'm appreciating GUI's more all the time, in fact sometimes I feel grumpy if I have to open an rxvt to get something done.
So bring on the GUI, but most definitely, don't give up the scriptability. The ideal system allows you to do everything from a GUI and everything from a CLI, and to easily find out how doing something in one could have been done in the other.
WHOOPS. Sorry.
That should have been "we should NOT smear young ones".
IMO, this should be the standard response.
There -should- be a negative connotation to the way we refer to people who attack computers.
However, you're right, we should smear young ones at the same time.
A coworker has an article posted up by his door, in which attackers are referred to as "script bunnies". I like it. No respect at all.
Of course unix can handle it - a LOT of people do this sort of thing on Solaris/sparc, for example.
I expect Linux would be able to handle it to, but don't expect the same throughput per MIPS from Linux/x86 as you'd get from Linux/sparc or Linux/alpha. Intel and AMD have great CPU performance for the price, but they aren't that much of a server architecture.
>> I think the real problem is going to be getting the end-user machines upgraded to IPv6.
This is right on target. It'll be pulling teeth getting people to upgrade. So I don't think there will be much of a push to get people to upgrade.
>If anything, ISPs (who these end-users are connecting to) can mass e-mail their customers and say, "Look, we're moving over to IPv6. If you're running this version of this operating system, be sure to upgrade with files found here."
No, it really won't work this way. There is a much smoother migration path than this. We're just going to have to live with dual stacks and other kludges for quite a while.
> The whole, "Older users will be alienated!" is a cry of the alarmist.
Mostly true. For a long time, we'll have dual stacks or gateway machines and such, so old stack users won't be alienated. But there will come a day when servers start doing ipv6 alone (not just security conscious sites which will come sooner, but fairly generic sites like search engines and about.com), and then the last ipv4 holdouts will be alienated.
People predict the end of the internet all the time.
So far, it's been a lot of... well, not worth
paying much attention to.
IMO, if the internet dies, it'll be because some slimeball company replaces it with something proprietary (that doesn't gateway), or because somebody decides it'd be a really neato marketing campaign to have a big chunk of the internet called something other than "the internet" in order to drive up sales.
Consider the "internet2" project, intended to give people experience with higher bandwidth than the internet. It's still basically the internet, just by another name.
I used to use bogomips for benchmarking. Not because I thought it was a great benchmark, but because it was so easy to set up a job to collect bogomips data from all of our unix/linux boxes. I didn't have to worry that any of our users would get upset that we were running an obtrusive benchmark program - bogomips completed very quickly.
Then I noticed that my K6/2 450 had a significantly higher bogomips rating than my Athlon 550 (both AMD, Athlon being a higher end CPU line than K6/2 - so if anything, I'd expect the Athlon to outperform a K6/2 at the same MHz).
Hence, I gave up on bogomips and switched to nbench, the Byte benchmark thingy. I doubt this is a perfect benchmark either, but it does seem to be better correlated with reality than bogomips. Alas, this one pegs the CPU for a while, so I no longer rest easy about users not complaining about it.
I'm typing this sitting in front of an athlon 550 with FIC SD11 motherboard. It's been working great with both redhat 5.2 (plus security patches, including an updated Xfree86 3.x) and redhat 6.2 (plus security patches, not including an updated XFree). I had to fiddle a bit to get X running on 5.2, but 6.2 worked right out of the box.
The video card is an AGP Matrox Millenium G400.
I haven't tried 3d on it at all.
I got it from LinuxIt! computers in San Diego.
On the other hand, the celeron system next to me that we built from scratch has been having problems, one of which is preventing me from using it for its primary purpose.
My K6/2 at home crashes infrequently (or at least it did running 6.1; it hasn't crashed since I upgraded to 6.2, but it was such an infrequent crash that it could still be waiting to surprise me
So in my experience, of the x86 compatible machines I'm currently closest to, the athlon has been the most reliable.
++@_[0]; isn't only an example of something grandmothers think is implausible - your average language designer is likely going to have fits over it too.
And it's definitely not cute. It's reminiscent of sendmail. It's pretty ugly.
I'm planning to learn perl basics, but not because it's a good language. I'll be doing it because there are so vastly many misguided souls who insist on using it, and I can no longer avoid their code.
In short, there are entirely too many programmers in the world who think that if their code is hard to read, that makes them clever - when in fact the reverse is true. A truly excellent programmer takes a difficult problem, and writes code to implement it in a way that makes it relatively easy for maintainers to understand.
Yes, it is outlook's fault.
The problem is, by making something easy, you give that thing an air of legitimacy.
"If it were a bad thing to do, why would the intelligent, benevolent Microsoft make it so easy to do? So it _must_ be ok to run executable attachments!"
To make things worse, I fully expect that a lot of the less-than-clueful microsoft users out there don't even know the difference between an executable attachment, and a nonexecutable attachment.
And microsoft has facilitated that lack of understanding, tried to make people feel that it's ok to have that lack of understanding.
I don't object at all to microsoft telling people that they shouldn't have to know what's under the hood of their computers.
But I do vehemently object to microsoft telling people it's ok not to bother to learn the rules of the road - not to turn left on red, as it were.
I think one way of combatting this problem is to have easy software interfaces to the intended speed of the processor, and the current speed of the processor.
People can still overclock and sell, but they may be less likely to think they can get away with it.
Urk.
Python is easy -and- flexible.
Don't write it off for substantive projects just because it's easy.
I've put a script up here that removes the virus from unix mailspools.
I work as a sysad at a university campus. We get portscanned at -least- a few times a week, and deal with breakins a couple of times a month.
So far, I have not been made aware of a single internal breakin. Every one I've gotten involved with has been external. Ok, except that student who forged a faculty member's e-mail recently, but that doesn't count as a breakin by a long shot.
The only way most breakins are internal (for us, and probably for you too), is if we've had a lot of internal crackers breaking into remote machines, and from there breaking back into internal machines.
I mean think about it: if you're on the internet, just how much huger is the internet than the population of your business or government agency or university?
Once, in a fit of pique about this oft-quoted bit of unlikely "wisdom", I did a survey. The number of respondents was small, but it did show that most respondents had suffered more external breakins than internal.
I think one of the reasons that linux viruses haven't been widespread is likely to be cultural.
At one time, computer viruses were things that only existed in theory. The attitude was "wow, if you can write a (microsoft) virus, you must be a really incredible programmer".
So writing a microsoft virus was a (to some braindead virus authors' thinking) "way to prove how smart you are".
But linux viruses aren't the same kind of technical challenge. They tend not to involve bits and bytes, or attaching yourself to an executable, or wedging into the boot process. They tend to be these idiot-simple little shell scripts that nearly anyone could write.
And to the person lacking in perspective enough to think that writing a virus is a way to prove how skilled they are, this just isn't a very good way of proving anything.
I think this is related to why there are so many script bunnies (aka script kiddies) running around breaking into computers - early on, the press decided these idiotic kids were "too smart for their own good", so the kids got the idea they could prove how smart they are by breaking into something.
Of course, in reality, writing even a microsoft virus isn't all that technically interesting, and hunting down a computer to break into is a piece of cake. Neither really proves much. But these seem to be some attitudes that contribute to their being as popular as they are.
PS: As a kid, there was much the same attitude about breaking the copy protection on commercial software. I fell prey to doing this for kicks for a while, but eventually I read this tiny blurb by Electronic Arts saying "Look, if you can break our copy protection, why the hell don't you use your skills to write something and sell it." IMO, that was the most effective copy protection they could buy - I never took the locks off another program.
More importantly however, let's consider an algorithmic analysis of this "innovation". Imagine copying N files into a filesystem of this type - for example, restoring a filesystem from backup after doing a reinstall.
In a tree-based implementation, the running time is suddenly O(NlogN) on average ( O(N^2) in the worst case), and that would probably hit the disk a lot.
In a memory based implementation, say one that uses MD5 or SHA-1 to avoid lots of disk accesses, it seems the running time would O(N^2).
So let's give them the benefit of the doubt for a sec, and say they have an incredibly well tuned hashing algorithm that makes it O(cN). But wouldn't this end up taking up just tons of memory, to have a hash table sparse enough to get that good of a running time? Imagine doing it for a news server's filesystems!
So it seems this may be the kind of innovation that sinks ships. And if it is, I hope they don't notice it until the "innovation" is already in the field and can't be retracted...
These are just rumors though, and I don't recall where I heard these.
If you think that's bad, wait until you examine some of the blecherous cruft automatically generated by the AI technique, Genetic Programming. Basically they define a function that determines if a randomly generated program does what's desired, and then throw tons of randomly generated programs into the mix until you get something that works well enough. (I'm simplifying, actually the random programs exchange genes and mutate so it's a faster convergence than a truly random process).
I'm not making this up.
I don't mean to slam it too much though - the technique's already produced some results that programmers had a very difficult time with.