Because the kernel manages hardware resources. Modesetting and graphics memory management should be done by real drivers in the kernel, just like everything else.
Right now, you basically have two driver frameworks managing the video hardware (and possibly more): the kernel's own framebuffer and the X.org drivers, which already have DRM shims in kernelspace. That is way too complicated and why anybody thinks having two drivers competing for a single piece of hardware is a good idea is beyond me.
There is a segment of the Unix population that seems to think that anything that's been done for longer than, say, 10 years, is automatically correct and anybody who chooses to change things is automatically wrong.
FWIW, Linux and the open source BSDs are the only Unices that have had X modesetting and basic video driver functionality OUTSIDE the kernel. The commercial Unices had special X drivers in the kernel, Mac OS X obviously has kernel mode graphics support, as does Windows, although it is partitioned off from the rest of the kernel to some degree. And which OS has the most problems with graphics drivers, crashes and lockups related to that? Linux...
You have to have contiguous sections of address space large enough for the allocation. If you're on Windows, and you've already allocated, say, a gigabyte of heap space, plus whatever is taken up by your code, stack and loaded libraries, then even a relatively small request might end up failing, even if there is enough memory available. There is just no free chunk large enough to satisfy it.
In fact, on a 32-bit system, I can say with 95% confidence that you could never allocate, say, 1GB in a single allocation and have it succeed. There are probably smaller numbers that work here as well.
The comparison with German was only for illustrative purposes (and I'm not a German-freak, which is something you seem to have pulled out of your ass). Looking at how things work in other languages is meant to show that it is not stupidity that creates the patterns we see in English. Almost any pattern you see in English that you consider to be stupid and the product of the "lowest common denominator" is an accepted feature in the standard dialect of some other language.
These things that people say _are_ reasonable. They just don't happen to be part of Standard Written English, which is only one of many dialects of English. Nothing it does is inherently superior to what the non-standard dialect do. Can you tell me how "borrow to" is actually wrong, other than the fact that it's non-standard? I'm not advocating using it in professional or even casual writing, but calling it stupid or ignorant or something that only mouth-breathing idiots would say is really going too far.
The big issue that most people are ignorant on here is the idea that non-standard usage is somehow "illogical" or "breaking the rules". As a linguist, I really cannot stand this type of attitude, mainly because it's utterly wrong, but also because it can be used as a tool to belittle and judge others for the way they speak.
What's wrong with "borrow to"? Those verbs have never had a strong fixed meaning in Germanic languages. In German they are somewhat interchangeable in certain circumstances. Same with "bring" and "take". The only ignorance is on the part of the grammar freaks who think they actually know anything about how language works.
No word has just one meaning. That's what makes language great. There are nuances, metaphors, intentional misuse, irony, litotes, etc. These all add to the richness of expression. Yes, from a purely logical standpoint, you could have a word mean one and only one thing and require a set of strict rules in which those words could be used. But that would make the language only capable of expressing a subset of what it can express now? The alternatives you have given, for example, do not suffice in this case, especially "uncommon" and "unusual". In fact, let's take a look at how these words would simply not work in many of the cases in which people use degrees of "unique":
"rare" -- denotation: the referent belongs to a small subset of U, which is either the set of all things, or the set of things of interest to the conversation. This would not work as a replacement for "very unique" because the connotation of "rare" focuses on the frequency of occurrence, rather than the nature of the item's rarity. "uncommon" and "unusual" are less strong forms of "rare" and suffer from the same problems. "extraordinary" -- denotation: some subset S of U is considered "normal" and the referent belongs to a different subset T which is smaller than S and has attributes that are held to be of greater value than the attributes of items in S. While this word hits closer to the mark because it talks about attributes rather than just frequency, it misses because it talks about attributes in the wrong way. Namely, it is rating the referent based on the value of its attributes, which, again, is not the focus of "unique". Same is true for "exceptional", a stronger form of "unique".
You see, you really can't express that something has one or more attributes that set it apart from any other item in the set of items with a given attribute. I suppose we could make up a word, but we already have a perfectly good one: "unique". If I say something is more unique than something else, I am merely saying that it has more unique attributes than the second item. No other word cuts it. It implies other things, such as the value of those attributes, or it simply talks about the frequency of the object in question, with no reference, really, to its attributes.
There are plenty of examples of people misusing good English words out of confusion or just lack of thought. Usage of "unique", however, is not one of them.
That would be the ultimate April Fool's joke: good stories, grammatically correct summaries, no dupes, etc. And at the end they'd say "April Fools! Just kidding!"
It's not misuse. The only misuse is from the grammar NAZIs who refuse to understand nuance and complexity in language.
In common usage, "unique" can refer to all attributes, or only a single attribute or subset of them. Thus, you can have degrees of uniqueness based on the number of attributes that are unique. And in a more metaphorical way, uniqueness can also refer to the degree to which the differences that make the item unique set it apart. If the differences are large, then we would say "xyz is very unique". This is really just the same thing as what I said at the beginning of the paragraph, but from a more holistic point of view.
Now, if the grammar NAZIs would pull their heads from their asses and take some time to think about what things actually mean, we wouldn't have this problem. By telling people they cannot use "unique" in this fashion, they are denying expressivity, which is not supposed to be the point of good grammar.
> I have also seen older people explaining to young bucks why a certified distro like Red Hat ES > rather than the young bucks own favorite distro like, say, Gentoo, is the best pick for an > Oracle server's OS
lol
(written on a Gentoo laptop, which is why I lolled)
Something like that would be nice in Java. And it follows the pattern I described above much better. If you expect errors and failures or end of file as part of normal processing, it's not an exception and exceptions should need to be used.
I wish over-use of exceptions was the only thing that bothered me about Java...
What's wrong with reading until you get to the end of the file? That's how the idiom seems to be done in every other language I've used. Why is that an exception in Java? If it's the end of the file because there was an IO error, that's one thing. But in the case I'm talking about, it's not.
> 9. Any error handling through error return codes, probably to be replaced by exceptions, unless it turns the calling code into a wild mass of try/catch blocks.
Exceptions should be used to mark, well, exceptional failure. I really really hate this pattern that Java (and perhaps from elsewhere) has foisted upon us where we get frickin exceptions because we reached the end of the file. That is technically an error condition in the reader function, but it is not exceptional and it shouldn't require me to write the "wild mess of try/catch blocks" just to read in data from a file. Exceptions say "we are really in a mess and have to abort this operation, and potentially the program. They do not say "could not find element x in array".
If that's what you were saying, however, then I apologize.
Get a new doctor. Mine has wanted me to move off anti-depressants and drugs (I take low doses of anti-anxiety meds) in general. As do I.
If you have a job and your boss is an asshole, you leave that job and find one where you don't have an asshole boss. Same with doctors. If your doctor isn't helping you and is actually holding you back, and/or being an asshole, leave that shit. The point is for *you* to get better. Don't waste your time.
Re:So when do we get its successor?
on
X Power Tools
·
· Score: 3, Insightful
That's an invalid argument. I may know enough to say my car isn't working (e.g., it won't start), but I certainly don't know enough to fix it.
Most people don't need that, though, when they are just viewing PDFs on the web. Nobody is really saying that Foxit/et al can or even should do all of what you are saying. But they're okay with that because they don't need to participate in online meetings through a PDF reader.
Again, I would say that putting hooks and the core graphics framework in kernel mode is all that's needed. Naturally, most everything else belongs client-side. Even Windows and Mac OS X follow this philosophy. For performance reasons, you want any code that deals with directly interfacing with the hardware, or that must deal with resource-contention across multiple threads/processes to be in kernel mode where that kind of thing can be done FAST. So, in a sense, we agree that the high-level stuff shouldn't be in the kernel. We disagree (perhaps not?) that low-level stuff should be in the kernel, be it graphics or not.
There is so much knee-jerkery about the GUI in the kernel, and that's what bugs me. There are very legitimate reasons to put SOME (by no means all, or even most) of the GUI into the kernel as I described above. Same for filesystems and other drivers. But so many people are opposed to doing any of it because Unix didn't and Windows does. That's what really bothers me. I pretty much agree otherwise with what everyone else has said here. And obviously, for Linux, having a GUI in the kernel could be optional or in a set of modules (not to dissimilar from the DRM).
Yes, I'm quite aware of the history of terminals. But terminal line discipline, tty and pseudo-tty support is built DIRECTLY into the kernel. So, I'm right.
If you're going to follow the line of "what's minimally required to be functional", you could strip out a lot more. That doesn't mean it's a good OS. A good OS should provide a stable and standard set of functionalities that are actually useful to most people. If we include terminals, then we should include GUIs. The fact that SOME GUI apps happen to be prone to crashing (and there's plenty of scripts I can think of that also like to crash a lot), does not mean that a GUI does not belong as a part of the OS. That's a specious argument.
Architecturally speaking, yes, I agree that the GUI and terminals and IO should be more towards the outer part of the OS. There should be hooks in the kernel and then userland daemons and libraries that do the rest of the work (more in the fashion of a microkernel). But a well designed piece of software never has everything bundled into one heap anyways.
But I think the time has come to recognize that the GUI is not some red-headed step-child anymore. It may still be allowed to be optional, as terminal drivers should be (and filesystem drivers, etc.), but it should not be treated like it's presence is only suffered because some lusers like to click with the mouse.
You don't use int 80h any more to make system calls. Instead you jump to an entry in the Linux Virtual Dynamic Shared Object (VDSO) at the top of the 4GB address space of a process, which then takes care of executing the code to enter the kernel, usually the "sysenter" instruction on recent enough x86 platforms.
It's been a long time since an OS has been just a kernel. You have to remember all the kernel threads, system libraries and system daemons that are practically required for the system to run at all. Windows has a number of processes and libraries that are core parts of the system and cannot really be removed (ntdll.dll, csrss.exe, lsass.exe, etc). Mac OS X is the same. None of this includes the GUI, which really should be considered part of the OS. The only reason Unix people don't like that is for historical reasons. Had Unix been invented after the GUI revolution, all the Unix crowd would accept that it is natural for the GUI to be part of the core OS. After all, in Unix, terminals and other IO devices are a part of the core OS. Why should a GUI be any different? It's kind of retarded not to be.
I hope you're being sarcastic. There's a lot more to it than that. There are a lot of phenomena in language that go beyond mere statistics and indeed cannot be explained by it. There are valid sentences that you and I may utter or hear that we have never heard before. If we only had a statistical grammar, we wouldn't be able to understand those sentences, or would get the wrong meaning (or maybe just get lucky for some of them). We certainly wouldn't be able to utter those sentences. And, if statistics were the full basis of language, then computer-based language translation would be a solved problem. As you can see with Babelfish, for example, that is far from being the case.
That's not what dyslexia is. Dyslexia is when someone has to SLOW DOWN to read because instead of just picking up the words quickly, they basically have to "decode" the letters and combinations of letters that make up words. When a normal person reads, the brain quickly matches image patterns to quickly determine what a word is. That's why we can read so fast. We don't sit there decoding letter by letter and then working out what word it corresponds to, etc. For a dyslexic, it is such a slow and ungainly process.
Slashdot Mirror
Because the kernel manages hardware resources. Modesetting and graphics memory management should be done by real drivers in the kernel, just like everything else. Right now, you basically have two driver frameworks managing the video hardware (and possibly more): the kernel's own framebuffer and the X.org drivers, which already have DRM shims in kernelspace. That is way too complicated and why anybody thinks having two drivers competing for a single piece of hardware is a good idea is beyond me. There is a segment of the Unix population that seems to think that anything that's been done for longer than, say, 10 years, is automatically correct and anybody who chooses to change things is automatically wrong. FWIW, Linux and the open source BSDs are the only Unices that have had X modesetting and basic video driver functionality OUTSIDE the kernel. The commercial Unices had special X drivers in the kernel, Mac OS X obviously has kernel mode graphics support, as does Windows, although it is partitioned off from the rest of the kernel to some degree. And which OS has the most problems with graphics drivers, crashes and lockups related to that? Linux...
You have to have contiguous sections of address space large enough for the allocation. If you're on Windows, and you've already allocated, say, a gigabyte of heap space, plus whatever is taken up by your code, stack and loaded libraries, then even a relatively small request might end up failing, even if there is enough memory available. There is just no free chunk large enough to satisfy it. In fact, on a 32-bit system, I can say with 95% confidence that you could never allocate, say, 1GB in a single allocation and have it succeed. There are probably smaller numbers that work here as well.
0x80000000 makes it negative in this case...I believe.
If you are communicating well and being around other people all day, then you aren't a loner.
You mean Sieg Heil...
The comparison with German was only for illustrative purposes (and I'm not a German-freak, which is something you seem to have pulled out of your ass). Looking at how things work in other languages is meant to show that it is not stupidity that creates the patterns we see in English. Almost any pattern you see in English that you consider to be stupid and the product of the "lowest common denominator" is an accepted feature in the standard dialect of some other language. These things that people say _are_ reasonable. They just don't happen to be part of Standard Written English, which is only one of many dialects of English. Nothing it does is inherently superior to what the non-standard dialect do. Can you tell me how "borrow to" is actually wrong, other than the fact that it's non-standard? I'm not advocating using it in professional or even casual writing, but calling it stupid or ignorant or something that only mouth-breathing idiots would say is really going too far. The big issue that most people are ignorant on here is the idea that non-standard usage is somehow "illogical" or "breaking the rules". As a linguist, I really cannot stand this type of attitude, mainly because it's utterly wrong, but also because it can be used as a tool to belittle and judge others for the way they speak.
What's wrong with "borrow to"? Those verbs have never had a strong fixed meaning in Germanic languages. In German they are somewhat interchangeable in certain circumstances. Same with "bring" and "take". The only ignorance is on the part of the grammar freaks who think they actually know anything about how language works.
No word has just one meaning. That's what makes language great. There are nuances, metaphors, intentional misuse, irony, litotes, etc. These all add to the richness of expression. Yes, from a purely logical standpoint, you could have a word mean one and only one thing and require a set of strict rules in which those words could be used. But that would make the language only capable of expressing a subset of what it can express now? The alternatives you have given, for example, do not suffice in this case, especially "uncommon" and "unusual". In fact, let's take a look at how these words would simply not work in many of the cases in which people use degrees of "unique":
"rare" -- denotation: the referent belongs to a small subset of U, which is either the set of all things, or the set of things of interest to the conversation. This would not work as a replacement for "very unique" because the connotation of "rare" focuses on the frequency of occurrence, rather than the nature of the item's rarity.
"uncommon" and "unusual" are less strong forms of "rare" and suffer from the same problems.
"extraordinary" -- denotation: some subset S of U is considered "normal" and the referent belongs to a different subset T which is smaller than S and has attributes that are held to be of greater value than the attributes of items in S. While this word hits closer to the mark because it talks about attributes rather than just frequency, it misses because it talks about attributes in the wrong way. Namely, it is rating the referent based on the value of its attributes, which, again, is not the focus of "unique". Same is true for "exceptional", a stronger form of "unique".
You see, you really can't express that something has one or more attributes that set it apart from any other item in the set of items with a given attribute. I suppose we could make up a word, but we already have a perfectly good one: "unique". If I say something is more unique than something else, I am merely saying that it has more unique attributes than the second item. No other word cuts it. It implies other things, such as the value of those attributes, or it simply talks about the frequency of the object in question, with no reference, really, to its attributes.
There are plenty of examples of people misusing good English words out of confusion or just lack of thought. Usage of "unique", however, is not one of them.
That would be the ultimate April Fool's joke: good stories, grammatically correct summaries, no dupes, etc. And at the end they'd say "April Fools! Just kidding!"
It's not misuse. The only misuse is from the grammar NAZIs who refuse to understand nuance and complexity in language.
In common usage, "unique" can refer to all attributes, or only a single attribute or subset of them. Thus, you can have degrees of uniqueness based on the number of attributes that are unique. And in a more metaphorical way, uniqueness can also refer to the degree to which the differences that make the item unique set it apart. If the differences are large, then we would say "xyz is very unique". This is really just the same thing as what I said at the beginning of the paragraph, but from a more holistic point of view.
Now, if the grammar NAZIs would pull their heads from their asses and take some time to think about what things actually mean, we wouldn't have this problem. By telling people they cannot use "unique" in this fashion, they are denying expressivity, which is not supposed to be the point of good grammar.
> I have also seen older people explaining to young bucks why a certified distro like Red Hat ES
> rather than the young bucks own favorite distro like, say, Gentoo, is the best pick for an
> Oracle server's OS
lol
(written on a Gentoo laptop, which is why I lolled)
Something like that would be nice in Java. And it follows the pattern I described above much better. If you expect errors and failures or end of file as part of normal processing, it's not an exception and exceptions should need to be used. I wish over-use of exceptions was the only thing that bothered me about Java...
What's wrong with reading until you get to the end of the file? That's how the idiom seems to be done in every other language I've used. Why is that an exception in Java? If it's the end of the file because there was an IO error, that's one thing. But in the case I'm talking about, it's not.
> 9. Any error handling through error return codes, probably to be replaced by exceptions, unless it turns the calling code into a wild mass of try/catch blocks.
Exceptions should be used to mark, well, exceptional failure. I really really hate this pattern that Java (and perhaps from elsewhere) has foisted upon us where we get frickin exceptions because we reached the end of the file. That is technically an error condition in the reader function, but it is not exceptional and it shouldn't require me to write the "wild mess of try/catch blocks" just to read in data from a file. Exceptions say "we are really in a mess and have to abort this operation, and potentially the program. They do not say "could not find element x in array".
If that's what you were saying, however, then I apologize.
I think they would operate. The universe doesn't need to know the math. It Just Works (TM).
Get a new doctor. Mine has wanted me to move off anti-depressants and drugs (I take low doses of anti-anxiety meds) in general. As do I. If you have a job and your boss is an asshole, you leave that job and find one where you don't have an asshole boss. Same with doctors. If your doctor isn't helping you and is actually holding you back, and/or being an asshole, leave that shit. The point is for *you* to get better. Don't waste your time.
That's an invalid argument. I may know enough to say my car isn't working (e.g., it won't start), but I certainly don't know enough to fix it.
Most people don't need that, though, when they are just viewing PDFs on the web. Nobody is really saying that Foxit/et al can or even should do all of what you are saying. But they're okay with that because they don't need to participate in online meetings through a PDF reader.
Again, I would say that putting hooks and the core graphics framework in kernel mode is all that's needed. Naturally, most everything else belongs client-side. Even Windows and Mac OS X follow this philosophy. For performance reasons, you want any code that deals with directly interfacing with the hardware, or that must deal with resource-contention across multiple threads/processes to be in kernel mode where that kind of thing can be done FAST. So, in a sense, we agree that the high-level stuff shouldn't be in the kernel. We disagree (perhaps not?) that low-level stuff should be in the kernel, be it graphics or not. There is so much knee-jerkery about the GUI in the kernel, and that's what bugs me. There are very legitimate reasons to put SOME (by no means all, or even most) of the GUI into the kernel as I described above. Same for filesystems and other drivers. But so many people are opposed to doing any of it because Unix didn't and Windows does. That's what really bothers me. I pretty much agree otherwise with what everyone else has said here. And obviously, for Linux, having a GUI in the kernel could be optional or in a set of modules (not to dissimilar from the DRM).
Yes, I'm quite aware of the history of terminals. But terminal line discipline, tty and pseudo-tty support is built DIRECTLY into the kernel. So, I'm right.
If you're going to follow the line of "what's minimally required to be functional", you could strip out a lot more. That doesn't mean it's a good OS. A good OS should provide a stable and standard set of functionalities that are actually useful to most people. If we include terminals, then we should include GUIs. The fact that SOME GUI apps happen to be prone to crashing (and there's plenty of scripts I can think of that also like to crash a lot), does not mean that a GUI does not belong as a part of the OS. That's a specious argument. Architecturally speaking, yes, I agree that the GUI and terminals and IO should be more towards the outer part of the OS. There should be hooks in the kernel and then userland daemons and libraries that do the rest of the work (more in the fashion of a microkernel). But a well designed piece of software never has everything bundled into one heap anyways. But I think the time has come to recognize that the GUI is not some red-headed step-child anymore. It may still be allowed to be optional, as terminal drivers should be (and filesystem drivers, etc.), but it should not be treated like it's presence is only suffered because some lusers like to click with the mouse.
You don't use int 80h any more to make system calls. Instead you jump to an entry in the Linux Virtual Dynamic Shared Object (VDSO) at the top of the 4GB address space of a process, which then takes care of executing the code to enter the kernel, usually the "sysenter" instruction on recent enough x86 platforms.
It's been a long time since an OS has been just a kernel. You have to remember all the kernel threads, system libraries and system daemons that are practically required for the system to run at all. Windows has a number of processes and libraries that are core parts of the system and cannot really be removed (ntdll.dll, csrss.exe, lsass.exe, etc). Mac OS X is the same. None of this includes the GUI, which really should be considered part of the OS. The only reason Unix people don't like that is for historical reasons. Had Unix been invented after the GUI revolution, all the Unix crowd would accept that it is natural for the GUI to be part of the core OS. After all, in Unix, terminals and other IO devices are a part of the core OS. Why should a GUI be any different? It's kind of retarded not to be.
I hope you're being sarcastic. There's a lot more to it than that. There are a lot of phenomena in language that go beyond mere statistics and indeed cannot be explained by it. There are valid sentences that you and I may utter or hear that we have never heard before. If we only had a statistical grammar, we wouldn't be able to understand those sentences, or would get the wrong meaning (or maybe just get lucky for some of them). We certainly wouldn't be able to utter those sentences. And, if statistics were the full basis of language, then computer-based language translation would be a solved problem. As you can see with Babelfish, for example, that is far from being the case.
That's not what dyslexia is. Dyslexia is when someone has to SLOW DOWN to read because instead of just picking up the words quickly, they basically have to "decode" the letters and combinations of letters that make up words. When a normal person reads, the brain quickly matches image patterns to quickly determine what a word is. That's why we can read so fast. We don't sit there decoding letter by letter and then working out what word it corresponds to, etc. For a dyslexic, it is such a slow and ungainly process.