I can easily get transfer rates of 800kb/s between two NE2000 clones. OS doesn't matter (if you care, over the time it was Linux 2.[02], FreeBSD 2.2.x,3.1, and now 4.0-current, NetBSD 1.[34], Solaris 2.6)
He should see whether upgrading to 2.2.10acx helps. And always use gcc 2.7.2.x for compiling kernels.
Strange what people do to fight spam. I used to get spam emails through my ISP's account (which I almost never use), but since I reminded the admin to turn on RBL, I haven't got a single piece of spam. The accounts I usually use also utilize RBL and I'm almost spam free.
And yes, I'm on about 10 public mailing lists and constantly active on 3 of them. My email address can be found in Altavista. I put it verbosely and outwritten on my homepage.
If it should ever become worse (more than one spam per week), I could easily add ORBS support to the SMTP servers I admin (and which handle my email).
The Linux PPP howto has not only information about setting up clients, but also a large chapter about setting up servers. It's available on every LDP and Metalab mirror.
Re:Yep, Alphas are great as workstations
on
RS/6000 Linux Box
·
· Score: 1
Right, I always get these two numbers wrong...
Yep, Alphas are great as workstations
on
RS/6000 Linux Box
·
· Score: 1
I'm sitting on a 633 MHz "Ruffian" Alpha w/ 256MB RAM. I would never deploy it as a server though. The speed of the box is really amazing.
With bladeenc, it takes about 45 minutes to encode 630MB ripped cd data in 128kbit/s mode. I think that is fairly good, since this box has only the "cheap" 21064a cpu (cheap is relative - the motherboard + cpu package was priced at about $1300 when I bought it).
If I'm not mistaken the USA has a monument which lists about 50.000 names of US soldiers who died in Vietnam. I wouldn't call that a "few," even if I'm not an American.
Imagine a university or company environment where you have a multiuser box where the people don't log out. I admin some boxes where you often have people with idle times > 1 day - leaving the memory claimed by their processes in RAM isn't very useful.
www.bitmover.com - he is doing contract work. As the other replies noted and what was explicitly stated at the end of the PS version is that he didn't develop the whole paper alone.
Afaik that doesn't do more than waiting for multiple objects to finish. In Unix, you could simply wait for each single one to terminate without much overhead (pthread_join).
MsgWaitForMultipleObjects
A design mistake (of Win32)
ReadFileEx/WriteFileEx
man aio
PulseEvent
You do know how to use message passing or other forms of IPC? The event functions could be easily replaced by pipes, for example.
Yes, I admit that Unix wasn't designed with multithreading in mind. In contrast, if you look at the recent standards formulated by POSIX and implemented by many vendors, you will notice that developing your application will not be limited by the API. In practice, being used to work with Microsoft "solutions" becomes a limiting factor.
That would be the correct term for the behaviour of RedHat. They don't seem to realize yet that they have actually competitors and that they must rally, if they want to survive.
The Linux FSSTD defines that no executable may be placed under/etc. init scripts are obviously executables (in the sense chmod +x) and therefore SuSE placed them in/sbin/init.d.
IMHO this doesn't make such a great difference. I admin several SysV-ish systems where the scripts are in/etc/init.d (Solaris, Debian Linux),/etc/rc.d/init.d (RedHat Linux), or/sbin/init.d (SuSE Linux). No problems with that.
As far as my comment goes regarding chaotic development, [...] Since when can anyone just insert their code in there without getting the approval of Linus?
I don't follow you here. If Linus controls the kernel, why is the development process chaotic?
If anyone could check in their changes, then it would be chaotic (at least in my understanding of the term "chaotic").
And no, slashdot.org doesn't run on FreeBSD. Don't know where you got that misinformation from. The image server however runs on FreeBSD (Rob wanted to try it out...)
I'm hardly a Linux bigot either (you seem to imply that). One of my boxes at home runs FreeBSD exclusively - it connects me to the Internet.
You constantly say that you are reporting only from your own perspective, based on your own experience.
That, of course, implies that I wanted you to define serving huge mission critical projects in exactly that context - in your own experience.
Now you reiterate again over the "FreeBSD is a better server OS" opinion. And again, you don't back it up by arguments.
Yes, there have been numerous exploits against Linux. Yes, they have been patched in a very short time. But you seem to imply that FreeBSD is not vulnerable against any attack of this kind.
Have you checked out rootshell.com lately? Some nice buffer problems in FreeBSD's fts, du, find, lprm, pppd, modstat, sendmail, and so on.
Yes, you don't need to reboot to fix these problems. But for example, FreeBSD 3.x can easily be panicked by using Unix domain sockets. That wouldn't work on Linux (yes, comparing single problems of various systems is plain dump. But you started that).
Final note: Running knowingle an exploitable sendmail version is simply irresponsible. Fine for you, if the crackers weren't able to crack that box. Assigning this "success" to FreeBSD is plain... (insert you favorite insult here).
"Oh, and by the way, you brought up" sendmail, not me.
You are wrong with the assertion that each distribution is an entire new OS. They all consist of 99% the same code (I made this number up, but you get the idea). The only major difference is how they are set up (i.e. paths, SysV-ish init vs. BSD-ish).
The major difference between Linuces and BSDs is that Linux is developed by only one party (splintered in many little groups focused on one project) while the BSDs are developed by completely different parties who don't work closely together (they coexist in peace, one could say. This happens to have historical reasons, for example OpenBSD which was founded after differences in the NetBSD developer team).
Funny, in exactly this second there is a mild distribution war taking place on linux-smp. Join in, if you have some time left.:-)
Read the php-dev mailing list archives.
Bah, I prefer VAX endianness
I can easily get transfer rates of 800kb/s between two NE2000 clones. OS doesn't matter (if you care, over the time it was Linux 2.[02], FreeBSD 2.2.x,3.1, and now 4.0-current, NetBSD 1.[34], Solaris 2.6)
He should see whether upgrading to 2.2.10acx helps. And always use gcc 2.7.2.x for compiling kernels.
Strange what people do to fight spam. I used to get spam emails through my ISP's account (which I almost never use), but since I reminded the admin to turn on RBL, I haven't got a single piece of spam. The accounts I usually use also utilize RBL and I'm almost spam free.
And yes, I'm on about 10 public mailing lists and constantly active on 3 of them. My email address can be found in Altavista. I put it verbosely and outwritten on my homepage.
If it should ever become worse (more than one spam per week), I could easily add ORBS support to the SMTP servers I admin (and which handle my email).
So long...
The Linux PPP howto has not only information about setting up clients, but also a large chapter about setting up servers. It's available on every LDP and Metalab mirror.
Right, I always get these two numbers wrong ...
I'm sitting on a 633 MHz "Ruffian" Alpha w/ 256MB RAM. I would never deploy it as a server though. The speed of the box is really amazing.
With bladeenc, it takes about 45 minutes to encode 630MB ripped cd data in 128kbit/s mode. I think that is fairly good, since this box has only the "cheap" 21064a cpu (cheap is relative - the motherboard + cpu package was priced at about $1300 when I bought it).
If I'm not mistaken the USA has a monument which lists about 50.000 names of US soldiers who died in Vietnam. I wouldn't call that a "few," even if I'm not an American.
Imagine a university or company environment where you have a multiuser box where the people don't log out. I admin some boxes where you often have people with idle times > 1 day - leaving the memory claimed by their processes in RAM isn't very useful.
yep, he is. And Linus will look at the tool. And eventually, it will become the standard Linux kernel source control system.
Having read linux-kernel at that time he came over as just another Unix ego. I don't trust these kind of people.
www.bitmover.com - he is doing contract work. As the other replies noted and what was explicitly stated at the end of the PS version is that he didn't develop the whole paper alone.
how to use rtfm anybody? (overheard on Dalnet #linux)
:-)
some guy on freebsd-hackers started a thread about a new utility called "rtfm." Guess what it does
Now that he has become a slick Penguin, he should finally be awarded with his own OS...
I wonder what will happen in the closet
WaitForMultipleObjects
Afaik that doesn't do more than waiting for multiple objects to finish. In Unix, you could simply wait for each single one to terminate without much overhead (pthread_join).
MsgWaitForMultipleObjects
A design mistake (of Win32)
ReadFileEx/WriteFileEx
man aio
PulseEvent
You do know how to use message passing or other forms of IPC? The event functions could be easily replaced by pipes, for example.
Yes, I admit that Unix wasn't designed with multithreading in mind. In contrast, if you look at the recent standards formulated by POSIX and implemented by many vendors, you will notice that developing your application will not be limited by the API. In practice, being used to work with Microsoft "solutions" becomes a limiting factor.
Here is the license of yast: click me
Yes, you cannot redistribute the entire cd set.
But no, once you remove yast and derived works, you can redistribute it.
I've been doing admin work for SuSE systems since years and have never used yast. You really don't need it, if you aren't a clueless newbie.
That would be the correct term for the behaviour of RedHat. They don't seem to realize yet that they have actually competitors and that they must rally, if they want to survive.
Btw, FSSTD stands for FileSystem STanDard. You can find the document on Metalab.
...but you need to remove these `unfree' packages first. Some years ago I saw this detailed in a README (iirc it was about burning CDs yourself).
The Linux FSSTD defines that no executable may be placed under /etc. init scripts are obviously executables (in the sense chmod +x) and therefore SuSE placed them in /sbin/init.d.
/etc/init.d (Solaris, Debian Linux), /etc/rc.d/init.d (RedHat Linux), or /sbin/init.d (SuSE Linux). No problems with that.
IMHO this doesn't make such a great difference. I admin several SysV-ish systems where the scripts are in
(ignoring the opinion thingies)
As far as my comment goes regarding chaotic development, [...] Since when can anyone just insert their code in
there without getting the approval of Linus?
I don't follow you here. If Linus controls the kernel, why is the development process chaotic?
If anyone could check in their changes, then it would be chaotic (at least in my understanding of the term "chaotic").
And no, slashdot.org doesn't run on FreeBSD. Don't know where you got that misinformation from. The image server however runs on FreeBSD (Rob wanted to try it out...)
I'm hardly a Linux bigot either (you seem to imply that). One of my boxes at home runs FreeBSD exclusively - it connects me to the Internet.
Nothing feels sluggish here.
Fine for you.
NetBSD has evolved since the split of OpenBSD. Do you compare Linux 1.0 to 2.2?
I didn't compare NetBSD to 4.4BSD-lite, did I.
You constantly say that you are reporting only from your own perspective, based on your own experience.
... (insert you favorite insult here).
That, of course, implies that I wanted you to define serving huge mission critical projects in exactly that context - in your own experience.
Now you reiterate again over the "FreeBSD is a better server OS" opinion. And again, you don't back it up by arguments.
Yes, there have been numerous exploits against Linux. Yes, they have been patched in a very short time. But you seem to imply that FreeBSD is not vulnerable against any attack of this kind.
Have you checked out rootshell.com lately? Some nice buffer problems in FreeBSD's fts, du, find, lprm, pppd, modstat, sendmail, and so on.
Yes, you don't need to reboot to fix these problems. But for example, FreeBSD 3.x can easily be panicked by using Unix domain sockets. That wouldn't work on Linux (yes, comparing single problems of various systems is plain dump. But you started that).
Final note: Running knowingle an exploitable sendmail version is simply irresponsible. Fine for you, if the crackers weren't able to crack that box. Assigning this "success" to FreeBSD is plain
"Oh, and by the way, you brought up" sendmail, not me.
Okay... Yahoo, IMDB.com, Walnut Creek CDROM... to name a few.
And you are running them all? And before you ran them, you tried Linux and it failed, and therefore you can judge that Linux is worse than FreeBSD.
Yes?
As for DoS attacks, I was talking about the OS
Again, what DoS attacks are possible against Linux?
On the topic of sendmail..
If you mean that serious, you are (literally) an idiot. The (in)security of sendmail has nothing to do with the OS.
And btw, I wasn't referring to sendmail exlusively. You can perform DoS attacks against every mail system.
kernel panic: kassert failed
:-)
You are wrong with the assertion that each distribution is an entire new OS. They all consist of 99% the same code (I made this number up, but you get the idea). The only major difference is how they are set up (i.e. paths, SysV-ish init vs. BSD-ish).
The major difference between Linuces and BSDs is that Linux is developed by only one party (splintered in many little groups focused on one project) while the BSDs are developed by completely different parties who don't work closely together (they coexist in peace, one could say. This happens to have historical reasons, for example OpenBSD which was founded after differences in the NetBSD developer team).
Funny, in exactly this second there is a mild distribution war taking place on linux-smp. Join in, if you have some time left.
Bye you "1d107 haxor."
Since when has bias became an excuse for misrepresenting technical facts?