(It is a bit more worrying if someone could pretend to be me and delete all my messages from the server.)
Well, unencrypted POP or IMAP don't encrypt usernames and passwords either. That's the real point about encrypting the connection: Encrypting the authentification. You're right, once your mail is out in the 'net, it's game anyway.
Normally, cron updatedb is heavily niced (19 on my box). So performance shouldn't suffer too much, except perhaps for I/O-heavy work. But locking up? No.
That's not a problem. It will simply take longer to deliver the message. The error isn't "No such user", it's a temporary failure. The list server will simply try again later. The timeout for responding to ML subscription confirmations is typically in excess of 24 hours, that is more than long enough.
I'd have thought a lot less than firing up SpamAssassin for every mail and parsing the body, decoding mime attachments etc.
1. SpamAssassin can run as a daemon, so no need to fire it up for every mail.
2. I think his point was the load on a busy sending server, like an ISP's. It would have to keep a lot more connections open since sending a mail to a server with Greylisting takes longer. With SA, the mail is accepted completely and only then scanned. Greylisting puts part of the load on the sending side, and what's worse: That load is only seen by legitimate senders and not by spammers, since they "fire and forget".
What's disappointing is that the Hurd kernel was such a dud. They've been trying to write a microkernel for a decade. Unfortunately, they started with the Mach interprocess communication model, and never escaped.
Well, they've learned the lesson and are beginning to switch the system to the much simpler and faster L4. Problem is that it doesn't have as much features as Mach (which is not a surprise, really, if you know Mach), and replacing them in user space is going to take some time. Still, the work is on, and in two years or so...
If you had RTFA, you'ld know that the point of the technology is rather on the billing and WLAN-side than on the GPRS/CDMA/3G/Your Favorite Mobile Data Standard Here side.
Most GPS systems don't use local tranbsponders. Only systems where accuracy is crucial and cannot be dependent upon the US military's whim use local transponders that send very accurate signals. Such configurations are used, for example, on some airports to guide planes to the tar strips. The accuracy of such systems can be measured in centimeters.
Before people point out that ILS does that without depending on GPS at all: True, but the paths that ILS can guide airplanes along are not very flexible. Difficult-to-reach airports like those situated in valleys gain a lot of alternative approach paths by using the GPS-based system.
Why do US mail carriers run around with the pouch over their shoulder? Back-relaxing solutions for varying distances I have seen include a trolley, a ruggedized bicycle and a scooter (as in Vespa).
Well, there are some libraries that are LGPL in KDE, too: KHTML and KJS (ECMA/JavaScript), for one. Apple chose KHTML and KJS for their Safari browser, and were able to do so exactly because it is LGPL'd.
Long answer: At least here in Germany and in the other places I've been in Europe, I can't confirm the article's claim. Of course, if you're in France with a German cell phone sending an SMS to a British cell phone currently in Switzerland (did that), it might take a few minutes for the message to arrive. But the only case of loss I encountered was when the receiving phone was shut off for longer periods of time, because SMSs time out after a sender-definable time span. So, to sum up, no gripes.
This is as good an argument as "But think about the children". The real question is, of course: Can we really prevent weather catastrophes without harmful side effects, both short and long term? If we save 5000 people from a tornado, but doom another 5000 people (or more, or less) to a flood in a possibly distant part of the world, should we do it?
I feel that is the question being asked here. We don't really understand the atmosphere. We may understand it well enough to prevent a single hurrican from happening in a certain area (or causing it to happen), but we don't know enough to understand the implictaions on a global scale. Our atmosphere is a highly comple system that intertacts globally. Local changes can have unpredicatble results (think of the butterfly causing a storm). Until we understand it better, we shouldn't use a weather changing system either as a safeguard or a weapon. Not a safeguard because we don't know whether we will harm others by using it, and not as a weapon because it might backire horribly.
First of all, here's a link to the story on The Dot, and Dirk Mueller's explanation. In summary, the Hackademy Audit Project discovered some bugs in KDE 3.0 some time ago, which have been fixed in 3.0.5 and 3.1RC4 (which was not released to the public). However, this also started a KDE-internal security audit, which, while not being completed yet, warranted a delay of the release. As soon as the audit is completed, a security fix release for 3.0 (3.0.6?) will hit the servers, along with patches for 2.2 and KDE 3.1. If you are interested in what exactly has been discovered, I suggest looking in the KDE mailing list archives.
Under KDE, you can switch Kexboard layouts on the fly: ControlCenter->Connected Devices->Keyboard->Layout. Activate the layouts you want (dvorak is among them), and an icon appears in Kicker that lets you change the layout with a click (okay, two clicks).
Which is why Apple won't do that unless they're compelled to, i.e. if Microsoft stops Mac development.
And how exactly would that help them? They are on x86 then, true, but it would still be MacOS X. Software written for Windows would still not run, though they'll perhaps be able to make use of (modified) Wine.
I think actually the situation is reverse: Should Apple release MacOS/x86, Microsoft would stop developing Mac software, thus probably dooming Apple.
This is not a huge problem - distcc is still great for production builds.
Uh, yeah, how often do you do production builds? Every 3 month? You can let that one run over night. It's the time the test builds take that really hurts productivity, and without debugging, they're worthless. So could it be this is a non.solution to an existing problem?
Slashdot Mirror
RTFA. The silk produced by worms and spiders is essentially the same.
Be aware that the memory on your video card shows up as memory used by X. Deduct that and you get the real RAM footprint.
blocks of up to 500ms
But that's still an order of magnitude less than that what the OP is experiencing. Turning DMA on is a Good Idea in any case.
(It is a bit more worrying if someone could pretend to be me and delete all my messages from the server.)
Well, unencrypted POP or IMAP don't encrypt usernames and passwords either. That's the real point about encrypting the connection: Encrypting the authentification. You're right, once your mail is out in the 'net, it's game anyway.
Is that the 'locate' database updating itself?
Normally, cron updatedb is heavily niced (19 on my box). So performance shouldn't suffer too much, except perhaps for I/O-heavy work. But locking up? No.
It may be that all of the IP is in the software
Huh? An IP stack in a NIC driver?
It's a Joke. Laugh (or don't, but don't take me seriously).That's not a problem. It will simply take longer to deliver the message. The error isn't "No such user", it's a temporary failure. The list server will simply try again later. The timeout for responding to ML subscription confirmations is typically in excess of 24 hours, that is more than long enough.
I'd have thought a lot less than firing up SpamAssassin for every mail and parsing the body, decoding mime attachments etc.
1. SpamAssassin can run as a daemon, so no need to fire it up for every mail.
2. I think his point was the load on a busy sending server, like an ISP's. It would have to keep a lot more connections open since sending a mail to a server with Greylisting takes longer. With SA, the mail is accepted completely and only then scanned. Greylisting puts part of the load on the sending side, and what's worse: That load is only seen by legitimate senders and not by spammers, since they "fire and forget".
What's disappointing is that the Hurd kernel was such a dud. They've been trying to write a microkernel for a decade. Unfortunately, they started with the Mach interprocess communication model, and never escaped.
Well, they've learned the lesson and are beginning to switch the system to the much simpler and faster L4. Problem is that it doesn't have as much features as Mach (which is not a surprise, really, if you know Mach), and replacing them in user space is going to take some time. Still, the work is on, and in two years or so...
They went right after someone who could afford to defend themselves, instead of trashing say, SuSe and RedHat.
SCO said that after they're done with IBM, they'll sue SuSE and Redhat (German).
If you had RTFA, you'ld know that the point of the technology is rather on the billing and WLAN-side than on the GPRS/CDMA/3G/Your Favorite Mobile Data Standard Here side.
Most GPS systems don't use local tranbsponders. Only systems where accuracy is crucial and cannot be dependent upon the US military's whim use local transponders that send very accurate signals. Such configurations are used, for example, on some airports to guide planes to the tar strips. The accuracy of such systems can be measured in centimeters.
Before people point out that ILS does that without depending on GPS at all: True, but the paths that ILS can guide airplanes along are not very flexible. Difficult-to-reach airports like those situated in valleys gain a lot of alternative approach paths by using the GPS-based system.
Noooo! Deutsche Telekom, take your hands off Linux!
For those who don't know them, about every product as a T prefixed: T-Mobile, T-Net, T-Systems, T-Online... and now T-LInux)
Why do US mail carriers run around with the pouch over their shoulder? Back-relaxing solutions for varying distances I have seen include a trolley, a ruggedized bicycle and a scooter (as in Vespa).
The tab closing button is a wishlst item that's already closed. Just didn't make it into 3.1.
Well, there are some libraries that are LGPL in KDE, too: KHTML and KJS (ECMA/JavaScript), for one. Apple chose KHTML and KJS for their Safari browser, and were able to do so exactly because it is LGPL'd.
Long answer: At least here in Germany and in the other places I've been in Europe, I can't confirm the article's claim. Of course, if you're in France with a German cell phone sending an SMS to a British cell phone currently in Switzerland (did that), it might take a few minutes for the message to arrive. But the only case of loss I encountered was when the receiving phone was shut off for longer periods of time, because SMSs time out after a sender-definable time span. So, to sum up, no gripes.
This is as good an argument as "But think about the children". The real question is, of course: Can we really prevent weather catastrophes without harmful side effects, both short and long term? If we save 5000 people from a tornado, but doom another 5000 people (or more, or less) to a flood in a possibly distant part of the world, should we do it?
I feel that is the question being asked here. We don't really understand the atmosphere. We may understand it well enough to prevent a single hurrican from happening in a certain area (or causing it to happen), but we don't know enough to understand the implictaions on a global scale. Our atmosphere is a highly comple system that intertacts globally. Local changes can have unpredicatble results (think of the butterfly causing a storm). Until we understand it better, we shouldn't use a weather changing system either as a safeguard or a weapon. Not a safeguard because we don't know whether we will harm others by using it, and not as a weapon because it might backire horribly.
First of all, here's a link to the story on The Dot, and Dirk Mueller's explanation. In summary, the Hackademy Audit Project discovered some bugs in KDE 3.0 some time ago, which have been fixed in 3.0.5 and 3.1RC4 (which was not released to the public). However, this also started a KDE-internal security audit, which, while not being completed yet, warranted a delay of the release. As soon as the audit is completed, a security fix release for 3.0 (3.0.6?) will hit the servers, along with patches for 2.2 and KDE 3.1. If you are interested in what exactly has been discovered, I suggest looking in the KDE mailing list archives.
Yeah, for example Daimler (primary brand: Mercedes), which has bought(1) *surprise* Chrysler. They also use Linux to drive their dealer network.
(1) Officially, it was a merger
Under KDE, you can switch Kexboard layouts on the fly: ControlCenter->Connected Devices->Keyboard->Layout. Activate the layouts you want (dvorak is among them), and an icon appears in Kicker that lets you change the layout with a click (okay, two clicks).
Imagine a Beowulf Cluster of these
It's called an office.
Which is why Apple won't do that unless they're compelled to, i.e. if Microsoft stops Mac development.
And how exactly would that help them? They are on x86 then, true, but it would still be MacOS X. Software written for Windows would still not run, though they'll perhaps be able to make use of (modified) Wine.
I think actually the situation is reverse: Should Apple release MacOS/x86, Microsoft would stop developing Mac software, thus probably dooming Apple.
Uh, yeah, how often do you do production builds? Every 3 month? You can let that one run over night. It's the time the test builds take that really hurts productivity, and without debugging, they're worthless. So could it be this is a non.solution to an existing problem?
You realize this doesn't work, right?