Honestly, given that this was an interview with someone tied to Comedy Central (and all that that entails), I thought the interview would be an in-character scripted affair. It was nice to hear from someone in entertainment who wasn't exactly trying to entertain.
"Their argument since the beginning has essentially not been about methodological issues at all, but about 'source data' issues [...] Only if you remove significant portions of the data do you get a different (and worse) answer."
You're over-trivializing a DRAMATICALLY IMPORTANT POINT. The original study is focused on North American data almost exclusively for certain time periods. That data (from a single species of tree) skews the results in such a way as to make the current trend seem unique and drastic. On the other hand, if you treat that data source in such a way as to balance it with the other data that is available, you see a VERY DIFFERENT TREND!
The response has been to claim that weighting the data in this way reduces the number of data points unacceptably (I would agree, but that doesn't make MBH98 right).
That's the whole point here, and the other side continues to say, "you're throwing away data" when any competent researcher would have thrown it out in the first place (note: there's an exception. if you produced a report that was specific to N. America, MBH98 would be your model, and it seems to be a fine model for that... N. America is seeing record warming as compared with the last few centuries, and that's all you can extract from MBH98).
Also keep some perspective in mind here. We're in a period where temperatures could rise MORE than ANYONE is predicting and not make a dent in the graph over the last 10million years. If you graph out the last 10 million years, you see that temperatures over the last 10,000 years have been part of a huge, cyclical spike in temperatures. We're at what is likely the peak of a drastic temperature swing, and it WILL plumet again into a new ice age (unless we decide to and are capable of coming up with a way to prevent it). I'm not drawing any conclusions from that, just pointing out that there are natural forces at work here, capable of making temperature changes that we a) cannot yet conclusively explain and b) the likes of which no human has ever experienced.
It's important to keep a sense of perspective and to remember that we have very impressive climate models... all of which might be wrong.
"Shakespeare [...] was popular and funny and accessible [...] I [would] compare his works to [...] Andrew Lloyd Weber."
Do you have any concept of how hard achieving that degree of popular, funny and accessible are?!
I'll make this simple for you: ALW could not begin to write a piece of work with the layers of complexity of a King Lear or a Hamlet. It's that simple.
Hamlet, just as an example, is cliche today because we've examined it endlessly, and had it shoved down out throats over and over, but the fact remains: you can pull that play apart into 1000 pieces and each one holds up under some pretty damned strict scrutiny.
Its pacing is outstanding given the ground it covers (so much so that "Rosencrantz and Guildenstern Are Dead" was able to tell an entirely different story without having to diverge from the core timing... try this with most plays and you have to re-construct the timing entirely); the soliloquies and monologues ring so deep with us that every generation since has found new and profound ways to re-express them (many focus on Hamlet's famous "To be or not to be..." soliloquy, but I prefer Polonious's "to thine own self be true," monologue which manages to touch on themes that are just as profound, and yet maintain its comedic timing and raw humor value); and the characters are so engrosing that they have been lifted and re-used by thousands of playwrights, authors, screenwriters, etc.
I think there were better playwrights throughout history, but ALW is not one of them.
I want my system to be robust against buggy programs with:
You can do that. And, I can do what I want.
That's all good.
The discussion in this thread did not have any bearing on the fact that both Linux and BSD give you the above choice, but on the fact that BSD (as reported, hey this is Slashdot, who knows) has a bug where reading pages from/dev/zero consumes real RAM, not COWed copies of the cannonical zero-filled page. That would shock me, as BSD tends to be reasonable in terms of VM management. However, it would not shock me at all to find that BSD had had a bug that was since fixed in this regard, or for which a fix is soon pending. After all, everyone can make a mistake.
If that's still not getting through, then I don't think another round of replies in this thread is going to help.
Relax, you can get the original from you local DVD rental.
No, that's just it. You CAN'T get the original unless you manage to find it on eBay or you have a video rental place that's renting out what is rapidly becoming a highly valuable relic. The original home-video release of Star Wars is gone forever... has been ever since the "Special Edition".
Now, I understand that Hollywood changes things all the time. There's no "one true version" of anything because you always re-edit for the format. However, when you release a version that adds in tons of stuff that very, very few people like (and most of your core fans HATE), and you then remove the originals... that's a problem.
That distorts what has become a piece of our cultural heritage.
The discussion in THIS thread was about the difference between Linux and BSD in terms of reading from/dev/zero where it was observed by the original poster that the command used ground a BSD box to a stand-still, but you could "still log in" to kill the process. I was shocked by this because you should NOT be able to do this. Linux (at least the box I'm sitting at, which has no problem allowing you to allocate as much RAM as you like, because I WANT it that way), does the right thing in this case. It COWs up a chain of copies of the cannonical zero-filled page, so that by the time the process reaches the per-process VM limit (3GB under recent kernels, though Red Hat was supporting a patch for 4GB until recently), it should be using 3MB of RAM for all of those zero-filled pages (just enough to store the COW info).
Now, if you were to WRITE to those pages, that would be another matter.
So the point is that the BSD problem noted originaly in the thread is probably a bug (possibly even already fixed) in the handling of COW for the/dev/zero It doesn't mean BSD sucks because we all know that you can find edge cases under any OS. Unless you do a holistic survey of all of the bugs and features of a system, you cannot reasonably compare it to any other. And THAT is why this whole Slashdot article made no sense: they were comparing the worth of one system to another on the basis of ONE data point.
On that basis, I could prove that a Timex Sinclair circa 1985 is the worlds finest computing platform. That doesn't make it so.
If anyone at Lucasfilm reads this, please, please convey my hopes that we can put Star Wars (the original three movies) away and, if we MUST perpetuate the franchise, do so by releasing new films by up-and-coming directors and writers who have interesting stories to tell.
I know that's a tad radical for Hollywood, but then Lucasfilm WAS a tad radical once....
On Fedora Core 2, I have unlimited memory available for processes, and yet my machine doesn't fall over at all. As well it should not. Why on earth would reading from/dev/zero give you anything but a bunch of COW versions of the same page (1MB overhead per 1GB of allocated space, under Linux).
Sure, your process will hit the system limit, and fall over, but it shouldn't hurt anything else. What's BSD doing wrong? This sounds like a bug in BSD, as there should be a cannonical zero-filled page that the system uses for all reads from/dev/zero
Of course, it could peg your CPU, and that might make things slow... but still, it should not render the system unusable (doesn't on mine).
Steroids are a terrible thing
on
Juiced
·
· Score: 1
Here's why steroids suck:
Once you walk down the path of comparing these people, not on the basis of what they can do with their bodies, but how augmented their bodies are, we begin to dehumanize the concept of sports, and as long as you're paying $1m for "the best", you'll get a constant lineup of folks who will subject themselves to ANYTHING in order to be the best.
I don't want to watch several hours of the finest machines money can buy slugging balls out of the park. I want to watch human beings doing what they're good at. In order to achieve that, baseball should start testing EVERYONE before every game, and remove ANYONE who fails two tests in a row for the rest of the season. They don't do this. There's a long and complicated process of testing and re-testing where the first n failures aren't even reported! The system ENCOURAGES this kind of thing.
I also think that serious injuries should get you removed for the rest of the season. It sucks, but I'd rather watch a game where everyone's holding back just a bit, because they know that getting seriously hurt means they won't be able to play. I want these guys to stay healthy, not play one great season and never see them again (other sports suffer from this more than Baseball, but still).
I live in Boston. I want to feel good about the Red Sox winning the series, but I'm constantly reminded that they didn't do it until steroid use became the norm (hey, this is Boston: the biotech capital of the eastern US).
Honestly, when will Slashdot stop posting trolls as stories. This is a clear case of "BSD is better than Linux because feature X has a DEFAULT that BSD people think is wrong". There's no security implication in the sense that most people would think of it (no remote root exploit, no remote exploit, no remote priv escalation, no remote DoS, no local root exploit, and no local priv escalation... just a local DoS... if that's what you were looking for, I can show you some OpenGL code you can throw at the display that will render your bus unusable on any display-acceleration capable graphics card regardless of OS).
Please, just stop posting this cruft as "news for nerds,"; it's not news and any self-respecting nerd knows bad advocacy when he/she sees it. I like BSD. I was a major BSD guy back in the day, from BSD 4.2 to Ultrix up to SunOS 4.x. BSD is great.
Linux is also quite nice.
They both have a ton of great features and a ton of other annoying features / arguably bugs. Linux has more features and more bugs because more people contribute to it, but that's both a blessing and a curse for the BSDs.
No, they're not. Xorg, egcs, the Linux kernel, and dozens of other projects that have had healthy forks demonstrate this.
"The mantra of "choice" isn't applicable to every situation."
Yeah, it is.
"Standardizing on a platform is difficult enough in the Linux world. Forking things whenever one of the devs feels wronged (usually how these things get started) just increases the confusion and non-interoperability between multiple platforms."
Such actions do not touch end-users and are ignorable to them, and by end-user, I mean anyone installing and using a distribution.
Unless, as an end-user you're going out on the Net searching for CVS repositories to download from, you don't care. If you are doing that... then, well, you're dipping your hand into a bag and getting whatever comes out. Might be something nice, but I don't recommend it.
When I install Fedora or SuSE or Mandrake or what-have-you, I don't care about what project management looks like, I care that when I click a button it does what I want.
Distribution maintainers take on the JOB of managing their software mix and the interaction between them and a given project. It's work, and it's HARD WORK, but the good news is that it's work that pays off richly as demonstrated by the many quality products that are, at their heart, a Linux distribution from RHEL to TiVo, it's all Linux Inside.
"The decreasing returns and impending limits of single threaded processing has been upcoming for a long time now."
First time I heard that was 1987. Pray, what's new?
My feeling is this: most of today's bottlenecks are related to bus and memory I/O. The fraction of bottlenecks that are CPU-related can generally be addressed more reasonably via true SMP, rather than multi-core pseudo-threading.
For those trivial number of cases where this technology is a win... well, there you go, but the problem is that that small section of the consumer base is dictacting that MY CPUs will be more expensive. This is unthrilling to me....
"Most of these features you wish to compare are not part of a Linux operating system. Most are applications that are installed on top of a Linux operating system.
So, among the Linux distributions, all of these features are roughly eqivalent, providing that you are using the same software to meet the need for the particular feature."
VERY untrue! You will find that, for example, LDAP support (and the ability to talk to AD if needed) varries widely from distribution to distribution, even though they all have roughly the same tools for talking to LDAP. The key questions are: how easy is it to set up; how well are applications, tools and libraries configured to integrate any given feature you need; are conflicting services installed by default (and/or REQUIRED);etc.
You might not think this way because you worry about <1000 end-user machines, but let me tell you, when you need to install 5,000 end-user desktops, you're not thinking, "eh, it's ok... I'll just install anything and configure to taste," you're looking for something that gets you as close to the finish-line as possible so that you can worry about the truly hard problems. Sure, you're just going to dupe hard-drives, but that doesn't get you the perfect economies of scale you might have expected. You're going to worry about things like, "oh look, this LDAP server falls over when 1000 clients ask it a question at once," and other scaling issues. You don't want to have to start at ground-zero, "why doesn't LDAP work with applications X and Y and works half the time with Z."
The above is just an example, but I think it illustrates the point.
Wow. I don't know what to say. I'm posting this from FC3, and the only crashes I've seen have to do with the CD writer and the burner program that Nautilus launches. I'll see if I can replicate any of your (as yet unsolved) problems. Glad to hear the login one is fixed, though.
I'd be curious to see what you're doing that could cause that (I'm not saying it's your fault; software should not crash), but I'd love to know how you triggered it. That's the kind of thing that I'd enjoy debugging.
You're massively confused about the definition of a query and a user as I used them in my post. I can't even really respond to what you said directly without clearing up those points first.
Ok, so you're saying that you can already can queries... yes, of course you can, what on earth did you think was being suggested by canning a query, and how does canning such a query involve re-inventing anything at all?! The suggestion was that, instead of going off and creating some OTHER SITE to track feature requests, instead a canned query be used in bugzilla. I think perhaps you got confused over what the list members had suggested, since you seem to be echoing their comments.
Second, you call the users "stupid". First off, remember that the "users" in this case are the developers who wrote Gnome. They're not stupid. Ranking a feature request as urgen becuase it's one of the highest profile items in the database is also not stupid. Using a keyword (standard bugzilla functionality for years) is to then collect all such requests is also not stupid.
I'm not sure if you just got confused over who we were talking about, or you just assumed that the Gnome developers were all just a bunch of monkeys banging on a keyboard until the result compiled, but I can assure you that both are incorrect.
Why would you ever can any query? Simple, to save keystrokes, and increase the likelyhood that any given dev will actually USE the query. What you suggest might also not be sufficient. For example, there might be so many requests that a menu editor be put back in that it's ranked as "urgent", and yet it's still an enhancement request. A keyword would be a better way to track such things.
I've never seen a panel crash. Nautilus crashes under me under FC3 (home desktop) from time to time, but it seems that this is related to previews (e.g. some underlying program that's reading a file soils itself and Nautilus wigs out). Turning off previews helped this quite a lot.
As for NFS-mounted homedirs... I don't have a problem. Is your NFS server correctly time-synced, running statd, etc.? At work I used (until very recently) and NFS-mounted homedir for Gnome. Works like a charm.
I do get some lockups, but those were a result of the crappy NVidia driver support, not Gnome (and that's NVidia's fault for not publishing specs... I had to give up and use their binary driver, since I don't spec what cards to buy).
The Eclipse project actively encourages its users and clients to log bugs and change requests as well as vote and comment on them through their Bugzilla.
IIRC, this concept was encouraged by ERS [sic] in Cathedral... It would be nice to see other mainstream OSS projects such as GNOME actively embrace this model of community involvement.
Interesting thread. The basic concept is this: "we should have a page specially designed for tracking feature requests".
The answers varied, but seemed to center on "no, we have bugzilla" and "if you want to do that with bugzilla, create a special query page for devs to review feature requests."
"Real, for-profit development succeeds mostly by doing something the customer wants."
And so Gnome, being the combined effort of real, for-profit companies like Novell, Sun, IBM, Red Hat and many others is... I'm sorry, what was your point there again?
"By failing to listen to and develop to their requests"
No, you see that's just the problem. Tools and systems like Gnome (which is a far-reaching set of specs, libraries and applications, which few of its users appreciate the value of, nor take advantage of beyond creating cute menus), are desgined for the needs of a huge and diverse community of users and user needs. Gnome satisfies the needs of its users....
AND THAT IS WHAT THE SLASHDOT CROWD HATES. We, here at Slashdot, are a microcosm of developers and geeks of various flavors. We have specialized needs, and we hate seeing out tools "watered down" by the needs of the average user.
That's fair, and I'm not saying that we should not push for our needs too, but face it: Gnome and KDE have both reached a level of popularity where your average Slashdotter is no longer the primary target-user. Cope.
Slashdot Mirror
Correction, obviously I meanet Cartoon Network. Sorry about that TWX, no one was trying to compare you to VIAb ;-)
Honestly, given that this was an interview with someone tied to Comedy Central (and all that that entails), I thought the interview would be an in-character scripted affair. It was nice to hear from someone in entertainment who wasn't exactly trying to entertain.
;-)
One point: use the deep voice, it works.
"Their argument since the beginning has essentially not been about methodological issues at all, but about 'source data' issues [...] Only if you remove significant portions of the data do you get a different (and worse) answer."
You're over-trivializing a DRAMATICALLY IMPORTANT POINT. The original study is focused on North American data almost exclusively for certain time periods. That data (from a single species of tree) skews the results in such a way as to make the current trend seem unique and drastic. On the other hand, if you treat that data source in such a way as to balance it with the other data that is available, you see a VERY DIFFERENT TREND!
The response has been to claim that weighting the data in this way reduces the number of data points unacceptably (I would agree, but that doesn't make MBH98 right).
That's the whole point here, and the other side continues to say, "you're throwing away data" when any competent researcher would have thrown it out in the first place (note: there's an exception. if you produced a report that was specific to N. America, MBH98 would be your model, and it seems to be a fine model for that... N. America is seeing record warming as compared with the last few centuries, and that's all you can extract from MBH98).
Also keep some perspective in mind here. We're in a period where temperatures could rise MORE than ANYONE is predicting and not make a dent in the graph over the last 10million years. If you graph out the last 10 million years, you see that temperatures over the last 10,000 years have been part of a huge, cyclical spike in temperatures. We're at what is likely the peak of a drastic temperature swing, and it WILL plumet again into a new ice age (unless we decide to and are capable of coming up with a way to prevent it). I'm not drawing any conclusions from that, just pointing out that there are natural forces at work here, capable of making temperature changes that we a) cannot yet conclusively explain and b) the likes of which no human has ever experienced.
It's important to keep a sense of perspective and to remember that we have very impressive climate models... all of which might be wrong.
"Shakespeare [...] was popular and funny and accessible [...] I [would] compare his works to [...] Andrew Lloyd Weber."
Do you have any concept of how hard achieving that degree of popular, funny and accessible are?!
I'll make this simple for you: ALW could not begin to write a piece of work with the layers of complexity of a King Lear or a Hamlet. It's that simple.
Hamlet, just as an example, is cliche today because we've examined it endlessly, and had it shoved down out throats over and over, but the fact remains: you can pull that play apart into 1000 pieces and each one holds up under some pretty damned strict scrutiny.
Its pacing is outstanding given the ground it covers (so much so that "Rosencrantz and Guildenstern Are Dead" was able to tell an entirely different story without having to diverge from the core timing... try this with most plays and you have to re-construct the timing entirely); the soliloquies and monologues ring so deep with us that every generation since has found new and profound ways to re-express them (many focus on Hamlet's famous "To be or not to be..." soliloquy, but I prefer Polonious's "to thine own self be true," monologue which manages to touch on themes that are just as profound, and yet maintain its comedic timing and raw humor value); and the characters are so engrosing that they have been lifted and re-used by thousands of playwrights, authors, screenwriters, etc.
I think there were better playwrights throughout history, but ALW is not one of them.
I want my system to be robust against buggy programs with:
/dev/zero consumes real RAM, not COWed copies of the cannonical zero-filled page. That would shock me, as BSD tends to be reasonable in terms of VM management. However, it would not shock me at all to find that BSD had had a bug that was since fixed in this regard, or for which a fix is soon pending. After all, everyone can make a mistake.
You can do that. And, I can do what I want.
That's all good.
The discussion in this thread did not have any bearing on the fact that both Linux and BSD give you the above choice, but on the fact that BSD (as reported, hey this is Slashdot, who knows) has a bug where reading pages from
If that's still not getting through, then I don't think another round of replies in this thread is going to help.
Relax, you can get the original from you local DVD rental.
... that's a problem.
No, that's just it. You CAN'T get the original unless you manage to find it on eBay or you have a video rental place that's renting out what is rapidly becoming a highly valuable relic. The original home-video release of Star Wars is gone forever... has been ever since the "Special Edition".
Now, I understand that Hollywood changes things all the time. There's no "one true version" of anything because you always re-edit for the format. However, when you release a version that adds in tons of stuff that very, very few people like (and most of your core fans HATE), and you then remove the originals
That distorts what has become a piece of our cultural heritage.
Several problems with that:
1) He has a track record for REMOVING the old versions
2) He has a track record for making them WORSE
3) Something won't be in the theather because Star Wars 3D with Uber-Jar-Jar in Sparklemotion the Director's Next Cut edged it out
4) I am probably the last guy on Eath who thinks this, but I believe he could do something truly interesting instead
You missed most of the point of the thread.
/dev/zero where it was observed by the original poster that the command used ground a BSD box to a stand-still, but you could "still log in" to kill the process. I was shocked by this because you should NOT be able to do this. Linux (at least the box I'm sitting at, which has no problem allowing you to allocate as much RAM as you like, because I WANT it that way), does the right thing in this case. It COWs up a chain of copies of the cannonical zero-filled page, so that by the time the process reaches the per-process VM limit (3GB under recent kernels, though Red Hat was supporting a patch for 4GB until recently), it should be using 3MB of RAM for all of those zero-filled pages (just enough to store the COW info).
/dev/zero It doesn't mean BSD sucks because we all know that you can find edge cases under any OS. Unless you do a holistic survey of all of the bugs and features of a system, you cannot reasonably compare it to any other. And THAT is why this whole Slashdot article made no sense: they were comparing the worth of one system to another on the basis of ONE data point.
The discussion in THIS thread was about the difference between Linux and BSD in terms of reading from
Now, if you were to WRITE to those pages, that would be another matter.
So the point is that the BSD problem noted originaly in the thread is probably a bug (possibly even already fixed) in the handling of COW for the
On that basis, I could prove that a Timex Sinclair circa 1985 is the worlds finest computing platform. That doesn't make it so.
If anyone at Lucasfilm reads this, please, please convey my hopes that we can put Star Wars (the original three movies) away and, if we MUST perpetuate the franchise, do so by releasing new films by up-and-coming directors and writers who have interesting stories to tell.
I know that's a tad radical for Hollywood, but then Lucasfilm WAS a tad radical once....
Sure, your process will hit the system limit, and fall over, but it shouldn't hurt anything else. What's BSD doing wrong? This sounds like a bug in BSD, as there should be a cannonical zero-filled page that the system uses for all reads from
Of course, it could peg your CPU, and that might make things slow... but still, it should not render the system unusable (doesn't on mine).
Here's why steroids suck:
Once you walk down the path of comparing these people, not on the basis of what they can do with their bodies, but how augmented their bodies are, we begin to dehumanize the concept of sports, and as long as you're paying $1m for "the best", you'll get a constant lineup of folks who will subject themselves to ANYTHING in order to be the best.
I don't want to watch several hours of the finest machines money can buy slugging balls out of the park. I want to watch human beings doing what they're good at. In order to achieve that, baseball should start testing EVERYONE before every game, and remove ANYONE who fails two tests in a row for the rest of the season. They don't do this. There's a long and complicated process of testing and re-testing where the first n failures aren't even reported! The system ENCOURAGES this kind of thing.
I also think that serious injuries should get you removed for the rest of the season. It sucks, but I'd rather watch a game where everyone's holding back just a bit, because they know that getting seriously hurt means they won't be able to play. I want these guys to stay healthy, not play one great season and never see them again (other sports suffer from this more than Baseball, but still).
I live in Boston. I want to feel good about the Red Sox winning the series, but I'm constantly reminded that they didn't do it until steroid use became the norm (hey, this is Boston: the biotech capital of the eastern US).
Honestly, when will Slashdot stop posting trolls as stories. This is a clear case of "BSD is better than Linux because feature X has a DEFAULT that BSD people think is wrong". There's no security implication in the sense that most people would think of it (no remote root exploit, no remote exploit, no remote priv escalation, no remote DoS, no local root exploit, and no local priv escalation... just a local DoS... if that's what you were looking for, I can show you some OpenGL code you can throw at the display that will render your bus unusable on any display-acceleration capable graphics card regardless of OS).
Please, just stop posting this cruft as "news for nerds,"; it's not news and any self-respecting nerd knows bad advocacy when he/she sees it. I like BSD. I was a major BSD guy back in the day, from BSD 4.2 to Ultrix up to SunOS 4.x. BSD is great.
Linux is also quite nice.
They both have a ton of great features and a ton of other annoying features / arguably bugs. Linux has more features and more bugs because more people contribute to it, but that's both a blessing and a curse for the BSDs.
Once agian, carry on. Nothing to see here.
Fedora Core 2
Kicked off 5 at a time on my (fairly old) desktop box.... waited a few seconds, greps started dying (correcty) when they ran out of memory.
System's fine.
Posting this message seconds later.
No problems here; move along.
"Forks ARE bad things."
No, they're not. Xorg, egcs, the Linux kernel, and dozens of other projects that have had healthy forks demonstrate this.
"The mantra of "choice" isn't applicable to every situation."
Yeah, it is.
"Standardizing on a platform is difficult enough in the Linux world. Forking things whenever one of the devs feels wronged (usually how these things get started) just increases the confusion and non-interoperability between multiple platforms."
Such actions do not touch end-users and are ignorable to them, and by end-user, I mean anyone installing and using a distribution.
Unless, as an end-user you're going out on the Net searching for CVS repositories to download from, you don't care. If you are doing that... then, well, you're dipping your hand into a bag and getting whatever comes out. Might be something nice, but I don't recommend it.
When I install Fedora or SuSE or Mandrake or what-have-you, I don't care about what project management looks like, I care that when I click a button it does what I want.
Distribution maintainers take on the JOB of managing their software mix and the interaction between them and a given project. It's work, and it's HARD WORK, but the good news is that it's work that pays off richly as demonstrated by the many quality products that are, at their heart, a Linux distribution from RHEL to TiVo, it's all Linux Inside.
If goal is to enforce licensing, then handing flyers to booth-babes isn't the way to go about it.
:-/
Score 0 for the geeks
My feeling is this: most of today's bottlenecks are related to bus and memory I/O. The fraction of bottlenecks that are CPU-related can generally be addressed more reasonably via true SMP, rather than multi-core pseudo-threading.
For those trivial number of cases where this technology is a win... well, there you go, but the problem is that that small section of the consumer base is dictacting that MY CPUs will be more expensive. This is unthrilling to me....
"Most of these features you wish to compare are not part of a Linux operating system. Most are applications that are installed on top of a Linux operating system.
So, among the Linux distributions, all of these features are roughly eqivalent, providing that you are using the same software to meet the need for the particular feature."
VERY untrue! You will find that, for example, LDAP support (and the ability to talk to AD if needed) varries widely from distribution to distribution, even though they all have roughly the same tools for talking to LDAP. The key questions are: how easy is it to set up; how well are applications, tools and libraries configured to integrate any given feature you need; are conflicting services installed by default (and/or REQUIRED);etc.
You might not think this way because you worry about <1000 end-user machines, but let me tell you, when you need to install 5,000 end-user desktops, you're not thinking, "eh, it's ok... I'll just install anything and configure to taste," you're looking for something that gets you as close to the finish-line as possible so that you can worry about the truly hard problems. Sure, you're just going to dupe hard-drives, but that doesn't get you the perfect economies of scale you might have expected. You're going to worry about things like, "oh look, this LDAP server falls over when 1000 clients ask it a question at once," and other scaling issues. You don't want to have to start at ground-zero, "why doesn't LDAP work with applications X and Y and works half the time with Z."
The above is just an example, but I think it illustrates the point.
Wow. I don't know what to say. I'm posting this from FC3, and the only crashes I've seen have to do with the CD writer and the burner program that Nautilus launches. I'll see if I can replicate any of your (as yet unsolved) problems. Glad to hear the login one is fixed, though.
I'd be curious to see what you're doing that could cause that (I'm not saying it's your fault; software should not crash), but I'd love to know how you triggered it. That's the kind of thing that I'd enjoy debugging.
You're massively confused about the definition of a query and a user as I used them in my post. I can't even really respond to what you said directly without clearing up those points first.
Ok, so you're saying that you can already can queries... yes, of course you can, what on earth did you think was being suggested by canning a query, and how does canning such a query involve re-inventing anything at all?! The suggestion was that, instead of going off and creating some OTHER SITE to track feature requests, instead a canned query be used in bugzilla. I think perhaps you got confused over what the list members had suggested, since you seem to be echoing their comments.
Second, you call the users "stupid". First off, remember that the "users" in this case are the developers who wrote Gnome. They're not stupid. Ranking a feature request as urgen becuase it's one of the highest profile items in the database is also not stupid. Using a keyword (standard bugzilla functionality for years) is to then collect all such requests is also not stupid.
I'm not sure if you just got confused over who we were talking about, or you just assumed that the Gnome developers were all just a bunch of monkeys banging on a keyboard until the result compiled, but I can assure you that both are incorrect.
Why would you ever can any query? Simple, to save keystrokes, and increase the likelyhood that any given dev will actually USE the query. What you suggest might also not be sufficient. For example, there might be so many requests that a menu editor be put back in that it's ranked as "urgent", and yet it's still an enhancement request. A keyword would be a better way to track such things.
I've never seen a panel crash. Nautilus crashes under me under FC3 (home desktop) from time to time, but it seems that this is related to previews (e.g. some underlying program that's reading a file soils itself and Nautilus wigs out). Turning off previews helped this quite a lot.
As for NFS-mounted homedirs... I don't have a problem. Is your NFS server correctly time-synced, running statd, etc.? At work I used (until very recently) and NFS-mounted homedir for Gnome. Works like a charm.
I do get some lockups, but those were a result of the crappy NVidia driver support, not Gnome (and that's NVidia's fault for not publishing specs... I had to give up and use their binary driver, since I don't spec what cards to buy).
Interesting thread. The basic concept is this: "we should have a page specially designed for tracking feature requests".
The answers varied, but seemed to center on "no, we have bugzilla" and "if you want to do that with bugzilla, create a special query page for devs to review feature requests."
This sounds like reasonable advice to me....
"Real, for-profit development succeeds mostly by doing something the customer wants."
And so Gnome, being the combined effort of real, for-profit companies like Novell, Sun, IBM, Red Hat and many others is... I'm sorry, what was your point there again?
"By failing to listen to and develop to their requests"
No, you see that's just the problem. Tools and systems like Gnome (which is a far-reaching set of specs, libraries and applications, which few of its users appreciate the value of, nor take advantage of beyond creating cute menus), are desgined for the needs of a huge and diverse community of users and user needs. Gnome satisfies the needs of its users....
AND THAT IS WHAT THE SLASHDOT CROWD HATES. We, here at Slashdot, are a microcosm of developers and geeks of various flavors. We have specialized needs, and we hate seeing out tools "watered down" by the needs of the average user.
That's fair, and I'm not saying that we should not push for our needs too, but face it: Gnome and KDE have both reached a level of popularity where your average Slashdotter is no longer the primary target-user. Cope.