That's true if each block of the disk was written equally often. AFAIK, unless you use special file systems, that's not the case with common file systems today. Let's say you write one file once and only read it from then on. The access time would get updated each time, wearing out a single block faster than the rest.
1. Interrupt handling bottleneck. Even with interrupt mitigation your typical pps value for a single CPU P4 is under 100 kps. It falls down to under 60 kps when using Intel dual CPUs (dunno about AMD or Via) or SMT due to the overly deep pipeline on the P4. That is way less then 1G for small packets.
Within 30 seconds it had caught one of the mssql worms and had stopped the linux router dead. I'm not sure you diagnose the problem correctly. How should it be able to affect the router? If a Linux router is "stopped dead" by worm traffic, it's obviously flawed. I could understand if the worm saturated your line or whatever, but disabling the router completely?
When the security "experts" are busy looking at all the data passing through routers, who is busy ensuring that the "experts" will not violate my privacy by reading the personal but sensitive e-mail notes that I send to my friends and associates?
I might be wrong, but since now at least the basic instruction set of the processor will be the same as on common hardware, there could be a hacked OS X at some time in the future.
What I am sure about is that at least someone will try.
Is the BSD core kernel better? I don't know; I like its incarnation on my Amiga, but every now and again I miss kernel modules rather than spending 8 hours recompiling/netbsd because I'm about to add a different network card. (It's an Amiga, remember... a 25 MHz 68030 Amiga. Yes, it's damn slow.)
You said you use NetBSD? Ever thought of building your kernel on a fast i386 box? build.sh -m amiga kernel=... is everything you need. Hell, this should even work on a Linux box since build.sh is supposed to (cross-)bootstrap a NetBSD just about everywhere.
The comment was attached to the fall-through of a FPU probing snippet. IOW, they documented being clueless about what they detect if it's not one of the expected cases.
I gave Simon Lok in TFA the benefit of the doubt that he would not make such a decision based on a comment that is even out of context. Perhaps one should look for themselves.
# cd/usr/src # grep -ir 'Why is this here' * gnu/usr.bin/binutils/bfd/elf64-hppa.c:/* ??? Why is this here and not elsewhere is_local_label_name. */ gnu/usr.bin/perl/perlio.c: * Why is this here - not in perlio.h? RMB gnu/usr.bin/perl/pod/perlopentut.pod:Why is this here? Someone has to cater to the hysterical porpoises.
Becuase someone posts a comment in source questioning something doesn't seem to me to be a problem, it's there for a reason... a good reason would be to make other hackers take a closer look at it and make decisions based on it.
And that's exactly the difference. With OpenBSD or NetBSD you'd have a lengthy discussion about the design of an implementation before any code is actually committed to the kernel.
I agree with TFA that someone submitting code and asking in the comments whether this even belongs there speaks for itself about the quality and the overall design of the code.
As we audit source code, we often invent new ways of solving problems. Sometimes these ideas have been used before in some random application written somewhere, but perhaps not taken to the degree that we do.
* strlcpy() and strlcat() * Memory protection purify
o W^X
o.rodata segment
o Guard pages
o Randomized malloc()
o Randomized mmap()
o atexit() and stdio protection * Privilege separation * Privilege revocation * Chroot jailing * New uids * ProPolice *... and others
Did you actually look how chroot is implemented? It's not a complete shadow tree in e.g./var/chroot followed by a chroot/var/chroot/<daemon>/sbin/<daemon>. Instead, the tools switch to the chroot themselves via an appropriate command line switch. The chroot only contains stuff like device nodes.
That's it. The real config resides in the real/etc. Additionally:
-i chrootdir
Specify the path to a directory in which ntpd will run chrooted.
As to it being a PITA: Just adding ntpd_chrootdir ="/var/chroot/ntpd" to/etc/rc.conf is enough./etc/rc.d/ntpd takes care of the rest (populating the dir with the necessary files, adding the -i switch to ntpd).
Going away from SMTP, I am currently running a Squid HTTP proxy with a quite long blacklist of URLs and networks of "marketing" and "ad" companies.
I find myself doing for example a lookup of ad.marketingscum.com followed by a whois lookup of the IP address. If I find that they own a larger network like
Postfix-users mail is normally filtered into a special folder - based on the sender, return, to and cc addresses. For the last 3 days I have had the unfortunately 'pleasure' of having to use Windows rather than linux, consequently that filter is not automatic, so all postfix mail was sorted by hand.
Now, when I receive UCE and UBE, I quickly verify it's not real mail and move it to the special folder - the system takes care of it from there. In this case the message is spam and there was no information to indicate it was via the postfix mailing list without viewing source (which I don't do routinely), so the message was submitted as spam.
WTF. I'd say this moron isn't aware of his responsibility and the consequences of his actions.
"Oh, looks like spam *clicketyclick*" "You just blacklisted a major legitimate relay" "Whoops, stupid windows, go file a delist request"
What an asshole.
This story makes a good point about some of the amateurish procedures these lists are run with. Apparently it's really hard to pick a good one and in no way should you let it have sole authority over the finaly decision to block mail.
Slashdot Mirror
And I think it means Gbps. Unless cards wear out after 10 Gigabits. :)
That's true if each block of the disk was written equally often. AFAIK, unless you use special file systems, that's not the case with common file systems today. Let's say you write one file once and only read it from then on. The access time would get updated each time, wearing out a single block faster than the rest.
I'd say it's at least 25 years old. Pfft.
You need to speed up your R&D cycle to compete in today's market, Mr. astronomer guys.
Give them some credit. How would you do layer3 switching with routing protocols at wire speed in software[1]?
It's not that you need Cisco for that. But you certainly need hardware for that.
[1] Imagine 48 Gbps ports or something like that.
This sucks. :(
1. Interrupt handling bottleneck. Even with interrupt mitigation your typical pps value for a single CPU P4 is under 100 kps. It falls down to under 60 kps when using Intel dual CPUs (dunno about AMD or Via) or SMT due to the overly deep pipeline on the P4. That is way less then 1G for small packets.
0 4-September/004840.html
;-) Yes, way to go!"
from http://lists.freebsd.org/pipermail/freebsd-net/20
"PS: Linux guys where pretty much floored that FreeBSD 5.3 can route 1Mpps and
they can't do much more than 100kpps.
Within 30 seconds it had caught one of the mssql worms and had stopped the linux router dead. I'm not sure you diagnose the problem correctly. How should it be able to affect the router? If a Linux router is "stopped dead" by worm traffic, it's obviously flawed. I could understand if the worm saturated your line or whatever, but disabling the router completely?
Glass bones are perfect! They will eventually lead to super heros!
Yes, but what's your point? Should we outlaw encryption because terro.. excuse me.. botnet owners can use it, too?
When the security "experts" are busy looking at all the data passing through routers, who is busy ensuring that the "experts" will not violate my privacy by reading the personal but sensitive e-mail notes that I send to my friends and associates?
You, by encrypting them.
I might be wrong, but since now at least the basic instruction set of the processor will be the same as on common hardware, there could be a hacked OS X at some time in the future.
What I am sure about is that at least someone will try.
OSX isn't free
That's not what matters. If it runs on off-the-shelf Intel hardware (which I heard it probably won't) and is pirateable, then that's all that matters.
Of course running with outdated Apache and mod_ssl version is much better. Current versions are Apache 1.3.33 for the 1.x branch and mod_ssl 2.8.22.
Netcraft reports that the Server string last changed almost 2 years ago!
Might be fun, and oughta be done about 10 times faster.
Likely even faster.. a lot.
This is a build.sh -m amiga tools kernel=GENERIC from a
cpu0: AMD Athlon (686-class), 1494.13 MHz, id 0x681
build.sh started: Fri Jun 17 23:07:17 CEST 2005
build.sh ended: Fri Jun 17 23:25:26 CEST 2005
This includes building the complete infrastructure (make, compiler+crosscompiler, other tools) with which the kernel is finally crossbuilt.
This means if you keep the tools once you have built a kernel, subsequent build will be in the order of some minutes.
Is the BSD core kernel better? I don't know; I like its incarnation on my Amiga, but every now and again I miss kernel modules rather than spending 8 hours recompiling /netbsd because I'm about to add a different network card. (It's an Amiga, remember... a 25 MHz 68030 Amiga. Yes, it's damn slow.)
You said you use NetBSD? Ever thought of building your kernel on a fast i386 box? build.sh -m amiga kernel=... is everything you need. Hell, this should even work on a Linux box since build.sh is supposed to (cross-)bootstrap a NetBSD just about everywhere.
Good point about ripping comments out of context.
The comment was attached to the fall-through of a FPU probing snippet. IOW, they documented being clueless about what they detect if it's not one of the expected cases.
I gave Simon Lok in TFA the benefit of the doubt that he would not make such a decision based on a comment that is even out of context. Perhaps one should look for themselves.
Becuase someone posts a comment in source questioning something doesn't seem to me to be a problem, it's there for a reason... a good reason would be to make other hackers take a closer look at it and make decisions based on it.
And that's exactly the difference. With OpenBSD or NetBSD you'd have a lengthy discussion about the design of an implementation before any code is actually committed to the kernel.
I agree with TFA that someone submitting code and asking in the comments whether this even belongs there speaks for itself about the quality and the overall design of the code.
The software (kernel, tools, etc.) are no better, just the packaging.
.rodata segment ... and others
I'll bite.
From http://www.openbsd.org/security.html:
As we audit source code, we often invent new ways of solving problems. Sometimes these ideas have been used before in some random application written somewhere, but perhaps not taken to the degree that we do.
* strlcpy() and strlcat()
* Memory protection purify
o W^X
o
o Guard pages
o Randomized malloc()
o Randomized mmap()
o atexit() and stdio protection
* Privilege separation
* Privilege revocation
* Chroot jailing
* New uids
* ProPolice
*
Did you actually look how chroot is implemented? It's not a complete shadow tree in e.g. /var/chroot followed by a chroot /var/chroot/<daemon> /sbin/<daemon>. Instead, the tools switch to the chroot themselves via an appropriate command line switch. The chroot only contains stuff like device nodes.
/var/chroot/ntpd -type f /var/chroot/ntpd/dev/clockctl /var/chroot/ntpd/var/db/ntp.drift /var/chroot/ntpd/var/run/log
/etc. Additionally:
/etc/rc.conf is enough. /etc/rc.d/ntpd takes care of the rest (populating the dir with the necessary files, adding the -i switch to ntpd).
Example ntpd on NetBSD:
# find
That's it. The real config resides in the real
-i chrootdir
Specify the path to a directory in which ntpd will run chrooted.
As to it being a PITA: Just adding ntpd_chrootdir ="/var/chroot/ntpd" to
Pretty easy and clean if you ask me.
Going away from SMTP, I am currently running a Squid HTTP proxy with a quite long blacklist of URLs and networks of "marketing" and "ad" companies.
I find myself doing for example a lookup of ad.marketingscum.com followed by a whois lookup of the IP address. If I find that they own a larger network like
NetRange: 216.73.80.0 - 216.73.95.255
CIDR: 216.73.80.0/20
NetName: DOUBLECLICK-NET
I enter the complete network into my blacklist. Are there any realtime blacklists for this purpose? This would be quite useful, wouldn't it?
Postfix-users mail is normally filtered into a special folder - based on
the sender, return, to and cc addresses. For the last 3 days I have had
the unfortunately 'pleasure' of having to use Windows rather than linux,
consequently that filter is not automatic, so all postfix mail was
sorted by hand.
Now, when I receive UCE and UBE, I quickly verify it's not real mail and
move it to the special folder - the system takes care of it from there.
In this case the message is spam and there was no information to
indicate it was via the postfix mailing list without viewing source
(which I don't do routinely), so the message was submitted as spam.
WTF. I'd say this moron isn't aware of his responsibility and the consequences of his actions.
"Oh, looks like spam *clicketyclick*" "You just blacklisted a major legitimate relay" "Whoops, stupid windows, go file a delist request"
What an asshole.
This story makes a good point about some of the amateurish procedures these lists are run with. Apparently it's really hard to pick a good one and in no way should you let it have sole authority over the finaly decision to block mail.
May I suggest that you get a freaking clue about programming, patches and.. uh.. the general things about those weird computer boxes?
The second and last paragraph are complete bullshit.
I can only assume you are, in a weird way, trying to troll or something.
NetBSD likewise. You could actually do a complete cross-compile of amd64 2 years ago.
Can you compile a complete Gentoo for a slower alpha on a fast dual i386 box? Real question here.