You forget that Outlook+Exchange is more than an email client. Yes, we could mandate Eudora (or whatever) as an email client. What then do we mandate for a meeting scheduler and a remote task assigner and all the other crap that Outlook+Exchange does?
And then who are you going to get to train people in all these new programs?
You don't simply up and abandon your entire email structure on a whim. First you threaten the manufacturer to improve or else, and that's what the AF has done.
I work on an AF base, and in my building alone we have about a half-dozen Exchange servers. (One alone can't handle the load.) What do you recommend as the "quick solution" here? What suite of programs are we going to use on all the desktops now that Exchange is gone? Remember that it doesn't just do email; it does tasks and meetings and all that crap.
What "quick solution" do you recommend for thousands of people at a time?
First, the changes that Apple made to their own version of GCC were not well thought out. Those patches can't simply be applied to the real GCC.
Second, I don't know what "commercial GCC release" you're talking about. The AltiVec patches have been going into the publiv version of GCC for weeks now. Check their mailing list archives for all the gory details.
(Not the best reference site, but the best one is currently down.)
Been there, done that
on
GCC 3.0.4 is Out
·
· Score: 5, Insightful
It is even slower at compiling C++ than the old one.
That's because C++ got bigger since the old one.
When will they implement precompiled headers.
A precompiled headers branch was created some time ago. Feel free to try using it. It's been implemented by two different commercial groups already; they're just merging in one of those solutions.
Perhaps you think implementing precompiled headers is easy? I invite you to try.
Oh why, why. why havnt they done it already!
If are are dissatisfied with the compiler, and unwilling to contribute your own time to make it better, you should definitely demand a refund of the money you paid for it.
We tried removing it once...
on
GCC 3.0.4 is Out
·
· Score: 3, Informative
...but RMS won't let us.
There are days when I dream about another GCC fork.
Soldier, starring Kurt Russell, is one of those action movies that's not supposed to be funny, but turns out to be hilarious. (This is the one where "I'm going to kill them all!" is Kurt's longest line in the whole movie.)
One of the directors is on record -- on the DVD, I believe -- as saying the movie takes place in the same universe as Bladerunner. There are some references, but you have to be quick to catch 'em.
As for compile times, yes, there were problems -- they were known problems at ship time, largely due to the inlining heuristics. Those were fixed in a point release, mostly, and the major changes to fix the reamining issues went in 3.1.
The KDE folks were making bad assumptions -- there's a long thread in the main GCC mailing list archives. Basically KDE wanted to violate the One Definition Rule and have the compiler/linker/loader read their minds. Can't have your cake and eat it too, etc. There were also MI bugs, all of which I/think/ have been fixed, but I haven't checked lately.
I don't blame the distros for not shipping 3.0 as the default. (I would've made the same decision in their place.) I/do/ blame people for saying that "GCC's default library implementation sucks" when they clearly haven't investigated the problem.
GCC 3.0 has been out for almost a year. All the problems you mention have long, long since been solved. Among other things, the library was completely rewritten (the old library predates the standard).
Whoops. G++'s STL doesn't support the vector.at() method, which is necessary for bounds-checking.
You're using version 2. Version 2's library was written before they finished tweaking the C++ Standard. So you blame the GCC people for not being able to tell the future?
I believe it's the third Dune book where, after spending the entire night talking and debating with Duncan Idaho, Stilgar looks out at the rising sun and says, "To stay awake all night is to add a day to your life."
(Okay, Stil, how come it's 4 in the morning for me, I can't sleep, and I feel like a fukkin corpse?:-) Blah, I hate insomnia.)
...talked about this. The name of the essay was IIRC "The Inconstant Moon" and I first read it in The Sun Shines Bright, a collection of his science essays.
All I vaguely remember from the essay is that, once everything slows down enough, the moon should start spiralling inward. Friction with the atmosphere will destroy it, giving us a nice little ring system like Saturn's. However, that's supposed to take 7 billion years, while Sol will go red-giant in 5 billion years, so it's one of those "this would be really cool, but we'll all be dead by other means before we get to see it" events.
I hope I'm remembering the essay correctly. If you disagree, okay -- go read the essay and tell me what I forgot.
When I say, "the solution is simply...," I'm not talking about the solution to spam. I'm talking about the solution to poorly-managed blacklists. And that solution (vocally promoting the good ones) is hardly technological.
The solution to spam is also quite simple: two bullets to the head of the marketing agent who did the spamming. That's not a technological solution either.:-)
Yep, that's the root of the problem: there are a number of for-free blacklists out there which are professionally managed. Those are the ones that should be used.
And as long as we publicly point out the blacklists that are being poorly run, people will stop using them, and switch to the good ones (like RBL, RSS, DUL, ORDB). The solution is not to ban or otherwise stop using blacklists, the solution is simply to (vocally) promote the ones which stay on top of the problem.
He helped Linux, says Neal Stephenson
on
.NETly News
·
· Score: 1
Does anyone truly believe that Gates has made a positive contribution to "this earth", other than his (admittedly laudable) charitable works?
(go go gadget karma whore...)
You owe it to yourself to buy a copy of Stephenson's In The Beginning Was The Command Line. (Yes, this is the Cryptonomicon guy.) One of the points he puts forward is that Linux could never be as popular and as widespread today if Microsoft had not been successful.
The reasoning, briefly, runs thus: if MS had not been so popular, x86 hardware would not have become so cheap and easily available. If x86 hardware had not been easily available, Torvalds would not have had such a platform available for his experiments.
I'm compressing Stephenson's arguments beyond what the average/.er will accept, which is why you should read the book. His point here is that the Linux community owes MS thanks for making x86 hardware cheap, fast, and widely available.
Something that wasn't (I think) clear from the/. writeup: the question is not "what if book five were available as an e-book," but rather, "what if book five were available only as an e-book."
I think you'd find a vast amount of interest in hacking e-books, putting the documents online (or at least on a local hard drive), and then printing them out for distribution among one's fellow fifth-graders. Not everybody's mommy and daddy can afford to buy an electronic bookreader.
I thinking keeping old projects around is a good idea, if the projects have actually done something. Too many times I've looked into a project only to find that absolutely nothing has happened other than the project's name being approved and added to SF. Even the homepage hadn't been touched.
Those projects are the ones that need to be removed. An empty project does nothing but take up space.
3. They're no longer obliged to make the contents of a deleted account available to its owner. (There was previously a "reasonable effort" clause to that effect.)
The users should have local backups... this is more then resonable.
Yes, the users should have local backups. But of what?
Another poster commented that this wasn't a big deal because "I update my local CVS checkout daily." So what? You have the latest current version, okay, true, that's good. But without the CVS repository itself, you've lost all the history (diffs over time, commit log entries, etc).
For the projects I care about, I use rsync and get a local copy of the CVS repository itself; that way I have it all. (It's also handy to be able to check out a copy from that repository; CVS ops go really quickly. *grin*)
I'd like SF.net to make a "reasonable effort" to mail me the CVS repo. Other than that I don't particularly care.
I forgot to mention that the GCC manuals, including the Internals manual, are nightly regenerated into HTML and posted online:
http://gcc.gnu.org/onlinedocs/. Have fun!
GCC Internals: How it works/How to modify it. - Have you ever looked at this heaping mess of code? I would love to play around with it, but the learning curve is too high to just jump in.
(That's what happens when you let Richard "We don't need to follow anybody's standards but our own" Stallman design a compiler.) GCC is written in LISP. It only looks like C. Just keep LISP in mind and it all makes sense.
Anyhow, you owe Joseph Myers some thanks. He's one of the C front-end maintainers, but he's also been ruthlessly documenting the entire compiler, and demanding that anybody who checks in a user-visible change update the documentation as well. (Others have certainly helped, but Joseph has been the driving force.)
So, there's now a GCC Internals manual as part of the documentation.
Linux/Unix Lowlevel Programming
I saw this in a bookstore the other day, but I don't recall the title. It was Linux-specific, however. For ELF stuff, there's a decent specification as part of the ELF File Format. For ld/ar/as/etc programming, you're screwed. They're all part of the "binutils" package, and those developers for the most part don't believe in keeping documentation up to date.
Using GNU Development Tools
New Riders has been publishing a lot of these books. The "Goat Book" for example is about autoconf, automake, and libtool.
As nonya points out, I was thinking of Exceptional C++. Oops. Essential C++ is a different book, by a different author. Although both authors happen to be brilliant.
Slashdot Mirror
You forget that Outlook+Exchange is more than an email client. Yes, we could mandate Eudora (or whatever) as an email client. What then do we mandate for a meeting scheduler and a remote task assigner and all the other crap that Outlook+Exchange does?
And then who are you going to get to train people in all these new programs?
You don't simply up and abandon your entire email structure on a whim. First you threaten the manufacturer to improve or else, and that's what the AF has done.
I work on an AF base, and in my building alone we have about a half-dozen Exchange servers. (One alone can't handle the load.) What do you recommend as the "quick solution" here? What suite of programs are we going to use on all the desktops now that Exchange is gone? Remember that it doesn't just do email; it does tasks and meetings and all that crap.
What "quick solution" do you recommend for thousands of people at a time?
Uh, no. Not by a long shot.
First, the changes that Apple made to their own version of GCC were not well thought out. Those patches can't simply be applied to the real GCC.
Second, I don't know what "commercial GCC release" you're talking about. The AltiVec patches have been going into the publiv version of GCC for weeks now. Check their mailing list archives for all the gory details.
You didn't think all those sexy nuke explosion simulations were just to stress-test some graphics cards, did you?
It's not a troll that challenges them. "It's the old man from Scene 24!"
(Not the best reference site, but the best one is currently down.)
That's because C++ got bigger since the old one.
A precompiled headers branch was created some time ago. Feel free to try using it. It's been implemented by two different commercial groups already; they're just merging in one of those solutions.
Perhaps you think implementing precompiled headers is easy? I invite you to try.
If are are dissatisfied with the compiler, and unwilling to contribute your own time to make it better, you should definitely demand a refund of the money you paid for it.
...but RMS won't let us.
There are days when I dream about another GCC fork.
Soldier, starring Kurt Russell, is one of those action movies that's not supposed to be funny, but turns out to be hilarious. (This is the one where "I'm going to kill them all!" is Kurt's longest line in the whole movie.)
One of the directors is on record -- on the DVD, I believe -- as saying the movie takes place in the same universe as Bladerunner. There are some references, but you have to be quick to catch 'em.
As for compile times, yes, there were problems -- they were known problems at ship time, largely due to the inlining heuristics. Those were fixed in a point release, mostly, and the major changes to fix the reamining issues went in 3.1.
The KDE folks were making bad assumptions -- there's a long thread in the main GCC mailing list archives. Basically KDE wanted to violate the One Definition Rule and have the compiler/linker/loader read their minds. Can't have your cake and eat it too, etc. There were also MI bugs, all of which I /think/ have been fixed, but I haven't checked lately.
I don't blame the distros for not shipping 3.0 as the default. (I would've made the same decision in their place.) I /do/ blame people for saying that "GCC's default library implementation sucks" when they clearly haven't investigated the problem.
GCC 3.0 has been out for almost a year. All the problems you mention have long, long since been solved. Among other things, the library was completely rewritten (the old library predates the standard).
You're using version 2. Version 2's library was written before they finished tweaking the C++ Standard. So you blame the GCC people for not being able to tell the future?
I believe it's the third Dune book where, after spending the entire night talking and debating with Duncan Idaho, Stilgar looks out at the rising sun and says, "To stay awake all night is to add a day to your life."
(Okay, Stil, how come it's 4 in the morning for me, I can't sleep, and I feel like a fukkin corpse? :-) Blah, I hate insomnia.)
...talked about this. The name of the essay was IIRC "The Inconstant Moon" and I first read it in The Sun Shines Bright, a collection of his science essays.
All I vaguely remember from the essay is that, once everything slows down enough, the moon should start spiralling inward. Friction with the atmosphere will destroy it, giving us a nice little ring system like Saturn's. However, that's supposed to take 7 billion years, while Sol will go red-giant in 5 billion years, so it's one of those "this would be really cool, but we'll all be dead by other means before we get to see it" events.
I hope I'm remembering the essay correctly. If you disagree, okay -- go read the essay and tell me what I forgot.
When I say, "the solution is simply...," I'm not talking about the solution to spam. I'm talking about the solution to poorly-managed blacklists. And that solution (vocally promoting the good ones) is hardly technological.
The solution to spam is also quite simple: two bullets to the head of the marketing agent who did the spamming. That's not a technological solution either. :-)
Yep, that's the root of the problem: there are a number of for-free blacklists out there which are professionally managed. Those are the ones that should be used.
And as long as we publicly point out the blacklists that are being poorly run, people will stop using them, and switch to the good ones (like RBL, RSS, DUL, ORDB). The solution is not to ban or otherwise stop using blacklists, the solution is simply to (vocally) promote the ones which stay on top of the problem.
(go go gadget karma whore...)
You owe it to yourself to buy a copy of Stephenson's In The Beginning Was The Command Line. (Yes, this is the Cryptonomicon guy.) One of the points he puts forward is that Linux could never be as popular and as widespread today if Microsoft had not been successful.
The reasoning, briefly, runs thus: if MS had not been so popular, x86 hardware would not have become so cheap and easily available. If x86 hardware had not been easily available, Torvalds would not have had such a platform available for his experiments.
I'm compressing Stephenson's arguments beyond what the average /.er will accept, which is why you should read the book. His point here is that the Linux community owes MS thanks for making x86 hardware cheap, fast, and widely available.
Heh. :-) I guess I should have written "take up mindshare" instead. But yes, you're right, they do get in the way of searching.
Something that wasn't (I think) clear from the
I think you'd find a vast amount of interest in hacking e-books, putting the documents online (or at least on a local hard drive), and then printing them out for distribution among one's fellow fifth-graders. Not everybody's mommy and daddy can afford to buy an electronic bookreader.
I thinking keeping old projects around is a good idea, if the projects have actually done something. Too many times I've looked into a project only to find that absolutely nothing has happened other than the project's name being approved and added to SF. Even the homepage hadn't been touched.
Those projects are the ones that need to be removed. An empty project does nothing but take up space.
Yes, the users should have local backups. But of what?
Another poster commented that this wasn't a big deal because "I update my local CVS checkout daily." So what? You have the latest current version, okay, true, that's good. But without the CVS repository itself, you've lost all the history (diffs over time, commit log entries, etc).
For the projects I care about, I use rsync and get a local copy of the CVS repository itself; that way I have it all. (It's also handy to be able to check out a copy from that repository; CVS ops go really quickly. *grin*)
I'd like SF.net to make a "reasonable effort" to mail me the CVS repo. Other than that I don't particularly care.
The "color matters" bit cannot be stressed enough. I learned this the hard way.
I forgot to mention that the GCC manuals, including the Internals manual, are nightly regenerated into HTML and posted online: http://gcc.gnu.org/onlinedocs/. Have fun!
I'm sure I'm forgetting some.
(That's what happens when you let Richard "We don't need to follow anybody's standards but our own" Stallman design a compiler.) GCC is written in LISP. It only looks like C. Just keep LISP in mind and it all makes sense.
Anyhow, you owe Joseph Myers some thanks. He's one of the C front-end maintainers, but he's also been ruthlessly documenting the entire compiler, and demanding that anybody who checks in a user-visible change update the documentation as well. (Others have certainly helped, but Joseph has been the driving force.)
So, there's now a GCC Internals manual as part of the documentation.
I saw this in a bookstore the other day, but I don't recall the title. It was Linux-specific, however. For ELF stuff, there's a decent specification as part of the ELF File Format. For ld/ar/as/etc programming, you're screwed. They're all part of the "binutils" package, and those developers for the most part don't believe in keeping documentation up to date.
New Riders has been publishing a lot of these books. The "Goat Book" for example is about autoconf, automake, and libtool.
As nonya points out, I was thinking of Exceptional C++. Oops. Essential C++ is a different book, by a different author. Although both authors happen to be brilliant.
You're right, I'm a moron. This is one of the in-depth books that I haven't purchased yet... sigh.
I just posted a comment on this in the "Books I want" thread. The comment is titled "Here ya' go" and it addresses your point