And, obviously, none of his buyers ever got addicted, and none have ever died due to their addiction (whether in school or later in life). I have a problem with believing that, but maybe you wanted to say something else:)
That's exactly the right way of doing it. Alas, teachers are not just some random interviewees. They are supposed to know better. Those who don't, don't have to teach.
That's fine and dandy at work, but at school the teachers are actually supposed to be above average in their social skills as well as their educator skills. Well, that's in my set of good teacher requirements, at least. If the teacher gets upset about being wrong and being called on it, they shouldn't be teaching. Plain and simple.
I think I have zero tolerance for such behavior in teachers at any level. If someone tried to pull that one on me, I'd have no problem making them miserable until they apologized. They'd have had it coming.
How the fuck is it being selfish and inconsiderate to realize that yes, the bullies are often inferior dumbasses. Stating the obvious doesn't make you any less humble. World is full of useless people, get over it.
That's pretty much what my mother always says: nobody really gives a shit if you started walking at 9 months of age and talking full sentences at 15. Same goes for K-12 grades. As an employer I certainly wouldn't give a damn.
Well, crossover has been hard at work at implementing DirectX-on-OpenGL for quite a while, and it works quite decently. Most bugs are at the interface between DirectX and other parts of Windows, especially legacy APIs.
Well, the sentence "DNA is never a 100% match" is really meaningless. What is being tested, usually, are some markers present in the DNA -- it's like taking a hash of a very small fragment of the file (the genome). Once you have a suspect, you can the do some sequencing and do much better comparisons where it's then out of the question that the DNA is from given person (or his/her genetic twin). I agree it still shouldn't make you anything more than a suspect, though, and must be insufficient on its own for any conviction other than a misdemeanor IMHO.
It must be understood that DNA tests are not comparisons of the entirety of the genome. They are just hashes, and very low bit-count hashes at that (16 to 24 bits I'd think). Worse yet, they are not hashes of the entire genome, just of small parts of it. Feel free to correct me if I'm wrong, of course.
Those "DNA matches" are not. AFAIK, what's matched a very tiny amount of information from the DNA. I figure there may be a reasonable probability that when you've got so many volunteers, there will be a "100%" match. I don't know what kind of "matching" they are using, of course, so feel free to correct me if I'm totally off-base.
There isn't a single resource that I know of. There are very few things you really need to appreciate.
First: every time you read anything from an I/O device, if you haven't been woken up by said device telling you that data is ready, you'll be blocking on the read call, and this makes your thread unresponsive to anything else. Be mindful that some reads are implied. For example, when you memory-map a file, a simple pointer dereference can take tens or hundreds of milliseconds as the hard drive performs a read that's then written to the memory page pointed to by your pointer. This means, unfortunately, that anything that communicates needs to be written explicitly as a state machine of some sort. You can't have simple, linear-flow code where reads are interspersed with processing of stuff. Simple things become, quickly, human unreadable. You'd be well served by at least some ad-hoc tool to rewrite linear code into state machines -- no, it doesn't need to have a full-blown C parser or anywhere near it.
Second: there's little point to having an abundance of threads, your code should be flexible so as to work with any number of worker threads. Such threads should be created on application startup, their number equivalent to the number of cores or hyperthreads available on the machine that you run on. There is a limited number of situations where you can't escape the abundance of threads model. Those are, universally, when you face stupidly written libraries whose code internally blocks. Almost all database APIs are written that way. Now there is a reason why many libraries are done so, and that's because otherwise they'd need to use a higher level framework to abstract away doing event loops on various OSes. Qt provides this functionality, as do various other C/C++ frameworks, as does, in more than one way, the.net platform.
You may want to read Miro Samek's articles on run-to-completion tasks and state machines. Google is your friend.
Context switches are expensive, but that's not the reason for Linux's or NT's architecture. They do plenty of context switches, these days more switches than just 15 years ago, in fact. Most drivers, these days, do minimum amount of processing in interrupt handlers and leave the rest for the bottom halves. That's often an extra pair of context switches per each interrupt, right there:)
You demonstrably have no clue about OS design, or even design of embedded software. The despicable multitasking you claim is so bad, if absent from the OS, will be badly reimplemented by everyone and their mother because the world we live in is full of asynchronous events. Any kernel worth its salt will multitask, even if all the tasks are lightweight run-to-completion tasks. There's no way around it. Interrupt handlers do preemptive multitasking, if you haven't noticed it yet. Even Windows 2 did cooperative multitasking for userland code, and preemptive stuff in the "kernel".
Any sort of a communications or driver stack that's more than a minimalistic proof-of-concept will have to multitask. Multitask as in interrupt handlers doing the minimum necessary amount of work so as not to unduly impact the overall interrupt latency of the system. Then normally scheduled bottom half tasklets finish up the work. You need this for USB, for networking, for really anything you can think of. Without solid scheduling and task preemption, you're doomed. Implementing most communication protocols becomes rather easy once you have interrupts, tasklets and timers.
As for those "annoying things" you claim your Android phone does, they happen precisely because things are *not* properly coded for asynchronous execution. Things get slow, almost universally, when something somewhere blocks, or worse, busy-waits (spins). It's rather unfortunate that neither C nor C++ really facilitates writing well performing software that's able to react to asynchronous events. Writing state machines explicitly with each state being a function/method or even a select case is a pain. You'd think it'd be a well solved problem by now, but it's not, and developers being what they are, you see plenty of applications that present you with busy cursors with no CPU nor I/O load to back it up. That's blocking behavior, and it's there because it's somewhat hard to write code otherwise. Every example code out there for receiving data from any device (serial port, network, etc). is fundamentally wrong and contributes to the problem:
send("foo");
read(buf);
if (buf == "bar") {... };
For your console to do your "one thing at a time" well, it must do a hundred things in parallel behind the scenes. It's your lack of appreciation of this simple fact that makes your post an uninformed rant.
I don't quite see, on a dedicated Linux system, how running anything in the kernel will improve things. The code still executes on the same CPU, same caches, etc. If the kernel includes broken drivers that disable interrupts for a long time (like the utter garbage USB device drivers for Raspberry PI), then whether you're in the kernel or outside, low latencies go out the window. As long as you don't include drivers written by people who have no clue, you'll be perfectly fine in the userland. Especially if you're the only process running at that time. I'm prototyping some rather low-end userspace PLC systems, and the userland performance is quite phenomenal if you're the sole process and are only using Ethernet communications (no USB). You can easily run cyclic tasks at 10kHz, and it's rock solid in performance.
[Rant: No USB device driver has to block on anything. Ever. No exceptions. If you think otherwise, you're dumb, and I mean it.]
Man, if you get that many court summonses in the mail, you've got worse problems I guess. I get government communications a couple of times a year, and some of it is really junk that they wouldn't bother sending if it cost them. BTW, you really don't have to overnight stuff, sending a letter via ground service even to nowhere, U.S., usually costs well under $20.
Well, guess what. A pension is part of your compensation, just deferred. That's all there's to it. You've earned it while you worked, you just get paid later. How can this be equated with paying people not to work is beyond me. You're silly.
They are allowed to deliver it, just not to mailboxes marked U.S. Mail. Well, nobody but USPS is allowed to do that. Technically, your kid dropping off a handwritten love letter in his/her beau's mailbox is breaking federal law:(
Slashdot Mirror
And, obviously, none of his buyers ever got addicted, and none have ever died due to their addiction (whether in school or later in life). I have a problem with believing that, but maybe you wanted to say something else :)
That's exactly the right way of doing it. Alas, teachers are not just some random interviewees. They are supposed to know better. Those who don't, don't have to teach.
That's fine and dandy at work, but at school the teachers are actually supposed to be above average in their social skills as well as their educator skills. Well, that's in my set of good teacher requirements, at least. If the teacher gets upset about being wrong and being called on it, they shouldn't be teaching. Plain and simple.
I think I have zero tolerance for such behavior in teachers at any level. If someone tried to pull that one on me, I'd have no problem making them miserable until they apologized. They'd have had it coming.
+5 insightful. And what a story!
That Panthers girl story made my day. Thanks, hairyfeet!
How the fuck is it being selfish and inconsiderate to realize that yes, the bullies are often inferior dumbasses. Stating the obvious doesn't make you any less humble. World is full of useless people, get over it.
That's pretty much what my mother always says: nobody really gives a shit if you started walking at 9 months of age and talking full sentences at 15. Same goes for K-12 grades. As an employer I certainly wouldn't give a damn.
Well, crossover has been hard at work at implementing DirectX-on-OpenGL for quite a while, and it works quite decently. Most bugs are at the interface between DirectX and other parts of Windows, especially legacy APIs.
Well, the sentence "DNA is never a 100% match" is really meaningless. What is being tested, usually, are some markers present in the DNA -- it's like taking a hash of a very small fragment of the file (the genome). Once you have a suspect, you can the do some sequencing and do much better comparisons where it's then out of the question that the DNA is from given person (or his/her genetic twin). I agree it still shouldn't make you anything more than a suspect, though, and must be insufficient on its own for any conviction other than a misdemeanor IMHO.
It must be understood that DNA tests are not comparisons of the entirety of the genome. They are just hashes, and very low bit-count hashes at that (16 to 24 bits I'd think). Worse yet, they are not hashes of the entire genome, just of small parts of it. Feel free to correct me if I'm wrong, of course.
You mean, like they don't give a fuck in France these days, for example?
Those "DNA matches" are not. AFAIK, what's matched a very tiny amount of information from the DNA. I figure there may be a reasonable probability that when you've got so many volunteers, there will be a "100%" match. I don't know what kind of "matching" they are using, of course, so feel free to correct me if I'm totally off-base.
There isn't a single resource that I know of. There are very few things you really need to appreciate.
First: every time you read anything from an I/O device, if you haven't been woken up by said device telling you that data is ready, you'll be blocking on the read call, and this makes your thread unresponsive to anything else. Be mindful that some reads are implied. For example, when you memory-map a file, a simple pointer dereference can take tens or hundreds of milliseconds as the hard drive performs a read that's then written to the memory page pointed to by your pointer. This means, unfortunately, that anything that communicates needs to be written explicitly as a state machine of some sort. You can't have simple, linear-flow code where reads are interspersed with processing of stuff. Simple things become, quickly, human unreadable. You'd be well served by at least some ad-hoc tool to rewrite linear code into state machines -- no, it doesn't need to have a full-blown C parser or anywhere near it.
Second: there's little point to having an abundance of threads, your code should be flexible so as to work with any number of worker threads. Such threads should be created on application startup, their number equivalent to the number of cores or hyperthreads available on the machine that you run on. There is a limited number of situations where you can't escape the abundance of threads model. Those are, universally, when you face stupidly written libraries whose code internally blocks. Almost all database APIs are written that way. Now there is a reason why many libraries are done so, and that's because otherwise they'd need to use a higher level framework to abstract away doing event loops on various OSes. Qt provides this functionality, as do various other C/C++ frameworks, as does, in more than one way, the .net platform.
You may want to read Miro Samek's articles on run-to-completion tasks and state machines. Google is your friend.
Context switches are expensive, but that's not the reason for Linux's or NT's architecture. They do plenty of context switches, these days more switches than just 15 years ago, in fact. Most drivers, these days, do minimum amount of processing in interrupt handlers and leave the rest for the bottom halves. That's often an extra pair of context switches per each interrupt, right there :)
You demonstrably have no clue about OS design, or even design of embedded software. The despicable multitasking you claim is so bad, if absent from the OS, will be badly reimplemented by everyone and their mother because the world we live in is full of asynchronous events. Any kernel worth its salt will multitask, even if all the tasks are lightweight run-to-completion tasks. There's no way around it. Interrupt handlers do preemptive multitasking, if you haven't noticed it yet. Even Windows 2 did cooperative multitasking for userland code, and preemptive stuff in the "kernel".
Any sort of a communications or driver stack that's more than a minimalistic proof-of-concept will have to multitask. Multitask as in interrupt handlers doing the minimum necessary amount of work so as not to unduly impact the overall interrupt latency of the system. Then normally scheduled bottom half tasklets finish up the work. You need this for USB, for networking, for really anything you can think of. Without solid scheduling and task preemption, you're doomed. Implementing most communication protocols becomes rather easy once you have interrupts, tasklets and timers.
As for those "annoying things" you claim your Android phone does, they happen precisely because things are *not* properly coded for asynchronous execution. Things get slow, almost universally, when something somewhere blocks, or worse, busy-waits (spins). It's rather unfortunate that neither C nor C++ really facilitates writing well performing software that's able to react to asynchronous events. Writing state machines explicitly with each state being a function/method or even a select case is a pain. You'd think it'd be a well solved problem by now, but it's not, and developers being what they are, you see plenty of applications that present you with busy cursors with no CPU nor I/O load to back it up. That's blocking behavior, and it's there because it's somewhat hard to write code otherwise. Every example code out there for receiving data from any device (serial port, network, etc). is fundamentally wrong and contributes to the problem:
send("foo"); ... };
read(buf);
if (buf == "bar") {
For your console to do your "one thing at a time" well, it must do a hundred things in parallel behind the scenes. It's your lack of appreciation of this simple fact that makes your post an uninformed rant.
I don't quite see, on a dedicated Linux system, how running anything in the kernel will improve things. The code still executes on the same CPU, same caches, etc. If the kernel includes broken drivers that disable interrupts for a long time (like the utter garbage USB device drivers for Raspberry PI), then whether you're in the kernel or outside, low latencies go out the window. As long as you don't include drivers written by people who have no clue, you'll be perfectly fine in the userland. Especially if you're the only process running at that time. I'm prototyping some rather low-end userspace PLC systems, and the userland performance is quite phenomenal if you're the sole process and are only using Ethernet communications (no USB). You can easily run cyclic tasks at 10kHz, and it's rock solid in performance.
[Rant: No USB device driver has to block on anything. Ever. No exceptions. If you think otherwise, you're dumb, and I mean it.]
:)
Thanks, that was informative. It turns out the love letter would have been legal, after all :)
Man, if you get that many court summonses in the mail, you've got worse problems I guess. I get government communications a couple of times a year, and some of it is really junk that they wouldn't bother sending if it cost them. BTW, you really don't have to overnight stuff, sending a letter via ground service even to nowhere, U.S., usually costs well under $20.
Can't you access your utility account electronically? It's 2012, after all...
Well, guess what. A pension is part of your compensation, just deferred. That's all there's to it. You've earned it while you worked, you just get paid later. How can this be equated with paying people not to work is beyond me. You're silly.
Ta-da we have a winner.
Not if you use their Ground service. For $20 you can ship a couple kilograms across the country. That's one heck of a letter you have in mind.
They are allowed to deliver it, just not to mailboxes marked U.S. Mail. Well, nobody but USPS is allowed to do that. Technically, your kid dropping off a handwritten love letter in his/her beau's mailbox is breaking federal law :(