Some years ago I was the computer guy for a fairly large network installation in a student dormatory. Because our 19in racks are (still) in the bicycle cellar, our equipment used to die of too much condensing wetness quite regularily.
So I ordered replacement parts and took the network switch out of the 19in rack into my apartment to replace all the components (thanks HP for their modular design). On the way I encountered a panicking student, who knew me as the guy responsible for the internet, and asked me _WHILE_ I was carrying an insanely large box with a giant bunch of network connectors, "Do you know that Internet stopped working, like, 5 minutes ago?"
Well, okay. This was just a polite way of saying that the LVM scripts & stuff in Debian woody (that's what I was talking about) are crappy. They work out of the box, for the sake of 2.4 compatibility. Which, IMHO, is not acceptable for a distro tagged "stable."
The kernel driver itself, DM, works great, as LVM did. (The only thing that did not work on kernel side in 2.6.0 was the Adaptec aic7xxx driver. With several 29160 cards, that hurt a lot.)
[...](I recommend www.backports.org), add their site to/etc/apt/sources.list [...]
Well, don't. Inserting the entire backports packet archive is a perfect way to ruin your system. Instead, browse their website, read the documentation, and manually install the packets you need.
Re:Instructions for 2.4 to 2.6 upgrades for Luddit
on
Linux 2.6.5 is Released
·
· Score: 4, Informative
Not that hard, actually.
Just get the packet "module-init-tools" from www.backports.org installed, if you plan to use modules.
The configuration dialogs are heavily restructured, but you'll find your stuff I guess. "make-kpkg" works fine.
If you have some rather peculiar stuff running, like LVM, there are some undocumented pitfalls, though.
... could be achieved by combining this with recent failures of GPS in Europe. See this article here (in German).
Abstract: Satellite SVN23 (PRN23) has gone off-line due to an "anomalous condition", which led to people having their GPS devices telling them they flew 14 km high with 120kph.
This is just a weak try. What it actually does is to move the weak spot of SMTP to another level, kinda out of SMTP down to IP. This whole principle will not help to reduce spam, it will even increase it: the "noise" in the DNS system, the exchange of valid IP addresses, etc. Plus: IP spoofing is not that hard. With this protocol at hand, just ask some mail servers for some valid IPs, and then build your own mail server with that IP. Thank you very much, now I do not even have the means of spoofed headers to proof it wasn't me.
There is a market IMHO. When I was still young and new to Linux, I installed FreeBSD on my box just for fun, and I was totally at loss to get this system work. Or getting myself working with the system. With a little more unix background in the meantime (driver programming and other stuff you do at a university) I think I could cope. Now, in the case of having Slowaris thrown at me, I would definitely appreciate every bit of help.
The existence of the BCD instruction, which is probably trapped in microcode by all modern implementations, is evidence of what exactly?
It is the evidence of a terribly overloaded instruction set, a I said before. Nobody really uses it anymore, as you said. What I wanted to say was "IMHO, it's a bad idea to add yet more complexity."
I do not like the changes proposed although x86 is awfully flawed (not enough GP registers, terribly overloaded instruction set {anyone ever used BCD commands? -- Yes, I hear the loud "We do" from the COBOL corner.}, you name it... ).
But this change would:
Make an internal interface explicitly controlled by the programmer/compiler, loading an enormous amount of work on the compiler creators. (Just have a look at IA64 - is there any good compiler out there already? I haven't had a look for a while.)
Destroy (or at least reduce the efficiency) of the internal register renaming unit, thus slowing down the out-of-order execution core and such (the entire core, actually...)
Sorry, but this man may have been busy programming x86 assembly his entire life (and for this he deserves my respect), but he is not up to date on how a modern x86 cpu works in its heart. When I heard the lectures in my university about how this stuff works, I gave up learning assembly -- one just doesn't need it anymore with the compilers around.
Reading the books by Hennesy/Patterson (don't know if I spelled them correctly) may help a lot.
Slashdot Mirror
Some years ago I was the computer guy for a fairly large network installation in a student dormatory. Because our 19in racks are (still) in the bicycle cellar, our equipment used to die of too much condensing wetness quite regularily.
So I ordered replacement parts and took the network switch out of the 19in rack into my apartment to replace all the components (thanks HP for their modular design).
On the way I encountered a panicking student, who knew me as the guy responsible for the internet, and asked me _WHILE_ I was carrying an insanely large box with a giant bunch of network connectors, "Do you know that Internet stopped working, like, 5 minutes ago?"
Someone is begging for a flamewar here. Out of topics that actually matter?
Personally, I grew up with Debian, so my preferences are clear. It might have its shortcomings, but I learned to cope with these over time.
Guess it's a slow news day
Yeah, except for the bombings in Saudi Arabia and Iraq, nothing special happened. After all, people die violently every day, so why bother? *yawn*
LVM? Peculiar? UNDOCUMENTED? Give me a break!
Well, okay. This was just a polite way of saying that the LVM scripts & stuff in Debian woody (that's what I was talking about) are crappy. They work out of the box, for the sake of 2.4 compatibility. Which, IMHO, is not acceptable for a distro tagged "stable."
The kernel driver itself, DM, works great, as LVM did. (The only thing that did not work on kernel side in 2.6.0 was the Adaptec aic7xxx driver. With several 29160 cards, that hurt a lot.)
So much for any hope of moving our cluster to 2.6
Just go ahead and upgrade. 2.6 rocks.
[...](I recommend www.backports.org), add their site to /etc/apt/sources.list [...]
Well, don't. Inserting the entire backports packet archive is a perfect way to ruin your system. Instead, browse their website, read the documentation, and manually install the packets you need.
Not that hard, actually.
Just get the packet "module-init-tools" from www.backports.org installed, if you plan to use modules.
The configuration dialogs are heavily restructured, but you'll find your stuff I guess. "make-kpkg" works fine.
If you have some rather peculiar stuff running, like LVM, there are some undocumented pitfalls, though.
Shouldn't this article be named more properly Gates for Spam, or Gates of Spam?
Those get tossed, or made into keychains or the like.
So YOU're the guy with that 300mm keychain.
... could be achieved by combining this with recent failures of GPS in Europe. See this article here (in German).
Abstract: Satellite SVN23 (PRN23) has gone off-line due to an "anomalous condition", which led to people having their GPS devices telling them they flew 14 km high with 120kph.
....they have to find his weapons of mass decep^H^H^Hstruction.
sovietrussium
This is just a weak try. What it actually does is to move the weak spot of SMTP to another level, kinda out of SMTP down to IP.
This whole principle will not help to reduce spam, it will even increase it: the "noise" in the DNS system, the exchange of valid IP addresses, etc.
Plus: IP spoofing is not that hard. With this protocol at hand, just ask some mail servers for some valid IPs, and then build your own mail server with that IP.
Thank you very much, now I do not even have the means of spoofed headers to proof it wasn't me.
There is a market IMHO.
When I was still young and new to Linux, I installed FreeBSD on my box just for fun, and I was totally at loss to get this system work. Or getting myself working with the system.
With a little more unix background in the meantime (driver programming and other stuff you do at a university) I think I could cope.
Now, in the case of having Slowaris thrown at me, I would definitely appreciate every bit of help.
The existence of the BCD instruction, which is probably trapped in microcode by all modern implementations, is evidence of what exactly?
It is the evidence of a terribly overloaded instruction set, a I said before. Nobody really uses it anymore, as you said. What I wanted to say was "IMHO, it's a bad idea to add yet more complexity."
But this change would:
Make an internal interface explicitly controlled by the programmer/compiler, loading an enormous amount of work on the compiler creators. (Just have a look at IA64 - is there any good compiler out there already? I haven't had a look for a while.)
Destroy (or at least reduce the efficiency) of the internal register renaming unit, thus slowing down the out-of-order execution core and such (the entire core, actually...) Sorry, but this man may have been busy programming x86 assembly his entire life (and for this he deserves my respect), but he is not up to date on how a modern x86 cpu works in its heart. When I heard the lectures in my university about how this stuff works, I gave up learning assembly -- one just doesn't need it anymore with the compilers around.
Reading the books by Hennesy/Patterson (don't know if I spelled them correctly) may help a lot.