At least all the unvaccinated kids would be confined to a ghetto, of sorts. Maybe more outbreaks (and, consequently, more dead kids) would motivate more parents to vaccinate.
Why? It's not like infections only happen in schools. Or that students spend 100% of their time at school. Look at the Disneyland outbreak.
The main reason to require vaccination in public schools is that they're a resource that's supposedly available to everyone. I shouldn't have to expose my kid to other kids who haven't been vaccinated in order to access the public school system. So we require vaccinations there. Private schools are private. That's why you can send your kid to a school that teaches young earth creationism if you want. Likewise, you could elect to send your kid to a school that doesn't require vaccinations. I would support a reporting requirement, though, obligating private schools to publicize in their promotional materials whether they allow un-vaccinated students to enroll. That way parents can make an informed decision.
I think that you are under the impression that it is ONLY transmitted via sex or needles.
Not really. It's transmitted by blood, or bodily fluids containing blood. That can happen without sex or needles but, outside of mother-to-child transmission during delivery, its more rare. I would be much less concerned about sending my kids to a school where some of the students weren't vaccinated against HepB than I would be about sending my kids to a school where some of the students weren't vaccinated against measles, mumps, rubella, pertussis, etc.
Primarily from mother to child during delivery. The likelihood of an child who hasn't been vaccinated both 1) contracting HepB and 2) passing it to someone else at school are fairly low. Much lower than, say, measles.
I'm cool with the public schools only admitting kids who're vaccinated. Imposing the same approach on private schools seems like overreach. Also, HepB shouldn't be in the schedule of required vaccines to enter kindergarten given its method of transmission.
I've steamed movies over this DSL connection. On a laptop. Point being: not everybody streams HD movies. You seem to want to define "broadband" as "what it takes to adequately stream HD content". That seems like a somewhat arbitrary way to define "broadband".
1. The FCC should establish a "moving definition". Identify a set of peer countries and define U.S. "broadband" relative to some measure of those countries' broadband capability. Maybe "broadband" is "just faster than the slowest peer nation". Or maybe it's "the median among all peer nations". Etc. Revise the standard yearly according to the moving definition.
2. To what extent is Sweden's network access made cheaper by way of public subsidy? The amount of the subsidy should be included in the "price", even if it's less visible.
3. Not everybody streams HD video. If you don't stream HD video then 25/3 is more than adequate. I watch TV shows from Hulu on my laptop over a 6 Mbps DSL connection.
I agree. LoC needed to implement Hello World is a dumb metric. Even by that dumb metric, though, he exaggerates, since the number needed in Java is 6 and not 50.
Huh. I thought the whole "community" aspect w/ Java allowed for more non-Oracle input into the development of the language, whereas VB and C# were tightly controlled by MS. If you're cynical you could view Java as being tightly controlled by the triumvirate of IBM, Google and Oracle. I agree you can find a job doing.Net, but I'd still argue if you had to choose between the two (C# and Java) then Java is probably the better choice of the two (if only because it potentially opens up Android positions and there are many more Android positions than Windows Mobile).
If I were designing an undergraduate C.S. curriculum I'd want students exposed to Java, C, Python and SQL (arguably not really a "programming" language). C# would be a bonus. Probably also some functional language (Scheme, Lisp) just so they leave with a sense of what those languages are like. If I were designing a high school curriculum and had to choose a single language to teach, given the present realities of university curricula and industry adoption, I'd go with Java.
I've used Ruby and Java and, honestly, I prefer Java. But I recognize I'm an outlier in that respect.
C#/VB + Mono gets you additional platform support, but not quite as robust as the situation with Java. Also, despite Mono, isn't the "spec" for VB tied to Microsoft in a way that exceeds Java's link to Oracle?
C# and VB (especially VB) are also not as popular in industry. So Java has that advantage over those two. Nor are they what's commonly used in intro courses at universities which, IMO, should be a factor in deciding what to teach pre-university students.
Java. It has the broadest popularity in industry, isn't tied to any one company (e.g. Microsoft), can be developed using a wide variety of host operating systems (Windows, Mac, Linux), lends itself well to teaching O.O. design and has a wealth of free tools. It's also what the majority of universities use in their intro level courses. (Though that's changing.)
It currently doesn't, but BSD's code could make the same guarantee, right? At the point where it recurses left and right, compare the length of the two sub-arrays. Sort the shorter one first via a recursive call, then take advantage of the tail recursion and sort the larger one by overwriting the current stack frame and jumping back to the top of the function. They already go halfway (taking advantage of the tail recursion); they just don't use any heuristic to choose which sub-array gets sorted via the recursive call. It's always the "left" side.
It looks like GNU actually allocates its custom stack *on the stack*. However, in the comments they claim their algorithm guarantees that the stack need only be as large as log(sort elements), so they allocate a stack that is (in theory) guaranteed to be big enough. You can check out the code here. I'm not sure what version of glibc that's from, but it looks similar to what I extracted from 2.10 a while back.
It should be noted that since both BSD and GNU versions rely on a stack (and neither chooses its pivot point randomly, so far as I know) they're both vulnerable to crafted data that's designed to cause the algorithm to exhaust its stack. It's possible GNU dynamically grows its custom stack when it nears the point of exhaustion, but I kind of doubt it.
They use the method described in Bentley & McIlroy's paper, which uses a "median of medians" for large arrays, a simple median of first/last/middle for mid-sized arrays and the mid-point for small arrays. See page 1255 here. No idea how effective that is. They also short-circuit to insertion sort when N 7 for a given sort window.
So your current salary is approximately 2x what you started at 10 years ago (i.e. 1.07^10)? Nice. I'm 15.5 years into my career since graduating with a M.S. If my salary 15 years ago is what I think it was (am having trouble remembering) then I'm averaging only 5%/year. It's possible that the yearly increase is steeper during the first 10 years than in the next 10. Then again, maybe I'm just consoling myself.:)
Agreed. It would be interesting to know the smallest number of crafted sort elements needed to cause BSD's qsort() to exceed a "normal" stack size, whatever that happens to be. If an array with that number of elements and a reasonable element size (probably sizeof(void*) since elements are almost always pointers) will always be larger than the largest system memory size then, in theory, we wouldn't need to worry about exceeding the available call stack.
It may be the case, though, that it is possible to fit a crafted sequence of keys into a reasonable amount of space that will cause BSD qsort() to exceed a "normal" stack size.
How many of those apps are simply re-branded versions of some core you wrote?
All of them. The company couldn't exist if we had to code up a unique app for every customer. My point is that the fact of there being "lots of apps in the store" doesn't mean the number of app "producers" is correspondingly large. I thought I made that clear when I said, "it's not quite a 1-1 from app to company".
This is just one data point, but I recently compared the BSD and GNU qsort() code. Built both with LLVM (on a Mac), tried both -O2 and -O3, and did some crude benchmarking. IIRC the BSD code was slightly more efficient, not to mention drastically simpler. BSD basically uses the Bentley & McIlroy code from "Engineering a Sort Function" with a few small optimizations to make it more adaptive (and exploit the fact that the algorithm is tail-recursive). So the BSD version is still recursive, whereas GNU is non-recursive but manages its own stack.
Yes. I imagine the skill set for low-level video game testers is pretty minimal, and they have a built-in advantage because so many (IMO foolish) people are disproportionately interested in "video game testing" compared to other things they could be doing with their time. I live in Austin, by the way. You can easily get $10 at many high-end fast food places (e.g. Rudy's BBQ). You can undoubtedly make more than $16/hr if you can successfully transition from "video game tester" to "QA Engineer" and get out of the gaming industry. But you'd have to be more than a random-button-pusher. Writing test plans, QA automation, etc.
That changes the equation somewhat, I agree. Some thoughts:
1. Moving cross-country to take a $16/hr job when you have no savings is somewhat risky, as your friend found out. How much could he have made in CA if he hadn't moved? How much did the initial move from California to Texas cost? If it cost $1000 to move one-way and he was able to earn $3/hr more (after taxes) than in CA then he would have recouped the cost of his move (round-trip) in 4 months time.
2. If he was able to earn more in Texas than in CA then I'm going to assume the job prospects for his skill set were superior in Texas. So even after he lost the initial job he was still better positioned in Texas than in CA.
3. The person making $16/hr probably doesn't need a 20ft U-Haul trailer. If he didn't have furniture (or was willing to sell and re-buy after the move) and had a reasonable car then 1750 miles / 20mpg * $2/gallon = $175. That's a much cheaper move.
Slashdot Mirror
At least all the unvaccinated kids would be confined to a ghetto, of sorts. Maybe more outbreaks (and, consequently, more dead kids) would motivate more parents to vaccinate.
The main reason to require vaccination in public schools is that they're a resource that's supposedly available to everyone. I shouldn't have to expose my kid to other kids who haven't been vaccinated in order to access the public school system. So we require vaccinations there. Private schools are private. That's why you can send your kid to a school that teaches young earth creationism if you want. Likewise, you could elect to send your kid to a school that doesn't require vaccinations. I would support a reporting requirement, though, obligating private schools to publicize in their promotional materials whether they allow un-vaccinated students to enroll. That way parents can make an informed decision.
Not really. It's transmitted by blood, or bodily fluids containing blood. That can happen without sex or needles but, outside of mother-to-child transmission during delivery, its more rare. I would be much less concerned about sending my kids to a school where some of the students weren't vaccinated against HepB than I would be about sending my kids to a school where some of the students weren't vaccinated against measles, mumps, rubella, pertussis, etc.
Primarily from mother to child during delivery. The likelihood of an child who hasn't been vaccinated both 1) contracting HepB and 2) passing it to someone else at school are fairly low. Much lower than, say, measles.
I'm cool with the public schools only admitting kids who're vaccinated. Imposing the same approach on private schools seems like overreach. Also, HepB shouldn't be in the schedule of required vaccines to enter kindergarten given its method of transmission.
Make fewer claims in order to drive down the % that end up having to be reversed.
Redbox, coupled with Netflix's service where they mail you the discs.
I've steamed movies over this DSL connection. On a laptop. Point being: not everybody streams HD movies. You seem to want to define "broadband" as "what it takes to adequately stream HD content". That seems like a somewhat arbitrary way to define "broadband".
1. The FCC should establish a "moving definition". Identify a set of peer countries and define U.S. "broadband" relative to some measure of those countries' broadband capability. Maybe "broadband" is "just faster than the slowest peer nation". Or maybe it's "the median among all peer nations". Etc. Revise the standard yearly according to the moving definition.
2. To what extent is Sweden's network access made cheaper by way of public subsidy? The amount of the subsidy should be included in the "price", even if it's less visible.
3. Not everybody streams HD video. If you don't stream HD video then 25/3 is more than adequate. I watch TV shows from Hulu on my laptop over a 6 Mbps DSL connection.
I agree. LoC needed to implement Hello World is a dumb metric. Even by that dumb metric, though, he exaggerates, since the number needed in Java is 6 and not 50.
Huh. I thought the whole "community" aspect w/ Java allowed for more non-Oracle input into the development of the language, whereas VB and C# were tightly controlled by MS. If you're cynical you could view Java as being tightly controlled by the triumvirate of IBM, Google and Oracle. I agree you can find a job doing .Net, but I'd still argue if you had to choose between the two (C# and Java) then Java is probably the better choice of the two (if only because it potentially opens up Android positions and there are many more Android positions than Windows Mobile).
If I were designing an undergraduate C.S. curriculum I'd want students exposed to Java, C, Python and SQL (arguably not really a "programming" language). C# would be a bonus. Probably also some functional language (Scheme, Lisp) just so they leave with a sense of what those languages are like. If I were designing a high school curriculum and had to choose a single language to teach, given the present realities of university curricula and industry adoption, I'd go with Java.
Google would seem to disagree.
False.
Exagerration. Hello World in Java is about six non-empty lines, i.e. on par with C.
I've used Ruby and Java and, honestly, I prefer Java. But I recognize I'm an outlier in that respect. C#/VB + Mono gets you additional platform support, but not quite as robust as the situation with Java. Also, despite Mono, isn't the "spec" for VB tied to Microsoft in a way that exceeds Java's link to Oracle? C# and VB (especially VB) are also not as popular in industry. So Java has that advantage over those two. Nor are they what's commonly used in intro courses at universities which, IMO, should be a factor in deciding what to teach pre-university students.
Java. It has the broadest popularity in industry, isn't tied to any one company (e.g. Microsoft), can be developed using a wide variety of host operating systems (Windows, Mac, Linux), lends itself well to teaching O.O. design and has a wealth of free tools. It's also what the majority of universities use in their intro level courses. (Though that's changing.)
Fewer features in each release. More time to fix bugs, test, "get it right the first time".
It currently doesn't, but BSD's code could make the same guarantee, right? At the point where it recurses left and right, compare the length of the two sub-arrays. Sort the shorter one first via a recursive call, then take advantage of the tail recursion and sort the larger one by overwriting the current stack frame and jumping back to the top of the function. They already go halfway (taking advantage of the tail recursion); they just don't use any heuristic to choose which sub-array gets sorted via the recursive call. It's always the "left" side.
It looks like GNU actually allocates its custom stack *on the stack*. However, in the comments they claim their algorithm guarantees that the stack need only be as large as log(sort elements), so they allocate a stack that is (in theory) guaranteed to be big enough. You can check out the code here. I'm not sure what version of glibc that's from, but it looks similar to what I extracted from 2.10 a while back.
It should be noted that since both BSD and GNU versions rely on a stack (and neither chooses its pivot point randomly, so far as I know) they're both vulnerable to crafted data that's designed to cause the algorithm to exhaust its stack. It's possible GNU dynamically grows its custom stack when it nears the point of exhaustion, but I kind of doubt it.
Slasdot ate my less-than symbol. They short-circuit to insertion when N < 7.
They use the method described in Bentley & McIlroy's paper, which uses a "median of medians" for large arrays, a simple median of first/last/middle for mid-sized arrays and the mid-point for small arrays. See page 1255 here. No idea how effective that is. They also short-circuit to insertion sort when N 7 for a given sort window.
So your current salary is approximately 2x what you started at 10 years ago (i.e. 1.07^10)? Nice. I'm 15.5 years into my career since graduating with a M.S. If my salary 15 years ago is what I think it was (am having trouble remembering) then I'm averaging only 5%/year. It's possible that the yearly increase is steeper during the first 10 years than in the next 10. Then again, maybe I'm just consoling myself. :)
Agreed. It would be interesting to know the smallest number of crafted sort elements needed to cause BSD's qsort() to exceed a "normal" stack size, whatever that happens to be. If an array with that number of elements and a reasonable element size (probably sizeof(void*) since elements are almost always pointers) will always be larger than the largest system memory size then, in theory, we wouldn't need to worry about exceeding the available call stack.
It may be the case, though, that it is possible to fit a crafted sequence of keys into a reasonable amount of space that will cause BSD qsort() to exceed a "normal" stack size.
All of them. The company couldn't exist if we had to code up a unique app for every customer. My point is that the fact of there being "lots of apps in the store" doesn't mean the number of app "producers" is correspondingly large. I thought I made that clear when I said, "it's not quite a 1-1 from app to company".
This is just one data point, but I recently compared the BSD and GNU qsort() code. Built both with LLVM (on a Mac), tried both -O2 and -O3, and did some crude benchmarking. IIRC the BSD code was slightly more efficient, not to mention drastically simpler. BSD basically uses the Bentley & McIlroy code from "Engineering a Sort Function" with a few small optimizations to make it more adaptive (and exploit the fact that the algorithm is tail-recursive). So the BSD version is still recursive, whereas GNU is non-recursive but manages its own stack.
Yes. I imagine the skill set for low-level video game testers is pretty minimal, and they have a built-in advantage because so many (IMO foolish) people are disproportionately interested in "video game testing" compared to other things they could be doing with their time. I live in Austin, by the way. You can easily get $10 at many high-end fast food places (e.g. Rudy's BBQ). You can undoubtedly make more than $16/hr if you can successfully transition from "video game tester" to "QA Engineer" and get out of the gaming industry. But you'd have to be more than a random-button-pusher. Writing test plans, QA automation, etc.
That changes the equation somewhat, I agree. Some thoughts:
1. Moving cross-country to take a $16/hr job when you have no savings is somewhat risky, as your friend found out. How much could he have made in CA if he hadn't moved? How much did the initial move from California to Texas cost? If it cost $1000 to move one-way and he was able to earn $3/hr more (after taxes) than in CA then he would have recouped the cost of his move (round-trip) in 4 months time.
2. If he was able to earn more in Texas than in CA then I'm going to assume the job prospects for his skill set were superior in Texas. So even after he lost the initial job he was still better positioned in Texas than in CA.
3. The person making $16/hr probably doesn't need a 20ft U-Haul trailer. If he didn't have furniture (or was willing to sell and re-buy after the move) and had a reasonable car then 1750 miles / 20mpg * $2/gallon = $175. That's a much cheaper move.