It's NOT new, I invented it ages ago, I've just never said it to anyone before. Your use of the term "patent squatters" is um, hurting my business, stop using it NOW or you will be hearing from my lawyer (and he's jooish)
"And allowing proprietary stuff into the kernel solves *what* problems exactly?"
Slow frame rate with opengl/games?
Seriously, unless you've developed the driver -yourself-, what difference does it make whether it's proprietary or not?
My nvidia drivers have never let me down, I'm tired of the slashdot attitude of "omg but they could!" just because the source isn't available to jerk off over.
My parents car once crashed. No, I don't mean a collision, the software locked up. This stopped (amongst other things) the electric doors (the middle one's) and windows (all of them) from working. No reset button. Had to disconnect the battery, then take it to get patched. Kinda unnerving.
"for two processes to communicate over a normal serial socket they do it one byte at a time"
I don't believe this is true. There'll be a maximum limit (which I recently hit myself, so you have to fragment large amount of data, but I forget what the limit I hit was), but moving data one byte at a time would be incredibly inefficient, I can't see it happened often at all. I guess the actual mechanism is that you send the length of your message as a (couple?) of bytes, followed by the message itself. The other end will read the length, and then read that many bytes of actual message.
"One process strill has to request and or accept a socket from another"
What you're I think talking about is zero-copy messaging, and is used in some places when you are moving pages at a time, and when the sender no longer needs the buffer/memory that the message is placed in. One useful place this can happen is passing packets along the network stack, when it's a case of "read, figure where it's to go, and pass it on... then read the next one".
Often though, copying is needed, as you may need to change stuff in the buffer, but need to make sure the reciever had the version before you carried on changing it.
I think you need to read the post you replied to again, especially how the second sentence (beginning "Everything") changes the meaning of the first sentence, which you replied to as if the second one wasn't even there.
You have a cause there, and an effect, but unfortunately you've got the two mixed up, which is a classic sign of low serotonin levels, you might wanna check up on that. And of cause I could just respond with something like "but you pointed out that I typed ~10% of my words in caps, so you must be right", but I think when you address the format of a response rather than the response itself, credability becomes hard to retain. (Yes I am aware of mine slipping quickly away too, I just fancied a quick head-up-my-arse response, get it out of my system, I'll be back to normal again after, as long as no one says anything stupider).
As much as you say what the reply was to, the message that was replied to had/before/ that: the domain registration matches up... which means it is shown that there is no seperate "they" to intercept login details to begin with. Leaving aside that it's not run by man eating elephants, going to the website could mean you get eaten up by man eating elephants!!!
Okay I'll stop now.
(and yes I have apologised to him for the harshness of my response)
Then I apologise for the harshness of my post, it was in response to several people's posts, unfortunately it got attached to yours, slashdot seems to breed frustration *lol*
"Nvidias unwillingness to simply document their product"
Simply? Are we talking about the same product line here? Leading edge highly competitive constantly pushing the boundaries through advanced hardware and software optimisation graphics renderers? And you want them to "simply" document them... all...?
Sorry but I'd rather leave it to the people who are employed to be skilled in building them. Nvidia/ATI have pretty much left everyone else behind with their graphics processors, if no one's come close to designing better hardware, why the hell would you wanna put a super fast graphics card in the hands of hobbiest driver writers? Could they really do a better job?
Their windows drivers are closed source, but I expect them to work. I also/do/ expect the nvidia linux drivers to work, because... they do!
Sure, nvidia "might not" keep the drivers up to date with all the linux kernel side changes that are going on, but they "might not" with windows as well... but they do, so their customers can use their product.
Okay, this weeks drivers might not work with next weeks kernel, but this is a problem with the linux kernel not having the same backwards compatibility as windows. Can hardly blaim nvidia for that.
It's so not as big a deal as everyone keeps making out.
It's the second name, I guess like it's supposed to be the "second" android, god knows what the submitter was on. It was made out of spare parts from the first one.
So something like the Viking Runic alphabet? They used all straight lines, but for a different reason (OCR hadn't been invented then) - their writing implement was usually something like a knife on stone or wood.
"Main issue to remember is that computers process in numbers, not letters, to completely solve this issue, we'd need a language that's completely based on numbers"
I don't know how you've reached that conclusion, there's actually not that much difference between numbers and letters to a computer - both have binary values. The only reason a computer might be able to recognise digits 0-9 easier than also including A-Z, is that there are less glyphs to recognise in the alphabet. All you'd by doing by writing down numbers instead of letters is changing the set of patterns it's trying to recognise.
Numbers would also be easier to recognise than say, joined hand writing, as it's obvious what's part of each digit, with joined it's harder to tell if a line is part of the first character, the second, or if it's just part of the link between the two.
You get quite a performance hit with FUSE though, although this isn't a problem with "slow" filesystems (eg, sftp, googlefs interfaces) where most of the time is spent waiting for data to be sent/recieved, with local high performance filesystems the hit is more than noticable. Unfortunately the faster code runs, the greater the chance-per-second a bug will cause a problem.
...we've decriminalised green, so we just sit around stoned all day anyway... *I* can't even remember how to get into my system :-p
It's NOT new, I invented it ages ago, I've just never said it to anyone before. Your use of the term "patent squatters" is um, hurting my business, stop using it NOW or you will be hearing from my lawyer (and he's jooish)
--
* Was that loud enough?
With this volume management software they're talking about, everything's loud enough wooot!
Contracting VISA in a hospital after a drunken accident? Priceless! For everything else, there's mastercard.
have you ever felt for anyone???
No, that could spray infectious blood everywhere, torching is probably better.
"And allowing proprietary stuff into the kernel solves *what* problems exactly?"
Slow frame rate with opengl/games?
Seriously, unless you've developed the driver -yourself-, what difference does it make whether it's proprietary or not?
My nvidia drivers have never let me down, I'm tired of the slashdot attitude of "omg but they could!" just because the source isn't available to jerk off over.
Then how do you talk to that, without a driver?
Also, bugs will need firmware updates then, which by their nature are far riskier than driver updates.
Careful, microkernels are the leading cause of smug... if all that smug combines with the smug from clooney's acceptance speech... disaster!
My parents car once crashed. No, I don't mean a collision, the software locked up. This stopped (amongst other things) the electric doors (the middle one's) and windows (all of them) from working. No reset button. Had to disconnect the battery, then take it to get patched. Kinda unnerving.
"for two processes to communicate over a normal serial socket they do it one byte at a time"
I don't believe this is true. There'll be a maximum limit (which I recently hit myself, so you have to fragment large amount of data, but I forget what the limit I hit was), but moving data one byte at a time would be incredibly inefficient, I can't see it happened often at all. I guess the actual mechanism is that you send the length of your message as a (couple?) of bytes, followed by the message itself. The other end will read the length, and then read that many bytes of actual message.
"One process strill has to request and or accept a socket from another"
What you're I think talking about is zero-copy messaging, and is used in some places when you are moving pages at a time, and when the sender no longer needs the buffer/memory that the message is placed in. One useful place this can happen is passing packets along the network stack, when it's a case of "read, figure where it's to go, and pass it on... then read the next one".
Often though, copying is needed, as you may need to change stuff in the buffer, but need to make sure the reciever had the version before you carried on changing it.
I think you need to read the post you replied to again, especially how the second sentence (beginning "Everything") changes the meaning of the first sentence, which you replied to as if the second one wasn't even there.
"But you type in all caps, so you must be right"
/before/ that: the domain registration matches up ... which means it is shown that there is no seperate "they" to intercept login details to begin with. Leaving aside that it's not run by man eating elephants, going to the website could mean you get eaten up by man eating elephants!!!
You have a cause there, and an effect, but unfortunately you've got the two mixed up, which is a classic sign of low serotonin levels, you might wanna check up on that. And of cause I could just respond with something like "but you pointed out that I typed ~10% of my words in caps, so you must be right", but I think when you address the format of a response rather than the response itself, credability becomes hard to retain. (Yes I am aware of mine slipping quickly away too, I just fancied a quick head-up-my-arse response, get it out of my system, I'll be back to normal again after, as long as no one says anything stupider).
As much as you say what the reply was to, the message that was replied to had
Okay I'll stop now.
(and yes I have apologised to him for the harshness of my response)
Then I apologise for the harshness of my post, it was in response to several people's posts, unfortunately it got attached to yours, slashdot seems to breed frustration *lol*
This is NOT how a domain registration lookup (a "whois") works!!!
Why don't you read the post first that you're replying to, and then UNDERSTAND WHAT IT SAYS before typing a response.
Hint: The whois record comes from the domain registrar, not the website you're "logging in" to.
"Nvidias unwillingness to simply document their product"
Simply? Are we talking about the same product line here? Leading edge highly competitive constantly pushing the boundaries through advanced hardware and software optimisation graphics renderers? And you want them to "simply" document them... all...?
Sorry but I'd rather leave it to the people who are employed to be skilled in building them. Nvidia/ATI have pretty much left everyone else behind with their graphics processors, if no one's come close to designing better hardware, why the hell would you wanna put a super fast graphics card in the hands of hobbiest driver writers? Could they really do a better job?
Their windows drivers are closed source, but I expect them to work. I also /do/ expect the nvidia linux drivers to work, because... they do!
Sure, nvidia "might not" keep the drivers up to date with all the linux kernel side changes that are going on, but they "might not" with windows as well... but they do, so their customers can use their product.
Okay, this weeks drivers might not work with next weeks kernel, but this is a problem with the linux kernel not having the same backwards compatibility as windows. Can hardly blaim nvidia for that.
It's so not as big a deal as everyone keeps making out.
so would someone who's prejudiced against the Ever model of robots be called Everist?
It's the second name, I guess like it's supposed to be the "second" android, god knows what the submitter was on. It was made out of spare parts from the first one.
Or this?
http://www.cdli.ca/CITE/r_alpha.gif
So something like the Viking Runic alphabet? They used all straight lines, but for a different reason (OCR hadn't been invented then) - their writing implement was usually something like a knife on stone or wood.
"Main issue to remember is that computers process in numbers, not letters, to completely solve this issue, we'd need a language that's completely based on numbers"
I don't know how you've reached that conclusion, there's actually not that much difference between numbers and letters to a computer - both have binary values. The only reason a computer might be able to recognise digits 0-9 easier than also including A-Z, is that there are less glyphs to recognise in the alphabet. All you'd by doing by writing down numbers instead of letters is changing the set of patterns it's trying to recognise.
Numbers would also be easier to recognise than say, joined hand writing, as it's obvious what's part of each digit, with joined it's harder to tell if a line is part of the first character, the second, or if it's just part of the link between the two.
So, block capitals?
You get quite a performance hit with FUSE though, although this isn't a problem with "slow" filesystems (eg, sftp, googlefs interfaces) where most of the time is spent waiting for data to be sent/recieved, with local high performance filesystems the hit is more than noticable. Unfortunately the faster code runs, the greater the chance-per-second a bug will cause a problem.
Doesn't everybody already?
"If a child is defined as anyone under 35, the figure is a staggering 95%"
-- brasseye on paedophilia statistics