Incidently, I decided to give Linux one more shot before giving up. I downloaded SuSE 9.1. The onboard network interface still doesn't work, but again, I don't care because the gigabit card does work. The video card works fine. Therefore, I'm satisfied.
I'm not advocating Windows over Linux. You'd have to pay me to use Windows (my company does, I'm continuously reminded why I don't use it at home).
"However, while Linux has "problems", they are only significant to the more naive user base. They are nothing that some training and some willingness on the part of the user to learn something new couldn't fix. In other words, these "problems" are social, not technological (except in the sense that ALL such "problems" are technological as per my previous paragraph.)"
I don't think that's accurate. I have technical issues with Linux with supposedly supported hardware (Intel PRO/100 network chipset, Matrox G550 video card) that I have not been able to solve, yet I am not a naive user. I think it's likely that these are bugs introduced through a lack of regression testing, because a number of out of date versions of Linux distros work fine (as well as FreeBSD), yet newer versions of the distros that I've tried don't work.
"My standard statement remains true: 1) Windows is CRAP. 2) Linux is ALSO CRAP (whether it is EQUALLY crap is another issue - given the difficulty of writing a virus for it and its renowned stability, I think not.) 3) Linux is FREE crap."
What bugged me was people asserting that it wasn't crap. As in, no one who is making an honest attempt to use Linux can have problems. It's possible they were responding to trolls, but they were just as wrong as trolls, and just as annoying.
"Really? Every time I go there, it's entirely about the law and how stupid SCO is. I don't think I've ever read anything about "Linux usability" there. Maybe I didn't look hard enough, since I don't read *every* post."
One of the other replies to my post said it better. They're not willing to engage in self-criticism. Thus, when anything at all gets said about Linux itself, it's positive.
Perhaps things have changed. I haven't read Groklaw (except for the odd linked article) for almost a year.
It was sufficiently annoying that I'm not going to be giving it another shot.
"Not likely. Too many Windows trolls post here. Especially the ones that act like they really like Linux, "it's just that Linux [fill in the blanks about usability, installs, and other ruminant evacuation.]" Sorry, these morons fool no one."
See, this is the attitude I'm talking about. Your attitude is that these criticisms are necessarily false. Anyone who disagrees must be a troll. They must have an agenda.
Groklaw has bugged me for a long time. They tend to wear rose colored glasses when looking at things like how good Linux is on the desktop. They're Linux users, but if you s/Linux/MacOS X/g, you could put most of the posts on a Mac forum and no one would look twice. In most places (like/.), you've got a healthy mix of people that use all kinds of OSes. Even if it takes zealots from the other camps (Mac, BSD, etc) to balance things out, they do eventually get balanced most of the time. Or failing that, at least you get another side presented, like the people whose transition to Linux stalled because something didn't work.
A few months after it got started, Groklaw turned into this orgy of groupthink with respect to issues of Linux technical and usability merit. Let's not turn Slashdot into that. It happens here on occasion, but it's well below critical mass. People do have legitimate problems with Linux, and there are technical reasons that it's not always the best choice.
The only thing we can take for granted is that SCO is full of shit.
It wasn't an overflow... the behavior this causes is well documented. Left by itself, it would just read from the random device until it reached the memory limit and crashed. It would eat all of the randomness buffer, most of the CPU, and a fair bit of memory until that happened though. All in all a good DOS.:) Thanks for pointing it out.
I was also going to set it up so it can't be invoked more than (say) once a second, but never got around to it.
I wrote this for my own use (I might be logging the results, and it doesn't use SSL, so don't use it yourself), but IMO an 8-character password from there will be good enough if your shadow file (or equivilant) isn't publically accessible.
What system doesn't restrict your attempt rate anyway?
The interface is similar to a search engine. You load the front page, submit the URL, and you are presented with a user/pass combination. No additional steps are required.
How about a stable branch? Solaris actually has one.
The only up to date versions of Linux that can touch Solaris in scalability terms are now development versions. It's up to the distros to figure out how to make it stable.
'course, it's easier to nab the encryption keys on a Linux box...
Re:bash = "embrace and extend" proprietary crap
on
Bash 3.0 Released
·
· Score: 1
a) You can't assume that everyone, everywhere will have the ability to install the shell of their choice.
b) You can't assume that bash will be in/bin. The BSDs, for example, when they install it out of ports, put it in/usr/bin. This is correct because/bin is for base system files and shouldn't be touched by the user (on a BSD anyway). It's quite possibly mounted read only. It might even be on read only media, or on NFS you can't write to.
While it's nice to see someone on/. get it right for a change, I'm a bit irritated at the tiny number of people that actually read it. The whole thing is shorter than the GPL's preamble.
The obvious course of action is to set up a multi-distribution kernel team to maintain a stable kernel, or to just use the kernel of a big distro like Red Hat or Suse. This would become the defacto stable kernel.
The 3rd party kernel would bring in patches from the development one, but this is of limited utility. As the BSDs have shown us, drift can build up pretty quickly. It's hard enough for them to backport stuff from FreeBSD 5.x to 4.x, and moving stuff between NetBSD and OpenBSD (still very similar) requires rewrites with the other code as a guide in many cases.
A commitment to stability is necessary for an OS to be taken seriously. This comes just after everyone saying that "2.6 is stable enough to switch!", so it's particularly disapointing. It's hard to keep a kernel stable when there's development patches coming in all the time.
Blah.
I don't run Linux on my servers because of less serious instances of this same problem. There are a few alternatives (Debian-stable et al), but they're even more out of date than OpenBSD. This just drives the point home.
"CISC chips run instructions simultaneously and out of order as well."
RISC chips can do this as well. In fact, they're generally better at it because they have more registers, and can therefore have more instructions without dependencies between them. For example, the PowerPC 970 can execute up to 5 instructions in one clock cycle if conditions are good. This is more than any CISC chip can do.
"RISC chips being faster than a CISC chip running at the same clock? Sorry, but no. That's completely unrealistic statement."
Not only is it possible, there are shipping processors that do exactly what you're saying is unrealistic.
CISC processors break things up into one or more internal RISC-like micro-ops. Instructions that require more than one micro-op (an add instruction that stores the results to memory for example) will require multiple internal ops. Exactly like a RISC chip does things, the RISC chip just doesn't hide what it's doing. This is why they can have similar performance. Or in the case of the P4, which is designed to increase the clock speed for marketting purposes, the RISC processor can have better performance per clock cycle.
You're completely wrong. Please shut up, read some of the papers on Ars Technica, and stop being wrong.
You can just download the install packages and burn your own CD. I've done that for years.
It's not as convenient as a FreeBSD ISO that you can just install, but if another 10 minutes is over your threshold for convenience, you won't like OpenBSD anyway. It takes a lot longer than that to adjust to things from most other OSes.
"I just wanted to point out you mentioned GCC. Sadly GCC is about the worst compiler in existence for performance."
That was my point. A shitty compiler with moderate optimization settings is very close in performance to one of the top compilers out there.
"The top compiler is infact the Intel compiler in part because it knows about unpublished instructions. Have fun reading the code it generates."
Yes, this was the example I used. The vectorized loops are a bitch to read.
"On the subject of G5s being faster, there are a whole host of differences between G5's and P4's. You can't just pick one difference and claim that's the reason."
That's true. However, I never gave a reason for the performance difference, so I'm not sure why you're saying this.
You said that RISC CPUs needed to run at a higher frequency to get the same performance as a CISC CPU. Since you're wrong, I gave an example to prove you wrong.
There is basically only one RISC CPU architechture that has the benefit of a really large R&D effort these days, and that's POWER/PowerPC. Itanium is not strictly RISC, and nothing else has the benefit of such a huge R&D effort.
Thus, the only RISC CPUs that can be fairly compared to x86 are the POWER/PowerPC chips from IBM. The only two x86 CPUs that have a really huge R&D effort behind them are the Athlons from AMD and the Pentiums from Intel.
They all have relatively similar performance (with advantages going to one or the other in a few niches). PowerPC chips are shipped at similar clock speeds to the Athlons and much lower clock speeds than the Pentiums.
Therefore, your statement that RISC CPUs need higher clock speeds to get the same performance has been demonstrated to be false in a comparison between the only 3 large chip makers in operation.
Further comparisons, such as those between Sparc and the VIA C3, which are smaller but significant efforts, show the RISC CPU getting more done per clock cycle, again demonstrating your statement to be false.
"Quick examples: RISC use less power because it has less logic? No, it needs to run at a higher frequency to maintain the same speed as a slower CISC."
No. This is exactly wrong. G5s are a good example of this. They easily outperform P4s at the same clock speed, and it's the P4 which must run at the higher speed to compensate.
The overhead of supporting all the various instructions and adressing modes, as well as being able to fit the whole CPU in one die were what made RISC a good choice in the past. Now, that overhead is dwarfed by other parts of the chip, and they're all running weird u-ops internally, so it makes little difference.
"RISC is easier to program? Depends on the person. A compiler can take advantage of large instructions very well which are hardware optimized."
Compilers are notorious for not utilizing esoteric opcodes. And when they do, there's almost never a significant performance advantage in doing so.
For example, none of the code I've ever tested with icc (one of the only compilers that can use weird opcodes on i386) has been more than about 5% faster than "gcc -Os -msse2", and a lot of it has been slower.
"RISC is physically smaller? No. RISC needs a higher clock frequency because many more instructions need to be executed. The result of this is that a much larger instruction cache is needed on chip.
RISC does generally need a larger cache, but it does not need a higher frequency.
"I don't remember every comparison but it pretty much comes out that neither is better than the other. That being said RISC is better than x86. Everything is better than x86. However CISC vs RISC is much harder to judge. Having done x86, 68k, and MIPS I must say that RISC is a pleasure."
Just use a compiler. Anything with a proper MMU will be good enough.
ahhh... but try Calgary. Filled with big oil companies, has one of the lowest costs of living in the US or Canada.
I make 40% less here than I did in Houston, but my quality of life is almost identical. On top of that, while I didn't save much in Houston, I save a lot every month here.
I think it's a reasonable to assume that anyone who makes an informed decision about what OS to use, even if they decide on Windows, is above average. Informed decisions have a higher probability of being another OS, because uninformed decisions are almost 100% Windows.
Slashdot Mirror
Incidently, I decided to give Linux one more shot before giving up. I downloaded SuSE 9.1. The onboard network interface still doesn't work, but again, I don't care because the gigabit card does work. The video card works fine. Therefore, I'm satisfied.
I'm not advocating Windows over Linux. You'd have to pay me to use Windows (my company does, I'm continuously reminded why I don't use it at home).
"However, while Linux has "problems", they are only significant to the more naive user base. They are nothing that some training and some willingness on the part of the user to learn something new couldn't fix. In other words, these "problems" are social, not technological (except in the sense that ALL such "problems" are technological as per my previous paragraph.)"
I don't think that's accurate. I have technical issues with Linux with supposedly supported hardware (Intel PRO/100 network chipset, Matrox G550 video card) that I have not been able to solve, yet I am not a naive user. I think it's likely that these are bugs introduced through a lack of regression testing, because a number of out of date versions of Linux distros work fine (as well as FreeBSD), yet newer versions of the distros that I've tried don't work.
"My standard statement remains true:
1) Windows is CRAP.
2) Linux is ALSO CRAP (whether it is EQUALLY crap is another issue - given the difficulty of writing a virus for it and its renowned stability, I think not.)
3) Linux is FREE crap."
What bugged me was people asserting that it wasn't crap. As in, no one who is making an honest attempt to use Linux can have problems. It's possible they were responding to trolls, but they were just as wrong as trolls, and just as annoying.
It would be nice to have a consistent multi-platform Objective C library period.
Forget about GUI bindings, all the different implementations don't even share the same root object.
"Really? Every time I go there, it's entirely about the law and how stupid SCO is. I don't think I've ever read anything about "Linux usability" there. Maybe I didn't look hard enough, since I don't read *every* post."
One of the other replies to my post said it better. They're not willing to engage in self-criticism. Thus, when anything at all gets said about Linux itself, it's positive.
Perhaps things have changed. I haven't read Groklaw (except for the odd linked article) for almost a year.
It was sufficiently annoying that I'm not going to be giving it another shot.
"Not likely. Too many Windows trolls post here. Especially the ones that act like they really like Linux, "it's just that Linux [fill in the blanks about usability, installs, and other ruminant evacuation.]" Sorry, these morons fool no one."
See, this is the attitude I'm talking about. Your attitude is that these criticisms are necessarily false. Anyone who disagrees must be a troll. They must have an agenda.
Groklaw has bugged me for a long time. They tend to wear rose colored glasses when looking at things like how good Linux is on the desktop. They're Linux users, but if you s/Linux/MacOS X/g, you could put most of the posts on a Mac forum and no one would look twice. In most places (like /.), you've got a healthy mix of people that use all kinds of OSes. Even if it takes zealots from the other camps (Mac, BSD, etc) to balance things out, they do eventually get balanced most of the time. Or failing that, at least you get another side presented, like the people whose transition to Linux stalled because something didn't work.
A few months after it got started, Groklaw turned into this orgy of groupthink with respect to issues of Linux technical and usability merit. Let's not turn Slashdot into that. It happens here on occasion, but it's well below critical mass. People do have legitimate problems with Linux, and there are technical reasons that it's not always the best choice.
The only thing we can take for granted is that SCO is full of shit.
What I wrote on the page:
"The worms keep my entropy buffer quite full."
Yes. Yes I should.
:) Thanks for pointing it out.
It wasn't an overflow... the behavior this causes is well documented. Left by itself, it would just read from the random device until it reached the memory limit and crashed. It would eat all of the randomness buffer, most of the CPU, and a fair bit of memory until that happened though. All in all a good DOS.
I was also going to set it up so it can't be invoked more than (say) once a second, but never got around to it.
That's why you use a good password..
I wrote this for my own use (I might be logging the results, and it doesn't use SSL, so don't use it yourself), but IMO an 8-character password from there will be good enough if your shadow file (or equivilant) isn't publically accessible. What system doesn't restrict your attempt rate anyway?
No. You need the server's cert to authenticate yourself.
Or at least, you're supposed to. You could self-sign and most people would probably click "accept".
(if only so I can justify unleashing wget)
:)
http://homestar.sytes.net/airpwn/
Parent deserves the karma, so don't mod me up until he gets to 5.
The interface is similar to a search engine. You load the front page, submit the URL, and you are presented with a user/pass combination. No additional steps are required.
How about a stable branch? Solaris actually has one.
The only up to date versions of Linux that can touch Solaris in scalability terms are now development versions. It's up to the distros to figure out how to make it stable.
'course, it's easier to nab the encryption keys on a Linux box...
a) You can't assume that everyone, everywhere will have the ability to install the shell of their choice.
/bin. The BSDs, for example, when they install it out of ports, put it in /usr/bin. This is correct because /bin is for base system files and shouldn't be touched by the user (on a BSD anyway). It's quite possibly mounted read only. It might even be on read only media, or on NFS you can't write to.
b) You can't assume that bash will be in
just use the more portable
#!/usr/bin/env bash
While it's nice to see someone on /. get it right for a change, I'm a bit irritated at the tiny number of people that actually read it. The whole thing is shorter than the GPL's preamble.
3-clause BSD license
The obvious course of action is to set up a multi-distribution kernel team to maintain a stable kernel, or to just use the kernel of a big distro like Red Hat or Suse. This would become the defacto stable kernel.
The 3rd party kernel would bring in patches from the development one, but this is of limited utility. As the BSDs have shown us, drift can build up pretty quickly. It's hard enough for them to backport stuff from FreeBSD 5.x to 4.x, and moving stuff between NetBSD and OpenBSD (still very similar) requires rewrites with the other code as a guide in many cases.
A commitment to stability is necessary for an OS to be taken seriously. This comes just after everyone saying that "2.6 is stable enough to switch!", so it's particularly disapointing. It's hard to keep a kernel stable when there's development patches coming in all the time.
Blah.
I don't run Linux on my servers because of less serious instances of this same problem. There are a few alternatives (Debian-stable et al), but they're even more out of date than OpenBSD. This just drives the point home.
"CISC chips run instructions simultaneously and out of order as well."
RISC chips can do this as well. In fact, they're generally better at it because they have more registers, and can therefore have more instructions without dependencies between them. For example, the PowerPC 970 can execute up to 5 instructions in one clock cycle if conditions are good. This is more than any CISC chip can do.
"RISC chips being faster than a CISC chip running at the same clock? Sorry, but no. That's completely unrealistic statement."
Not only is it possible, there are shipping processors that do exactly what you're saying is unrealistic.
CISC processors break things up into one or more internal RISC-like micro-ops. Instructions that require more than one micro-op (an add instruction that stores the results to memory for example) will require multiple internal ops. Exactly like a RISC chip does things, the RISC chip just doesn't hide what it's doing. This is why they can have similar performance. Or in the case of the P4, which is designed to increase the clock speed for marketting purposes, the RISC processor can have better performance per clock cycle.
You're completely wrong. Please shut up, read some of the papers on Ars Technica, and stop being wrong.
You can just download the install packages and burn your own CD. I've done that for years.
It's not as convenient as a FreeBSD ISO that you can just install, but if another 10 minutes is over your threshold for convenience, you won't like OpenBSD anyway. It takes a lot longer than that to adjust to things from most other OSes.
"I just wanted to point out you mentioned GCC. Sadly GCC is about the worst compiler in existence for performance."
That was my point. A shitty compiler with moderate optimization settings is very close in performance to one of the top compilers out there.
"The top compiler is infact the Intel compiler in part because it knows about unpublished instructions. Have fun reading the code it generates."
Yes, this was the example I used. The vectorized loops are a bitch to read.
"On the subject of G5s being faster, there are a whole host of differences between G5's and P4's. You can't just pick one difference and claim that's the reason."
That's true. However, I never gave a reason for the performance difference, so I'm not sure why you're saying this.
You said that RISC CPUs needed to run at a higher frequency to get the same performance as a CISC CPU. Since you're wrong, I gave an example to prove you wrong.
There is basically only one RISC CPU architechture that has the benefit of a really large R&D effort these days, and that's POWER/PowerPC. Itanium is not strictly RISC, and nothing else has the benefit of such a huge R&D effort.
Thus, the only RISC CPUs that can be fairly compared to x86 are the POWER/PowerPC chips from IBM. The only two x86 CPUs that have a really huge R&D effort behind them are the Athlons from AMD and the Pentiums from Intel.
They all have relatively similar performance (with advantages going to one or the other in a few niches). PowerPC chips are shipped at similar clock speeds to the Athlons and much lower clock speeds than the Pentiums.
Therefore, your statement that RISC CPUs need higher clock speeds to get the same performance has been demonstrated to be false in a comparison between the only 3 large chip makers in operation.
Further comparisons, such as those between Sparc and the VIA C3, which are smaller but significant efforts, show the RISC CPU getting more done per clock cycle, again demonstrating your statement to be false.
"Quick examples: RISC use less power because it has less logic? No, it needs to run at a higher frequency to maintain the same speed as a slower CISC."
No. This is exactly wrong. G5s are a good example of this. They easily outperform P4s at the same clock speed, and it's the P4 which must run at the higher speed to compensate.
The overhead of supporting all the various instructions and adressing modes, as well as being able to fit the whole CPU in one die were what made RISC a good choice in the past. Now, that overhead is dwarfed by other parts of the chip, and they're all running weird u-ops internally, so it makes little difference.
"RISC is easier to program? Depends on the person. A compiler can take advantage of large instructions very well which are hardware optimized."
Compilers are notorious for not utilizing esoteric opcodes. And when they do, there's almost never a significant performance advantage in doing so.
For example, none of the code I've ever tested with icc (one of the only compilers that can use weird opcodes on i386) has been more than about 5% faster than "gcc -Os -msse2", and a lot of it has been slower.
"RISC is physically smaller? No. RISC needs a higher clock frequency because many more instructions need to be executed. The result of this is that a much larger instruction cache is needed on chip.
RISC does generally need a larger cache, but it does not need a higher frequency.
"I don't remember every comparison but it pretty much comes out that neither is better than the other. That being said RISC is better than x86. Everything is better than x86. However CISC vs RISC is much harder to judge. Having done x86, 68k, and MIPS I must say that RISC is a pleasure."
Just use a compiler. Anything with a proper MMU will be good enough.
ahhh... but try Calgary. Filled with big oil companies, has one of the lowest costs of living in the US or Canada.
I make 40% less here than I did in Houston, but my quality of life is almost identical. On top of that, while I didn't save much in Houston, I save a lot every month here.
Plus, you know... not in Texas. w00t.
I think it's a reasonable to assume that anyone who makes an informed decision about what OS to use, even if they decide on Windows, is above average. Informed decisions have a higher probability of being another OS, because uninformed decisions are almost 100% Windows.
I'm biased towards BSD, but honestly I don't think each of them independantly create enough article traffic to justify extra icons.