What is wrong with having the options? And there is a very good reason why the terminal should have a separate setting for textfields: it's not a textfield and it doesn't act like one. I don't want an annoying blinking box of a cursor in my terminal. It is, however, nice to have a blinking cursor in textfields.
Now on to the rest of your points. Who does it hurt to have extra config options? If the defaults are sane, then regular users don't have to touch them, but for people who care, the options are available. I mean, I thought this was the whole point of Linux and FOSS, that you wouldn't have some monolithic entity telling you how you are going to use your computer and what is "best" for you. GNOME is the anti-thesis of this. GNOME knows how things should be. GNOME knows that you only need to care about blinking cursors globally. GNOME knows that you don't want to make good use of your screen real-estate so all themes have to have huge amounts of wasted space. GNOME knows that you don't want to change settings, so they are hidden away in gconf instead of being in a useful and documented config dialog. Etc. etc. etc.
Yes, I am aware of and use gconf. And it helps some, but there's still some bone-headed design decision. My favorite, of course, is how they made it so that cursor blinking is a global setting. It doesn't matter if you use gconf or not, either your cursor blinks everywhere, including the terminal, or it blinks nowhere. That is, neither setting is acceptable.
Yes, that's because you can't configure GNOME, and it doesn't do what you need it to do, so you just give up and accept the brown-plated shit that is given to you.
Having to run a compiler means less control over your code. If you are really that anal about it, use assembly, or better yet, just code in a hex editor.
MOC doesn't really do that much. It just generates some much-needed code for limited object introspection. Otherwise, it's not much more advanced than what you already get with the C preprocessor.
I use a high resolution screen and I'd rather have the layout reasonable and pleasing to the eye (not to mention more real estate for actual content), than be able to click the button an extra millisecond faster. Even Mac buttons aren't as big as what GNOME generally has, and since Mac is all about HIG and that kind of stuff, I assume that the buttons really just don't need to be that fucking big.
"It would start if they got out of the habit of using excessively lavish button bars with enourmous, heavily padded buttons."
I'm glad I'm not the only one annoyed by this. The strange padding fetish that the GTK folks has results in terrible feng shui for most GNOME apps, especially Nautilus. Even tweaking the theme manually to reduce the insane amounts of padding only helps a little, and often causes subtle and not-so-subtle rendering glitches.
I'll ignore your reductio ad absurdum rant at the beginning (except to say that just because there are a lot of theoretical cases that we *can* respect, it doesn't mean that we necessarily *must* respect all of them) and go straight to the point. First of all, I don't think nor did I say that JS was the be all end all of languages. It's small, fairly clean and gets the job done. Are there better languages out there? Sure. Are there better languages in the same "niche" as JavaScript? Yes. Is JavaScript a terrible, convoluted, ugly mess? No (but DOM and web-browser support make it uglier than it needs to be). And that's really the extent of my point.
Honestly, I don't see the big deal with having strict block-level scoping rules. It really seems like it makes it harder to deal with the code because you have more levels to keep track of. If you really need levels of scope nesting, just use functions. And then your code will be more clear.
I've never run into a situation where I though "damn, I could really use proper block-level scoping" when using JS or PHP. And I came from a background of C, and I really like C. I appreciate the theoretical value of block-level scoping, but in practice, it seems to be nearly useless.
C++ is awfully convoluted, maybe. JavaScript is pretty simple and straightforward, aside from a few minor gotchas. Most of the problems with JavaScript are browser API issues and not with the core language itself. It's pretty much the opposite of convoluted.
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
Are you running that from GNOME? I didn't have to have all that kbuildsycoca because I was already running KDE so everything is ready to go. I admit that that's a bit annoying, but it's a one time thing per session and usually doesn't take that long on moderately modern hardware.
Uhhh...if you have some background portion of the process that is CPU or IO intensive, you will want that to be in a separate thread, not in the same thread as the UI. If you don't, you get a UI that locks up completely, which is a real pain for the user.
There's no competition between XFree86 and X.org because XFree86 is effectively dead. There still is a monopoly on X, but they have a more open development process, which is why things are proceeding at a faster pace now.
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
Qt apps start up pretty damn fast for me. I can't really tell a difference between Qt and GTK+ start up times, honestly. Using "time gedit" and "time kedit" and then clicking the close button as fast as I can yields nearly equal times, at about half a second.
What? Within a desktop, everything is more or less consistent. Yes, there is some inconsistency *between* desktops, but if you avoid using programs from another desktop, it's not a problem. Also, there are themes that make the apps look the same, and the copy/paste problems were solved years ago. Honestly, I have no trouble using mixed apps on the same desktop.
What is "proper diction"? You mean the diction used by standard written English. Well, that's all well and good, but that's just one possible set of words. There's nothing inherently "proper" about it except that it is the current accepted standard for writing this particular language. God did not come down and bequeath unto us mortal humans standard written English. From a linguistic standpoint, it's no more proper than any other dialect's set of words. Now, if you are writing a book, then you definitely need to follow the rules of standard written English and not use dialectical or colloquial words, idioms and grammatical rules. I agree with you there. But in general, it's not "inferior". If you want inferior, try looking at a pidgin, which is actually a true subset language with incomplete rules and minimalist vocabulary and is, of course, illiterate by nature.
Many spoken dialects other than AA ones pronounce words differently from the standard. Often, their pronunciations predate the ones developed by the standard, so they are, from a historical standpoint, more "correct". Yes, dialects are usually inherently illiterate (as the written standard dialect is preferred in modern times when writing, for obvious reasons), but that doesn't make them "mispronunciations" or inferior, in and of themselves. Using them in the wrong situations or with the wrong groups of people is a problem, obviously. But it's a very different problem.
The Normans didn't change the language as much as people like to think. The Viking invasion and the Renaissance had greater effects than the Norman invasion did. The main by-products of the Norman invasion were a new/modified spelling system and some new vocabulary (but still a lot of native English vocabulary hung around until the Renaissance or at least the late Middle English period). The grammar changes, such as the loss of inflections and the change in word order were already underway during the late Old English period and may have been spurred/hastened by interaction with the Vikings.
The spelling problems arose later, with the Great Vowel Shift and a lot of refusal to fix spelling back when we had the chance.
The asc shows up correctly for me on Firefox on Linux, but the thorns (both capital and regular) do not show up at all. I didn't use any other characters and I'm glad I didn't.
Butchery...or an evolution for more effective communication over a limited channel? As for rap and R&B, there's no butchery there at all, it's just based on a different dialect of English.
I don't understand where these "decline of civilization" people come from and how they so ironically prove the point they are making by being complete and utter idiots who make groundless and ignorant claims without any qualification whatsoever.
The "u" was removed by Noah Webster. There were some other intentional changes, like "aluminium" -> "aluminum". The purpose was, among other things, to differentiate the language from British. Of course, this all happened at a time when spelling wasn't fully standardized, so neither British nor the Americans were had the "correct" spelling for the other side to bastardize.
As for language evolution: its sole purpose is not to progress in a positive direction, but to progress in such a way that the speakers are able to express what they want and need to express. If that means simplification in syntax or morphology or whatever, then so be it. Any other standard for language evolution is groundless. The rest of your rant is just ignorant and hateful BS.
"Hacker" still means what it used to mean, but only among the community of for-fun programmers. So those people who get incensed about it are half-right. They are generally wrong, however, because in the common parlance, it really does truly mean someone who breaks into computers. Context almost always clears up whether it is meant to be used in the common fashion or in the jargon fashion. "I spent all weekend hacking on my Perl module" is clearly positive (well, unless you hate Perl) and would only be used amongst people who know what any of that means anyways.
Slashdot Mirror
What is wrong with having the options? And there is a very good reason why the terminal should have a separate setting for textfields: it's not a textfield and it doesn't act like one. I don't want an annoying blinking box of a cursor in my terminal. It is, however, nice to have a blinking cursor in textfields.
Now on to the rest of your points. Who does it hurt to have extra config options? If the defaults are sane, then regular users don't have to touch them, but for people who care, the options are available. I mean, I thought this was the whole point of Linux and FOSS, that you wouldn't have some monolithic entity telling you how you are going to use your computer and what is "best" for you. GNOME is the anti-thesis of this. GNOME knows how things should be. GNOME knows that you only need to care about blinking cursors globally. GNOME knows that you don't want to make good use of your screen real-estate so all themes have to have huge amounts of wasted space. GNOME knows that you don't want to change settings, so they are hidden away in gconf instead of being in a useful and documented config dialog. Etc. etc. etc.
Yes, I am aware of and use gconf. And it helps some, but there's still some bone-headed design decision. My favorite, of course, is how they made it so that cursor blinking is a global setting. It doesn't matter if you use gconf or not, either your cursor blinks everywhere, including the terminal, or it blinks nowhere. That is, neither setting is acceptable.
Yes, that's because you can't configure GNOME, and it doesn't do what you need it to do, so you just give up and accept the brown-plated shit that is given to you.
Just download it from Mozilla, unpack it on your desktop and run it from there. I've never had any problems doing that.
Having to run a compiler means less control over your code. If you are really that anal about it, use assembly, or better yet, just code in a hex editor.
MOC doesn't really do that much. It just generates some much-needed code for limited object introspection. Otherwise, it's not much more advanced than what you already get with the C preprocessor.
I use a high resolution screen and I'd rather have the layout reasonable and pleasing to the eye (not to mention more real estate for actual content), than be able to click the button an extra millisecond faster. Even Mac buttons aren't as big as what GNOME generally has, and since Mac is all about HIG and that kind of stuff, I assume that the buttons really just don't need to be that fucking big.
"It would start if they got out of the habit of using excessively lavish button bars with enourmous, heavily padded buttons."
I'm glad I'm not the only one annoyed by this. The strange padding fetish that the GTK folks has results in terrible feng shui for most GNOME apps, especially Nautilus. Even tweaking the theme manually to reduce the insane amounts of padding only helps a little, and often causes subtle and not-so-subtle rendering glitches.
I'll ignore your reductio ad absurdum rant at the beginning (except to say that just because there are a lot of theoretical cases that we *can* respect, it doesn't mean that we necessarily *must* respect all of them) and go straight to the point. First of all, I don't think nor did I say that JS was the be all end all of languages. It's small, fairly clean and gets the job done. Are there better languages out there? Sure. Are there better languages in the same "niche" as JavaScript? Yes. Is JavaScript a terrible, convoluted, ugly mess? No (but DOM and web-browser support make it uglier than it needs to be). And that's really the extent of my point.
Honestly, I don't see the big deal with having strict block-level scoping rules. It really seems like it makes it harder to deal with the code because you have more levels to keep track of. If you really need levels of scope nesting, just use functions. And then your code will be more clear.
I've never run into a situation where I though "damn, I could really use proper block-level scoping" when using JS or PHP. And I came from a background of C, and I really like C. I appreciate the theoretical value of block-level scoping, but in practice, it seems to be nearly useless.
C++ is awfully convoluted, maybe. JavaScript is pretty simple and straightforward, aside from a few minor gotchas. Most of the problems with JavaScript are browser API issues and not with the core language itself. It's pretty much the opposite of convoluted.
Are you running that from GNOME? I didn't have to have all that kbuildsycoca because I was already running KDE so everything is ready to go. I admit that that's a bit annoying, but it's a one time thing per session and usually doesn't take that long on moderately modern hardware.
Uhhh...if you have some background portion of the process that is CPU or IO intensive, you will want that to be in a separate thread, not in the same thread as the UI. If you don't, you get a UI that locks up completely, which is a real pain for the user.
There's no competition between XFree86 and X.org because XFree86 is effectively dead. There still is a monopoly on X, but they have a more open development process, which is why things are proceeding at a faster pace now.
Qt apps start up pretty damn fast for me. I can't really tell a difference between Qt and GTK+ start up times, honestly. Using "time gedit" and "time kedit" and then clicking the close button as fast as I can yields nearly equal times, at about half a second.
What? Within a desktop, everything is more or less consistent. Yes, there is some inconsistency *between* desktops, but if you avoid using programs from another desktop, it's not a problem. Also, there are themes that make the apps look the same, and the copy/paste problems were solved years ago. Honestly, I have no trouble using mixed apps on the same desktop.
'"A lot" is two words. You wouldn't say "alittle", would you?'
No, but I would say "another" ;).
What is "proper diction"? You mean the diction used by standard written English. Well, that's all well and good, but that's just one possible set of words. There's nothing inherently "proper" about it except that it is the current accepted standard for writing this particular language. God did not come down and bequeath unto us mortal humans standard written English. From a linguistic standpoint, it's no more proper than any other dialect's set of words. Now, if you are writing a book, then you definitely need to follow the rules of standard written English and not use dialectical or colloquial words, idioms and grammatical rules. I agree with you there. But in general, it's not "inferior". If you want inferior, try looking at a pidgin, which is actually a true subset language with incomplete rules and minimalist vocabulary and is, of course, illiterate by nature.
Many spoken dialects other than AA ones pronounce words differently from the standard. Often, their pronunciations predate the ones developed by the standard, so they are, from a historical standpoint, more "correct". Yes, dialects are usually inherently illiterate (as the written standard dialect is preferred in modern times when writing, for obvious reasons), but that doesn't make them "mispronunciations" or inferior, in and of themselves. Using them in the wrong situations or with the wrong groups of people is a problem, obviously. But it's a very different problem.
The Normans didn't change the language as much as people like to think. The Viking invasion and the Renaissance had greater effects than the Norman invasion did. The main by-products of the Norman invasion were a new/modified spelling system and some new vocabulary (but still a lot of native English vocabulary hung around until the Renaissance or at least the late Middle English period). The grammar changes, such as the loss of inflections and the change in word order were already underway during the late Old English period and may have been spurred/hastened by interaction with the Vikings.
The spelling problems arose later, with the Great Vowel Shift and a lot of refusal to fix spelling back when we had the chance.
The asc shows up correctly for me on Firefox on Linux, but the thorns (both capital and regular) do not show up at all. I didn't use any other characters and I'm glad I didn't.
Butchery...or an evolution for more effective communication over a limited channel? As for rap and R&B, there's no butchery there at all, it's just based on a different dialect of English.
I don't understand where these "decline of civilization" people come from and how they so ironically prove the point they are making by being complete and utter idiots who make groundless and ignorant claims without any qualification whatsoever.
The "u" was removed by Noah Webster. There were some other intentional changes, like "aluminium" -> "aluminum". The purpose was, among other things, to differentiate the language from British. Of course, this all happened at a time when spelling wasn't fully standardized, so neither British nor the Americans were had the "correct" spelling for the other side to bastardize.
As for language evolution: its sole purpose is not to progress in a positive direction, but to progress in such a way that the speakers are able to express what they want and need to express. If that means simplification in syntax or morphology or whatever, then so be it. Any other standard for language evolution is groundless. The rest of your rant is just ignorant and hateful BS.
There is no palatal-velar fricative. He meant palatal fricative. Hopefully, that clears everything up!
"Hacker" still means what it used to mean, but only among the community of for-fun programmers. So those people who get incensed about it are half-right. They are generally wrong, however, because in the common parlance, it really does truly mean someone who breaks into computers. Context almost always clears up whether it is meant to be used in the common fashion or in the jargon fashion. "I spent all weekend hacking on my Perl module" is clearly positive (well, unless you hate Perl) and would only be used amongst people who know what any of that means anyways.
Slashdot raped my Old English, so I feel your pain.
Fuck you Slashdot and your inability to even handle Latin-1, to say nothing of Unicode. DIAF.