The latest development release of Gnome has the new MIME system, based on the one discussed at freedesktop.org. This is supposed to put a stop to the idiocy that was the previous file association brou-ha-ha.
It's not like these proofs are hard to find. Most of them will involve repeated use of this fact, which is also easy to prove: The countable union of countable sets is itself countable.
You seem like a very angry fellow. Do you get this upset about other trivial things, too? If so, you might want to look into taking a vacation, or finding time to relax.
Seriously, though, your anger at my admittedly vague post is disproportionate, especially since I clarified myself in responses I made before you posted.
Of course, under your assumptions, your conclusion is true. That is, yes, if you accept that the "only evaluation criteria of a GUI is user perception" then "if a GUI system 'feels' slow, it is slow."
No. My point was, and I'll say it again, bloat is not the issue at fault with respect to the original poster's problem. That is all I wanted to say, nothing less and nothing more. I never mentioned anything about the size of a distro, the memory footprint of anything, how long XYZ application takes to load, or the stability of the GUI. But most importantly, I never made any qualitative judgement about which was better to use.
Thank you for playing, but I'm done fighting this land war.
I wouldn't call you weird, and in fact that's what I'd prefer, too. The original poster went something like, "Oh, it makes sense now: Gnome/KDE are bloated, therefore slow, therefore are not fluid." This is incorrect for the reasons I have stated. They are not "slow" in the sense that would cause a lack of fluidity; they might be slow in other senses, but that wasn't what I was talking about. If anything it is the lack of "bloat" (i.e., the lack of code to make it appear smoother) that causes the apparent slowness.
The original article is about bloat, and the original poster posted about the fluidity of Gnome and KDE. My points was that, while other things may be bloated, this isn't. In fact, it's so not bloated that it's faster than Windows or MacOS X. It may feel slower, but that is not an issue of bloat.
Window redraw speeds within a toolkit it mostly what I'm talking about. When people say "Gnome feels slow" they typically mean, as the original poster did here, that the windows are redrawn slowly. They're not, but the way in which they are redrawn gives the impression that they are slower because the redraws are less smooth than in Windows or MacOS X.
No, you can actually measure the redraw speeds of various toolkits. Windows is slower than Gnome and KDE, with GTK+ and QT respectively. Both of them appear slower because of the limitations in XFree86. The same goes for MacOS X.
Given your last sentence, however, it is clear you're not even paying attention to what people are looking at doing or, moreover, at what level the problem rests.
And I really overused the word "things" in that post. What I meant was that XFree86 is empirically faster but feels slower because of the way window drawing is done. In a twisted sort of way it makes sense: XFree86 doesn't spend one second making you think it's fast, and that makes it faster. The catch is that, because of this, you think it is slower.
A lot of it is illusory. When dragging windows around, for example, XFree86 seems slow because it renders the whole process poorly. Things jitter and blink and just look horrible. In Windows and MacOS X things look nice and smooth. However, if you actually measure these things, XFree86 is faster. The same can be said for a lot of things. That is, they seem slower because the way XFree86 does things (which, by the way, is being worked on extensively thanks to people like Keith Packard).
If your machine is unpatched, it's likely that you'll get infected with Sasser within ten minutes of connecting to the internet. On more permissive networks, like a university's, I've heard that (and seen) this happen in less than a minute.
I don't know how many people reading this actively study mathematics, but most of us students have, along the way, made a very good friend: Dover Publishers. Each of their books runs from about $10 to $30, though most are about $15. You can easily find [i]high quality[/i] math text here. To recommend some for Calculus/Analysis:
Advanced Calculus of Several Variables by C.H. Edwards, Jr
Introductory Real Analysis by Kolmogorov (tr. Fomin)
Neither of these books are suited for the beginning calculus student, unless said student is very eager about mathematics, but I haven't been a beginning calculus student for many years now and at the time I didn't know Dover even existed. I'm sure if you looked hard enough you could find a good, elementary calculus text from Dover and you'd only have to pay $10 or $15 for it.
You need to have a textbook anyway: not all students learn best by listening to you talk, and even those students are going to miss class every once in a while.
Thankfully, we have libraries for just this problem! The mathematics department at my university has a nice library where you can find all the commonly used textbooks, and certainly any text covering whatever topic you wanted to learn that day.
If Linus were the sole copyright holder of code in the Linux kernel or had the unanimous agreement of the contributors, yes, he could put the kernel under a different license. However, revoking a license to redistribute and changing the license under which software is redistributed are two different things. Your little id est doesn't hold.
Don't let your mathmatician friends know. Damn mathmaticians.
Re:Something I learned from Martin Gardner...
on
The Golden Ratio
·
· Score: 1
Yes, and in fact, if you let Phi be the positive root of that equation and phi be the negative root (i.e., 1 - Phi), then the nth Fibonacci number is given explicitly as:
Slashdot Mirror
The latest development release of Gnome has the new MIME system, based on the one discussed at freedesktop.org. This is supposed to put a stop to the idiocy that was the previous file association brou-ha-ha.
You can read about it here.
It's not like these proofs are hard to find. Most of them will involve repeated use of this fact, which is also easy to prove: The countable union of countable sets is itself countable.
His premise is: "the only evaluation criteria of a GUI is user perception"
That is not a definition, it is a statement of fact. A fact, I might add, that is assumed and which garners the conclusion he wants.
How exactly is that "the definition of responsiveness?"
You seem like a very angry fellow. Do you get this upset about other trivial things, too? If so, you might want to look into taking a vacation, or finding time to relax.
Seriously, though, your anger at my admittedly vague post is disproportionate, especially since I clarified myself in responses I made before you posted.
Of course, under your assumptions, your conclusion is true. That is, yes, if you accept that the "only evaluation criteria of a GUI is user perception" then "if a GUI system 'feels' slow, it is slow."
Isn't it clear that I don't accept your premise?
1,2,3, predicability.
No. My point was, and I'll say it again, bloat is not the issue at fault with respect to the original poster's problem. That is all I wanted to say, nothing less and nothing more. I never mentioned anything about the size of a distro, the memory footprint of anything, how long XYZ application takes to load, or the stability of the GUI. But most importantly, I never made any qualitative judgement about which was better to use.
Thank you for playing, but I'm done fighting this land war.
I wouldn't call you weird, and in fact that's what I'd prefer, too. The original poster went something like, "Oh, it makes sense now: Gnome/KDE are bloated, therefore slow, therefore are not fluid." This is incorrect for the reasons I have stated. They are not "slow" in the sense that would cause a lack of fluidity; they might be slow in other senses, but that wasn't what I was talking about. If anything it is the lack of "bloat" (i.e., the lack of code to make it appear smoother) that causes the apparent slowness.
The original article is about bloat, and the original poster posted about the fluidity of Gnome and KDE. My points was that, while other things may be bloated, this isn't. In fact, it's so not bloated that it's faster than Windows or MacOS X. It may feel slower, but that is not an issue of bloat.
Window redraw speeds within a toolkit it mostly what I'm talking about. When people say "Gnome feels slow" they typically mean, as the original poster did here, that the windows are redrawn slowly. They're not, but the way in which they are redrawn gives the impression that they are slower because the redraws are less smooth than in Windows or MacOS X.
Hope that helps.
No, you can actually measure the redraw speeds of various toolkits. Windows is slower than Gnome and KDE, with GTK+ and QT respectively. Both of them appear slower because of the limitations in XFree86. The same goes for MacOS X.
Given your last sentence, however, it is clear you're not even paying attention to what people are looking at doing or, moreover, at what level the problem rests.
And I really overused the word "things" in that post. What I meant was that XFree86 is empirically faster but feels slower because of the way window drawing is done. In a twisted sort of way it makes sense: XFree86 doesn't spend one second making you think it's fast, and that makes it faster. The catch is that, because of this, you think it is slower.
A lot of it is illusory. When dragging windows around, for example, XFree86 seems slow because it renders the whole process poorly. Things jitter and blink and just look horrible. In Windows and MacOS X things look nice and smooth. However, if you actually measure these things, XFree86 is faster. The same can be said for a lot of things. That is, they seem slower because the way XFree86 does things (which, by the way, is being worked on extensively thanks to people like Keith Packard).
ESR is about as right as one can get. Or at least as Libertarian as one can get. RMS on the other hand...
When discussing nigritude ultramarine it is important to understand the impact of nigritude ultramarine on nigritude ultramarine.
If slashdot wins, does that mean we all get to share an iPod and a 17" LCD monitor?
If your machine is unpatched, it's likely that you'll get infected with Sasser within ten minutes of connecting to the internet. On more permissive networks, like a university's, I've heard that (and seen) this happen in less than a minute.
There's some truth to that sentiment.
English has been doing fine for a while now without you defending her. Go home, eat a sandwich, and let English take care of herself. Thanks.
http://porthole.sourceforge.net/
http://www.nongnu.org/kportage/
Haha, have you seen most women try to operate hardware, lol!
- Advanced Calculus of Several Variables by C.H. Edwards, Jr
- Introductory Real Analysis by Kolmogorov (tr. Fomin)
Neither of these books are suited for the beginning calculus student, unless said student is very eager about mathematics, but I haven't been a beginning calculus student for many years now and at the time I didn't know Dover even existed. I'm sure if you looked hard enough you could find a good, elementary calculus text from Dover and you'd only have to pay $10 or $15 for it.Could you honestly see Microsoft including IE, Mozilla, Opera, and five command-line browsers? I couldn't.
If Linus were the sole copyright holder of code in the Linux kernel or had the unanimous agreement of the contributors, yes, he could put the kernel under a different license. However, revoking a license to redistribute and changing the license under which software is redistributed are two different things. Your little id est doesn't hold.
This has already been done. The group called themselves Oasis.
Don't let your mathmatician friends know. Damn mathmaticians.
Yes, and in fact, if you let Phi be the positive root of that equation and phi be the negative root (i.e., 1 - Phi), then the nth Fibonacci number is given explicitly as:
F(n) = (Phi^n - phi^n)/Sqrt(5)