None of the current chip manufacturers has opted to move the southbridge or northbridge into the CPU, despite the fact that this would improve performance, without having to speed the chip up.
I believe AMD's Opterons (and possibly Athlon 64) have embedded Northbridge.
Intel moved to copper from aluminium for chip interconnects, because it reduced power consumption. If they moved to silver, they could reduce it further, so the chips could run cooler and/or faster, with no additional work. There's no evidence they're even looking at that.
It's not as easy as taking a better conductor (one with lower intrinsic resistance) and slapping it on silicon. You have to make it stick on the silicon, and you have to be able to build layers of the stuff. Aluminium bonds pretty easily with silicon. Copper is harder to deposit on the silicon substrate, that's why it took foundries so long to come up with copper interconnect chips.
Brilliantly BAD... Now you may have to use e2defrag on a regular basis...
These 5% are actively used by ext2 to avoid fragmentation. Sure, you may gain an extra 5% space, at the cost of some performance.
While you're at it, investigate the -i and -N options which control the number of inodes (who need so many inodes anyway, huh?), and if you're an ext3 user, also try a 1 MB journal with -J size=1. This way you may squeeze the last byte of your hard disk.
the conservation of energy is a law, it explains why things must happen, it doesn't explain why they happen.
a rocket works in space because the expanding gas exterts more pressure on the aft-facing components of the engine (including other gasses) than the bow facing ones.
No, dude!
A rocket in space move forwards because of the law of action / reaction. Also know as Newton's third law of motion:
For every action there is an equal and opposite reaction.
A rocket moves forwards because by sending the combustion gasses to the back of the rocket, the reactive force pushes the rocket forward.
Also because in 64-bit mode, the Opteron has access to more registers. The IA-32 architecture is so register-limited that throwing more registers at any task makes a huge difference.
The DJB wanabees are pushing their idol's software, and ISC gets the flak for having designed a very good patch. The problem is not with the patch itself, it's how it is used.
The first patch
ISC initially designed Verisign wilcard blocking patch so that one can mark a zone as delegation only. Explanation: the TLD servers (the one that serve.com,.net,.us, etc) should not contain any domain information: their purpose is just to point to the actual name server for a given domain:
When a.com TLD server is asked for existingdomain.com, it replies: for any address below existingdomain.com, ask this and this servers. That's a delegation answer.
When asked for non-existingdomain.com, the gtld server used to reply: there is no such domain.
When Verisign introduced their sitefinder service, they basically configured their server to say: non-existingdomain.com is at this address. Compare that with the ask this other server. That's not a delegation. It's a straight answer.
So, the first ISC patch allowed people to mark a zone (eg..com) as delegating-only. All straight (i.e. non-delegating) answers from a delegating-only zone are interpreted as no such domain.
Note to the DJB groupies: that's much cleaner than passing an IP address to be ignored in an environment variable. For once, with the bind approach, you can still access www.sitefinder.com. It's only the unwanted wildcard referrals that are blocked, not a given IP address.
Second (and current) patch
Then people noticed that all TLD ought to be delegation-only (they were wrong) and objected to have to write a stanza in the configuration file for every TLD. That's why the second patch was introduced.
This time, in addition to the configuration directive saying "this zone is delegation only", a new configuration directive was introduced: "all TLDs are delegation-only". You may also provide a a TLD exclusion list for the few domains that were known to have non-delegation records (like.de).
Some misinformed admins started using this new directive with just the few known non-delegating domains excluded, but more TLDs than previously thought had non-delegating records in their TLD zone. Like.name. And that's what they're complaining about.
Summary
If you use the.com and.net are delegation-only zones configuration directive, you're doing good.
If you use the all TLDs but a select few are delegation-only, then you must make sure you have the exhaustive list of non-delegating TLDs. Since no-one has the exhaustive list yet, so I suggest you just mark.com and.net for the moment.
If you use DJBDNS, stop showing such misplaced zealotry.
There are several reasons why Linux does not have non-executable stacks yet...
One of them is that gcc and the kernel use trampolines. From the gcc docs:
A "trampoline" is a small piece of code that is created at run time
when the address of a nested function is taken. It normally resides on
the stack, in the stack frame of the containing function.
AFAIK, linux uses trampolines at least in these places:
Gcc uses them for nested functions (not very common though, but glibc has quite a few of those).
The linux kernel uses (used?) trampolines for signal delivery.
Both problems can be addressed (the openwall patches take care of the kernel trampolines), but it's not as easy as turning off the PROT_EXEC bits in the stack.
Also, a non-exec stack is not a silver bullet: it only makes exploiting buffer overflows somewhat harder. Check out this article from Solar Designer (the OpenWall patch author).
On top of the above:
Multithreaded programs have more than one stack, and they're not necessarily contiguous.
As Theo's mail says, the i386 arch (which is still the most common linux arch, despite its suckiness) has a very limited way of implementing PROT_READ && ! PROT_EXEC pages:
The i386 is not capable of doing per-page execute permission.
At most it is only capable of drawing a line through the address
space, by limiting the code segment length (using the code segment
register). So we can say, "from 0 to this point is executable"
and "from that point on to the end of userland is not executable".
You may now understand why Linus has so far judged that a non-executable stack was more trouble than it was worth.
You've just sayed that it's all right to rob the public and behave in a monopolistic manner as long as you redistribute a tiny part of the profit as charity.
Or do a lot of bad things as long as you use some of the benefits to do good things.
With this logic, one can justify anything... Hey, you should do politics!
68K architecture may have 16 registers, but they are 16-bit, while x86 are 32-bit.
Check your facts dude: the 68K has 16 32-bits registers (actually 17 if you count the dual A7 stack pointer, the 68k has two hardware stack registers, one for user-mode and one for supervisor-mode).
On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used.
WTF are you talking about? A7 is typically used as stack pointer and A6 as frame pointer. That leaves 14 usable registers.
The complexity of checking a board of x columns by y rows is 8*x*y (8 because you need to check the 8 adjacent positions for every position). And I can see some algorithms faster than that by using rolling sums...
Yes, they are different things. Weight is the force exerted on an object put on a gravitational field. Mass is an object's intrisic property.
I think you were confusing the weight/mass issue with an other troubling coincidence which is: Why inertial mass and gravitational mass are the same thing?
Gravitational mass is the gravitation force "charge". Like electrostatic attraction (or repulsion) between to electrically charged object is proportional to their electric charge, gravitational attraction between two massive objects is proportional to their gravitational charge, aka mass.
Inertial mass is something else. The energy expense needed to accelerate an object is proportional to its inertial mass.
As far as I know, both inertial and gravitational mass have been experimentally verified to be the same, and general relativity is mostly based on that equivalence (one cannot distinguish between a small region of space subject to gravitational force from an other small regsion subject to constant acceleration) but we do not know why these two properties of particles are the same.
At the end of the article, they recommend blocking some ICMP messages and mention echo reply and request, and destination unreachable...
Blocking ICMP destination unreachable of type fragmentation needed will give a hard time to PMTU discovery (eg. Linux, FreeBSD, any OS with a decent TCP/IP stack).
Why would you want to do that ? Are there any exploits using ICMP ? I know you can tunnel stealthily using ICMP, but any protocol can be used as tunnel...
I had so many problems with linux's NFS implementation that I've tried FreedBSD 3.3 and the STABLE branch.
I was quite pissed by FreeBSD's behavior in this respect. Altough it had NFS v3 and NQNFS, I got several problems:
NFS would hang forever when a server rebooted: mounting with NFS v2, v3 or NQNFS with FreeBSD server and client, cd to a NFS-mounted directory, reboot the NFS server, do ls while the server reboots, watch it hang forever.
The AMD automounter does not pass all the parameters to the kernel: the fancy nfs parameter (nqnfs, etc...) don't get passed to the kernel because AMD doesn't know about them...
The mount command does not show all the mount parameters: This is related to the previous one. While trying to find out what mount options were passed by AMD, I could not get to know exactly what was being passed to the kernel, and I had to use the debugger to do that. In FreeBSD, the mtab is kept in the kernel, and the kernel table does not record all the NFS-related flags.
Unrelated: although the port system rocks, the package system sucks: I really liked the ports collection. However when files are installed, the packaging system often fails to register all the files, and upgrading was a major chore. The ports builds have to be run as root, which is also an annoyance for me.
Of course, Linux NFS is even worse. But when I was so pissed about Linux's NFS, I gave FreeBSD a serious try and attempted to convert all my servers to FreeBSD. After 3 weeks, I reverted to Linux because I was deceived by the above NFS thing.
Slashdot Mirror
Bullshit, the only reason you avoid braking abruptly is to reduce wear on the brake pads. No shmancy third order effect :-)
Yeah, notorious amongst the Gentoo fanboyz...
http://linux.bkbits.net:8080/linux-2.5/diffs/inclu de/asm-i386/i387.h@1.16?nav=index.html|src/.|src/i nclude|src/include/asm-i386|hist/include/asm-i386/ i387.h
And do not forget to visit Bob the Angry Flower, that's where I got the link... and this week's cartoon (Bombs of love) is hilarious too.
All that lost karma!!! It should be mine!!!
Okay... This is the result of a cursory check, do your homework folks!
The R128 DRI bounds checking bug is a potential local root exploit.
According to this patch 2.4.26 contains the fix.
The isofs bug. It is locally exploitable iff you have hardware access or if you can induce someone to mount a compromised medium.
The ext3 information leak. It cannot lead to any exploit and has only the tiniest chances of giving an attacker any usable information.
The SoundBlaster Denial of Service.
But no, no mremap issues...
</KARMA>
These 5% are actively used by ext2 to avoid fragmentation. Sure, you may gain an extra 5% space, at the cost of some performance.
While you're at it, investigate the -i and -N options which control the number of inodes (who need so many inodes anyway, huh?), and if you're an ext3 user, also try a 1 MB journal with -J size=1 . This way you may squeeze the last byte of your hard disk.
No, dude!
A rocket in space move forwards because of the law of action / reaction. Also know as Newton's third law of motion:
A rocket moves forwards because by sending the combustion gasses to the back of the rocket, the reactive force pushes the rocket forward.
Add to that:
Also because in 64-bit mode, the Opteron has access to more registers. The IA-32 architecture is so register-limited that throwing more registers at any task makes a huge difference.
Duh. There's no work-around if you want to connect anonymously.
Yes and yes.
Then we'll have to use some other tricks to prevent sitefinder from breaking DNS.
The DJB wanabees are pushing their idol's software, and ISC gets the flak for having designed a very good patch. The problem is not with the patch itself, it's how it is used.
The first patch
ISC initially designed Verisign wilcard blocking patch so that one can mark a zone as delegation only. Explanation: the TLD servers (the one that serve .com, .net, .us, etc) should not contain any domain information: their purpose is just to point to the actual name server for a given domain:
- When a
.com TLD server is asked for existingdomain.com, it replies: for any address below existingdomain.com, ask this and this servers. That's a delegation answer.
- When asked for non-existingdomain.com, the gtld server used to reply: there is no such domain.
- When Verisign introduced their sitefinder service, they basically configured their server to say: non-existingdomain.com is at this address. Compare that with the ask this other server. That's not a delegation. It's a straight answer.
So, the first ISC patch allowed people to mark a zone (eg.Note to the DJB groupies: that's much cleaner than passing an IP address to be ignored in an environment variable. For once, with the bind approach, you can still access www.sitefinder.com. It's only the unwanted wildcard referrals that are blocked, not a given IP address.
Second (and current) patch
Then people noticed that all TLD ought to be delegation-only (they were wrong) and objected to have to write a stanza in the configuration file for every TLD. That's why the second patch was introduced.
This time, in addition to the configuration directive saying "this zone is delegation only", a new configuration directive was introduced: "all TLDs are delegation-only". You may also provide a a TLD exclusion list for the few domains that were known to have non-delegation records (like .de).
Some misinformed admins started using this new directive with just the few known non-delegating domains excluded, but more TLDs than previously thought had non-delegating records in their TLD zone. Like .name. And that's what they're complaining about.
Summary
If you use the .com and .net are delegation-only zones configuration directive, you're doing good.
If you use the all TLDs but a select few are delegation-only, then you must make sure you have the exhaustive list of non-delegating TLDs. Since no-one has the exhaustive list yet, so I suggest you just mark .com and .net for the moment.
If you use DJBDNS, stop showing such misplaced zealotry.
There are several reasons why Linux does not have non-executable stacks yet...
One of them is that gcc and the kernel use trampolines. From the gcc docs:
AFAIK, linux uses trampolines at least in these places:
Both problems can be addressed (the openwall patches take care of the kernel trampolines), but it's not as easy as turning off the PROT_EXEC bits in the stack.
Also, a non-exec stack is not a silver bullet: it only makes exploiting buffer overflows somewhat harder. Check out this article from Solar Designer (the OpenWall patch author).
On top of the above:
You may now understand why Linus has so far judged that a non-executable stack was more trouble than it was worth.
Yeah, sure...
You've just sayed that it's all right to rob the public and behave in a monopolistic manner as long as you redistribute a tiny part of the profit as charity.
Or do a lot of bad things as long as you use some of the benefits to do good things.
With this logic, one can justify anything... Hey, you should do politics!
Absolutely true: http://worstphotos.fifi.org/pix/pix-00039.jpg. Seen on WinNT 4.0.
68K architecture may have 16 registers, but they are 16-bit, while x86 are 32-bit.
Check your facts dude: the 68K has 16 32-bits registers (actually 17 if you count the dual A7 stack pointer, the 68k has two hardware stack registers, one for user-mode and one for supervisor-mode).
On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used.
WTF are you talking about? A7 is typically used as stack pointer and A6 as frame pointer. That leaves 14 usable registers.
Check out: http://membres.lycos.fr/larance/main1.html (french), http://www.edf.fr/html/fr/decouvertes/voyage/usine /usine_d.html (french) or http://www.edf.fr/html/en/decouvertes/voyage/usine /retour-usine.html (english).
The 240 MW figure comes from this page: the power plant contains 24 groups, eeach group able to ouput 10 MW.
In summary:
See it here.
Uh, why would it be NP ?
The complexity of checking a board of x columns by y rows is 8*x*y (8 because you need to check the 8 adjacent positions for every position). And I can see some algorithms faster than that by using rolling sums...
Or am I missing something here ?
Yes, they are different things. Weight is the force exerted on an object put on a gravitational field. Mass is an object's intrisic property.
I think you were confusing the weight/mass issue with an other troubling coincidence which is: Why inertial mass and gravitational mass are the same thing?
- Gravitational mass is the gravitation force "charge".
- Inertial mass is something else. The energy expense needed to accelerate an object is proportional to its inertial mass.
As far as I know, both inertial and gravitational mass have been experimentally verified to be the same, and general relativity is mostly based on that equivalence (one cannot distinguish between a small region of space subject to gravitational force from an other small regsion subject to constant acceleration) but we do not know why these two properties of particles are the same.Like electrostatic attraction (or repulsion) between to electrically charged object is proportional to their electric charge, gravitational attraction between two massive objects is proportional to their gravitational charge, aka mass.
At the end of the article, they recommend blocking some ICMP messages and mention echo reply and request, and destination unreachable...
Blocking ICMP destination unreachable of type fragmentation needed will give a hard time to PMTU discovery (eg. Linux, FreeBSD, any OS with a decent TCP/IP stack).
Why would you want to do that ? Are there any exploits using ICMP ? I know you can tunnel stealthily using ICMP, but any protocol can be used as tunnel...
90% of ICMP should not be blocked IMHO.
I had so many problems with linux's NFS implementation that I've tried FreedBSD 3.3 and the STABLE branch.
I was quite pissed by FreeBSD's behavior in this respect. Altough it had NFS v3 and NQNFS, I got several problems:
- NFS would hang forever when a server rebooted: mounting with NFS v2, v3 or NQNFS with FreeBSD server and client, cd to a NFS-mounted directory, reboot the NFS server, do ls while the server reboots, watch it hang forever.
- The AMD automounter does not pass all the parameters to the kernel: the fancy nfs parameter (nqnfs, etc...) don't get passed to the kernel because AMD doesn't know about them...
- The mount command does not show all the mount parameters: This is related to the previous one. While trying to find out what mount options were passed by AMD, I could not get to know exactly what was being passed to the kernel, and I had to use the debugger to do that. In FreeBSD, the mtab is kept in the kernel, and the kernel table does not record all the NFS-related flags.
- Unrelated: although the port system rocks, the package system sucks: I really liked the ports collection. However when files are installed, the packaging system often fails to register all the files, and upgrading was a major chore. The ports builds have to be run as root, which is also an annoyance for me.
Of course, Linux NFS is even worse. But when I was so pissed about Linux's NFS, I gave FreeBSD a serious try and attempted to convert all my servers to FreeBSD. After 3 weeks, I reverted to Linux because I was deceived by the above NFS thing.