Hrmmm? And the Republicans aren't doing this? It's hard to listen to a George W. speech (or Buchanan for that matter) without them harping about "judges legislating from the bench." (ie, making decisions that they disagree with) The Supreme Court seems equally exploited by both sides.
Re:Iain M Banks - famous for being famous?
on
Look to Windward
·
· Score: 2
Hrmmm. I'm a big Banks fan and due to that just read Ken McLeod's "The Star Fraction". I was extremely disappointed. Perhaps his other books are better? TSF seemed tedious, a lot of confusing fillers crammed together with unbelievable political philosophies/situations. Would you say his other stuff is better or more of the same? (possibly I just don't like his style)
A lot of his non-fiction isn't quite as grim however. I read Song of Stone and hated it, yet at the same time, I loved "The Bridge," "The Crow Road" and "Walking on Glass" (short but extremely clever). Like any author he has his ups and downs ("Whit" was particularly forgettable). But, one of his strengths is that everything isn't extremely sugar-coated. I think his writing benefits from the fact that he isn't afraid to throw some curveballs at the reader, even if he sometimes goes too far.
While I agree that LTW isn't one of Banks' strongest books, I definitely enjoyed it (especially after Inversions which was, IMO, extremely disappointing) and if you're a Banks fan wouldn't hesitate to recommend it.
In case anyone's unaware, there's an alt.fan.iain-banks usenet group...
I'm another American who ordered from the UK, why can't we get Banks here in a reasonable time?
Re:That's absolutely crazy thinking.
on
Microsoft Cracked
·
· Score: 2
Wine's running Diablo II perfectly as well, without any Windows DLLs for me whatsoever. I tend to think that looking at the history of Wine it would be hard for Microsoft to be able to claim any sort of collusion. It's really a tribute to the Wine team that they've been plugging at it for 5 years and it's now bearing some real fruit.
If I remember correctly, it's been speculated by many people that the Windows TCP/IP stacks are BSD-derived (perhaps because the bugs they've suffered from seem similar?). However, Microsoft has always denied that claim and said that their stack is a ground-up implementation of their own.
Is there a reason you feel a need to put your posts in a block? Presumably you have some reason asides from the fact that Courier is harder on the eyes. Or is it just supposed to be/-r4d 31337?
Offhand it sounds almost like the SCSI bus is being reset. Have you checked your kernel messages? Obviously, check the termination and everything as well, but you've probably done that already. Could just be flaky drivers...
I think you're not reading in threaded mode or something...I was responding to a post pointing to a review of Accelerated X, also made by Xi Graphics...
I think "great" might be overrating it a bit. The author bought a piece of barely supported (by XFree86) hardware and then bought AX. If you want to experience a similar effect, try this:
1) Buy ATI VGAWonder(Circa 1989 or so).
2) Be amazed at how slow XFree runs
3) Buy a Matrox G400.
4) Be amazed at how fast XFree runs
5) Write an article lauding XFree
Short version: Buying poorly supported hardware will color your impressions of software. Most tests show XFree to be pretty equivelent to AX on modern graphics cards...
That's silly. You simply don't want an MUA setuid root. PERIOD. How many security notices have you seen where a program doesn't give up privs properly? More than I can count for sure. The lesson is that unless you have a really really good reason for it, an app should not be setuid anything. Not trusting swap space on a machine isnt' a good reason - as I noted before, if you don't trust the machine you're typing something into, there are already tons of other ways to get your password.
Now I've got a lot more trust about the robustness of mutt programming than, for instance, pine (*gag*), but I still wouldn't want it setuid root.
As others have pointed out, your objections to mutt are all basically invalid. A couple of things I don't think others have touched on:
* "protected memory"? You mean you want to mlock() the page with your password on it? That would require mutt to be suid root since only root can wire pages in memory. Hardly seems like a good idea.
*/proc and readability - if someone can read/proc for your process they've either hacked your account or they have root. In any case, if they've done either of those there's nothing stopping them from using any of a dozen other ways to get your password (trojanned gpg/pgp binary perhaps?). Bottom line: If you ever type your password in, you're implicitly trusting that machine.
www.cdindex.org is trying to come up with a flexible alternative, but I don't think they have anything usable yet.
CDDB is ok for what it wants to do - given a cd in a drive, id it, but it's way too limitted as a generic media database. Hopefully a better effort will succeed.
WinNT64 isn't "nowhere in sight." It runs, albeit slowly and really flaky. Hopefully Linux runs better than it (no experience there) but with Itanium getting closer to shipping, the landscape is looking pretty bare for operating systems.
Hrmmm, people's memories are short. When Al started up the "Opensource website" crap, I seem to remember that he was actually running NT or something. Only after people started crying hypocrisy did he switch to Linux. (ie, this was a political move, not anything coming from some deep idealogical standpoint)
The point is that if every ISP filtered outgoing packets to make sure that they came from legitimate IP addresses, while it may not stop DOSes, it would at least make it a LOT easier to shut down the offending sites since they couldn't lie about where they were coming from. Currently when you get DOSes, it requires a hellish amount of effort from the backbone providers if you want to try to figure out where the (spoofed) packets are coming from.
This is a convenient ivory-tower way of looking at coding, however the fact is that any large complex problem (ie the ones you'd like to use threading or multiple processes for) have bugs. Period. Being able to recover better from bugs is simply a good thing, especially when you're going for reliability (databases, anyone?).
And asides from that, you don't even know if the bug is yours - For instance, Apache processes die off after handling a certain number of requests to try to limit the effect of memory leaks *in vendor libraries*. It's nice working on (Linux|*BSD) where you can just fix the library in question, but if you have to work on Irix, Siemens Unix or something even more obscure, do you want to be waiting on a vendor to get you a bug fix? And of course the libc on various systems may have even more nefarious bugs than memory leaks...
In short, in an ideal world, threading is probably almost always the more attractive solution. In the real world, however, compromises sometimes need to be made, and frequently fork() is a good compromise.
(I know this isn't the meat of your comment but...)
> Unix programmers seems to dislike using threads > in their applications. After all, they can just > fork(); and run along instead of using the > thread functions.
This is a somewhat naive view of threading on Unix. The biggest factor is probably that many Unix programs don't use threads because they're not portable - only relatively "modern" (as Unix systems go) systems support them. Yes, you can go with userspace threads but then you give up a lot of the advantages of programming with threads, and a userspace threads package needs to be ported to any new platform it runs on, which gets back to the whole portability problem. Remember, a lot of the programs you run on Unix were originally written back in the 80's or even earlier.
Asides from that, there are some good reasons for not being wedded to the "Everything should thread" model. Foremost, multiple fork()ed processes insulates you quite a bit. If a thread in a process starts overwriting random memory, that affects ALL threads running. A well written server running as multiple processes won't be affected nearly as much by misbehaving siblings. Signal handling and a variety of other things become more complicated as well in a threaded application.
Of course, threads are really neat anyhow and make a lot of sense for lots of applications (and in fact a large portion of my job involves working with threads). But too often people make the assumption that threads == "cool, fast, well-written code" and fork == "old, crusty code" when both programming models have their place.
Unfortunately their PGP support has been fucked up for over a year and their "support" people don't seem to be able to come up with an explanation or advice besides "switch to another authentication method."
Slashdot Mirror
IIRC, Coda was originally under a BSD-style license which was changed to GPL 6-12 months after they started work.
Everyone who knows Martin knows that he's a schizophrenic crack-addict. No right-minded person would desire a return to EZMAIL.
Hrmmm? And the Republicans aren't doing this? It's hard to listen to a George W. speech (or Buchanan for that matter) without them harping about "judges legislating from the bench." (ie, making decisions that they disagree with) The Supreme Court seems equally exploited by both sides.
Hrmmm. I'm a big Banks fan and due to that just read Ken McLeod's "The Star Fraction". I was extremely disappointed. Perhaps his other books are better? TSF seemed tedious, a lot of confusing fillers crammed together with unbelievable political philosophies/situations. Would you say his other stuff is better or more of the same? (possibly I just don't like his style)
A lot of his non-fiction isn't quite as grim however. I read Song of Stone and hated it, yet at the same time, I loved "The Bridge," "The Crow Road" and "Walking on Glass" (short but extremely clever). Like any author he has his ups and downs ("Whit" was particularly forgettable). But, one of his strengths is that everything isn't extremely sugar-coated. I think his writing benefits from the fact that he isn't afraid to throw some curveballs at the reader, even if he sometimes goes too far.
While I agree that LTW isn't one of Banks' strongest books, I definitely enjoyed it (especially after Inversions which was, IMO, extremely disappointing) and if you're a Banks fan wouldn't hesitate to recommend it.
In case anyone's unaware, there's an alt.fan.iain-banks usenet group...
I'm another American who ordered from the UK, why can't we get Banks here in a reasonable time?
Wine's running Diablo II perfectly as well, without any Windows DLLs for me whatsoever. I tend to think that looking at the history of Wine it would be hard for Microsoft to be able to claim any sort of collusion. It's really a tribute to the Wine team that they've been plugging at it for 5 years and it's now bearing some real fruit.
Interesting link, thanks.
If I remember correctly, it's been speculated by many people that the Windows TCP/IP stacks are BSD-derived (perhaps because the bugs they've suffered from seem similar?). However, Microsoft has always denied that claim and said that their stack is a ground-up implementation of their own.
Is there a reason you feel a need to put your posts in a block? Presumably you have some reason asides from the fact that Courier is harder on the eyes. Or is it just supposed to be /-r4d 31337?
Offhand it sounds almost like the SCSI bus is being reset. Have you checked your kernel messages? Obviously, check the termination and everything as well, but you've probably done that already. Could just be flaky drivers...
I think you're not reading in threaded mode or something...I was responding to a post pointing to a review of Accelerated X, also made by Xi Graphics...
I think "great" might be overrating it a bit. The author bought a piece of barely supported (by XFree86) hardware and then bought AX. If you want to experience a similar effect, try this:
1) Buy ATI VGAWonder(Circa 1989 or so).
2) Be amazed at how slow XFree runs
3) Buy a Matrox G400.
4) Be amazed at how fast XFree runs
5) Write an article lauding XFree
Short version: Buying poorly supported hardware will color your impressions of software. Most tests show XFree to be pretty equivelent to AX on modern graphics cards...
For the record, the Pi soundtrack was done by Clint Mansell, former member of Pop Will Eat Itself.
That's silly. You simply don't want an MUA setuid root. PERIOD. How many security notices have you seen where a program doesn't give up privs properly? More than I can count for sure. The lesson is that unless you have a really really good reason for it, an app should not be setuid anything. Not trusting swap space on a machine isnt' a good reason - as I noted before, if you don't trust the machine you're typing something into, there are already tons of other ways to get your password.
Now I've got a lot more trust about the robustness of mutt programming than, for instance, pine (*gag*), but I still wouldn't want it setuid root.
As others have pointed out, your objections to mutt are all basically invalid. A couple of things I don't think others have touched on:
/proc and readability - if someone can read /proc for your process they've either hacked your account or they have root. In any case, if they've done either of those there's nothing stopping them from using any of a dozen other ways to get your password (trojanned gpg/pgp binary perhaps?). Bottom line: If you ever type your password in, you're implicitly trusting that machine.
* "protected memory"? You mean you want to mlock() the page with your password on it? That would require mutt to be suid root since only root can wire pages in memory. Hardly seems like a good idea.
*
www.cdindex.org is trying to come up with a flexible alternative, but I don't think they have anything usable yet.
CDDB is ok for what it wants to do - given a cd in a drive, id it, but it's way too limitted as a generic media database. Hopefully a better effort will succeed.
WinNT64 isn't "nowhere in sight." It runs, albeit slowly and really flaky. Hopefully Linux runs better than it (no experience there) but with Itanium getting closer to shipping, the landscape is looking pretty bare for operating systems.
Hrmmm, people's memories are short. When Al started up the "Opensource website" crap, I seem to remember that he was actually running NT or something. Only after people started crying hypocrisy did he switch to Linux. (ie, this was a political move, not anything coming from some deep idealogical standpoint)
The point is that if every ISP filtered outgoing packets to make sure that they came from legitimate IP addresses, while it may not stop DOSes, it would at least make it a LOT easier to shut down the offending sites since they couldn't lie about where they were coming from. Currently when you get DOSes, it requires a hellish amount of effort from the backbone providers if you want to try to figure out where the (spoofed) packets are coming from.
This is a convenient ivory-tower way of looking at coding, however the fact is that any large complex problem (ie the ones you'd like to use threading or multiple processes for) have bugs. Period. Being able to recover better from bugs is simply a good thing, especially when you're going for reliability (databases, anyone?).
And asides from that, you don't even know if the bug is yours - For instance, Apache processes die off after handling a certain number of requests to try to limit the effect of memory leaks *in vendor libraries*. It's nice working on (Linux|*BSD) where you can just fix the library in question, but if you have to work on Irix, Siemens Unix or something even more obscure, do you want to be waiting on a vendor to get you a bug fix? And of course the libc on various systems may have even more nefarious bugs than memory leaks...
In short, in an ideal world, threading is probably almost always the more attractive solution. In the real world, however, compromises sometimes need to be made, and frequently fork() is a good compromise.
(I know this isn't the meat of your comment but...)
> Unix programmers seems to dislike using threads
> in their applications. After all, they can just
> fork(); and run along instead of using the
> thread functions.
This is a somewhat naive view of threading on Unix. The biggest factor is probably that many Unix programs don't use threads because they're not portable - only relatively "modern" (as Unix systems go) systems support them. Yes, you can go with userspace threads but then you give up a lot of the advantages of programming with threads, and a userspace threads package needs to be ported to any new platform it runs on, which gets back to the whole portability problem. Remember, a lot of the programs you run on Unix were originally written back in the 80's or even earlier.
Asides from that, there are some good reasons for not being wedded to the "Everything should thread" model. Foremost, multiple fork()ed processes insulates you quite a bit. If a thread in a process starts overwriting random memory, that affects ALL threads running. A well written server running as multiple processes won't be affected nearly as much by misbehaving siblings. Signal handling and a variety of other things become more complicated as well in a threaded application.
Of course, threads are really neat anyhow and make a lot of sense for lots of applications (and in fact a large portion of my job involves working with threads). But too often people make the assumption that threads == "cool, fast, well-written code" and fork == "old, crusty code" when both programming models have their place.
I keep my home directory in CVS, which kindof counts.
Unfortunately their PGP support has been fucked up for over a year and their "support" people don't seem to be able to come up with an explanation or advice besides "switch to another authentication method."
This was the #1 reason I just ditched NSI.