Obviously, selling bottled air is a 'good idea' if you can get people to buy it; but what possible sense does that make as a strategy for coping with pollution?
As a glance at the scuba gear aisle shows, the equipment needed to actually bottle useful amounts of air isn't trivial. You need a fairly sturdy(and thus heavy) tank to safely achieve pressures high enough to avoid ridiculous volume requirements, and then you need a regulator stage so the pressure doesn't blow your alveoli to hell.
Unless the pollutants are some truly alarming stuff, rather than just soot and miscellaneous VOCs, you'll get a lot more mileage out of lighter and less bulky filters.
"Kind of like how some refuse to shop at Walmart, Chick Fill-A, or other companies because they don't like their corporate practices."
Dubious analogy: It would be more like a restaurant critic being ordered not to praise Chick Fil-A's food because Zagat doesn't approve of them.
The story here isn't that CBS dislikes the Dish Hopper; but that the alleged 'journalists' at Cnet have neither the editorial independence nor the integrity to act in the interests of their customers instead of their owners.
Do they want Computer Science or Computer Technology, because I doubt primary children are capable of Computer Science.
Primary school children wouldn't know a Dedekind–Peano axiom if it bit them in the ass; but that doesn't stop us from teaching them things about math that are both useful in themselves and a foundation for later work...
Mac UEFI is, if anything, even weirder than the usual flavor. Apple laptops running Apple EFI in order to boot OSX work; because Apple makes all of them and none of the parts is dumb enough to lean on the other parts in an unexpected way; but once you try something different, life gets exciting(the, er, interesting transition between 32 bit and 64 bit EFI 1.x was good fun as well).
This fellow used to do EFI-related work for Redhat and is interesting reading on the matter. UEFI is a bloated bear of a 'standard', that makes ACPI look like a brutally efficient paragon of elegance, and things tend to go downhill from there once a vendor gets their sloppy hands all over it...
The BIOS interface was overdue for being updated/replaced
True. Unfortunately, UEFI was a step in the wrong direction. Yeah, the classic BIOS was older than dirt, limited, and saddled with a variety of quirks, oddities, and cruft from its years of genetic drift and backward compatibility.
However, because it sucked, there was a strong incentive not to try anything stupid with it, and to just boot the OS and GTFO. Instead of just cleaning up and rationalizing this basic firmware function, UEFI goes wildly in the opposite direction, to the point where the firmware is tantamount to a second OS; but still with all the fucked up weirdness that we know and love from BIOS features like ACPI...
It seems as though there is something badly wrong with the at least some part of the design if a bug of this flavor is possible(much less happening for reasons that even the vendor hasn't nailed down yet).
There are reasons to update/modify the firmware responsible for the first stages of the boot process; but not all that often(especially on a PC-class device, which has tons of both RAM and persistent mass storage available, this isn't some cost-reduced embedded device where the OS has to scribble configuration information in whatever bits of the teeny flash chip that also stores the bootloader).
Can anybody enlighten me as to why (outside of a BIOS update) a situation would arise where the kernel needs to scribble over the motherboard firmware, or where the firmware would be doing anything sufficiently drastic to itself based on input from the kernel that it wouldn't be recoverable?
Obviously, Boeing should simply have specified that all the contractors deliver components that accept and output plaintext, and then used pipes and awk to cobble the pieces together into a working system! What could possibly go wrong?
Given how bitterly controversial the idea that Americans really ought to have access to boring old routine healthcare is, I wouldn't be optimistic about our level of preparedness...
The turnaround time(even if you crank up your risk tolerance a bit and skip some of the approval steps) from even modestly novel pathogen to treatment/vaccine is on the order of months(something like the flu vaccine is probably the most well-oiled vaccine development and distribution operation, and even there they have to forecast the expected outbreak strain in order to have enough time to produce, distribute, and administer the result), with some diseases proving much tougher to crack.
In the meantime, the main factor determining the mortality rate, aside from the disease itself, will be the ability of your healthcare system to cope under overload conditions, your social infrastructure to cope with a heck of a lot of sick days without cascading failures, and possibly your ability to do very unpopular quarantine related things.
While there doesn't seem to be a 100% clear answer on how hard biological weapons actually are to make(nation states have definitely played with them, sometimes just by bottling wild nasties, sometimes by modification or selective breeding, amateurs don't seem to have managed much for the moment), the thing that makes 'biodefense' feel like something of a lost cause is that so much of it is a deeply unsexy(and surprisingly unpopular) mix of public health and infrastructure work.
Sure, somebody has to wear the cool positive-pressure suits and do Tense Movie Science in the biohazard level 4 labs; but if a novel strain of something for which there isn't presently a vaccine pops up, the only relevant question will be along the lines of 'do we have anything resembling the capacity to provide supportive care/any remedies that are available in a mass infection context?' The answer, of course, is 'ha, ha, are you joking? Have you seen the wait times for anything short of serious trauma at your local ER?'
That's the trouble: Barring some sort of technology-indistinguishable-from-magic(an immunological simulation powerful enough to take a pathogen's genetic sequence as input and spit out a vaccine formulation ready to hit production, or something similarly Not Available Now), your main defensive options are comparatively low-tech; but very broad based and probably quite expensive, improvements in healthcare capacity and epidemiological surveillance, combined with lots and lots of basic research in medicine(since a good bioweapon will be at least somewhat novel, you can't really target research against it, so you need to have as much as possible in terms of supportive care, general understanding of strategies for rapidly evaluating and countering novel pathogens, etc, etc.) Unfortunately, that's exactly the sort of plan that would never sell, and, since it involves spending lots of money every year against a threat that may not even show up, makes a great target every time budget time rolls around.
Why does Facebook even offer an API to developers if any time an app becomes popular they block them?
If you can get suckers to develop for a platform that you can shove them off to drown at any time, it ensures that you can buy their assets at firesale prices and face minimal challenges integrating them into your service, since they are already API compatible!
Perfectly sensible on Facebook's part, it's the sanity of the people who use the API that you have to worry about...
The soul-crushing thing about your story is that it suggests that somebody deliberately went to additional effort to build/install a telnet daemon while hacking the firmware together. That's just sick and wrong.
What, nobody has complained about this being an intentional backdoor yet? The Chinese are out to get us.
I'm inclined to keep "Never attribute to malice something much stupider than malice would have implemented" in mind as a variant on the usual phrase.
Given the hordes of profit-driven, variously political, and simply lulz-oriented attackers on the internet, relatively blatant backdooring(when you are in the privileged position of being the guys shipping the firmware, no less, hard to ask for more insider access than that) amounts to squandering an advantage. Had the units shipped with, say, a bugged sshd that is hardcoded to always allow access via keypair auth with a specific private key, it is both much more likely that nobody would ever have noticed, and that nobody but the intended attacker would ever have been able to make use of the vulnerability. A wholly unauthenticated hole, on the other hand, is an open invitation to every bot-herder and na'er-do-well on the planet to come and have a rummage through the systems, leading to much greater competition for the creator of the backdoor.
The study of history is a perfectly valid field and has some researchers and courses of study that focus specifically on technological and scientific developments. It would certainly be quite reasonable for influential software and hardware to end up being studied here, same as any other relevant developments from fire and cave-painting to the present.
CS, though, seems like an odd place to roll out history beyond the level of name-checking discovers of algorithms and the like. Much of what is historically influential is either excessively bound to its time(writing a functional business software package in assembly may be impressive; but learning that somebody did so probably won't teach you much about modern software design or even be terribly efficient at teaching the architecture they wrote it for), or sufficiently timeless as to make its historical details a matter of politeness; but not really relevance(it is a polite convention to credit the discoverer of an algorithm or the originator of a concept; but the result stands by itself).
If anything, the expectation that 'Computer Science' would include a dose of history suggests the influence of the fairly lousy state of science education(at least among people not directly on a science track): much lower level 'Science' curriculum is heavily larded with pure history because the present state of the art is too complex or fast moving(and, unfortunately, often because even the historical science is considered too mathematically intimidating and so is taught as historical anecdote instead).
1. Very few arguments apply 'without limit', and this one certainly doesn't. In broad strokes, it starts to break down once the supply of jobs available(given the narrowed definition of the labor pool) falls below the number of economic entities who need incomes(depending on the prevailing social arrangements, such entities might be individuals, nuclear families, extended families, or other). Exactly what equilibrium point is reached in practice is mostly empirical: child labor, at least outside the family, seems to have few moralists on its side and tends to significantly retard education, so it often gets the chop. Limits on working hours are another means of reducing the labor supply that has achieved broad adoption and popularity.
Restrictions on individuals within the adult population definitely exist; but tend to be carved out by much more idiosyncratic means; formally-illicit-but-common discrimination against certain groups, various professional exams and licenses, that sort of thing. Because they tend to badly fail the 'number of jobs roughly equals number of economic entities' rule, wholesale restrictions typically only achieve support if the group excluded is supposed to be a member of some already employed entity(exclusion of women, say, becomes deeply problematic if single-income families are not the ideal and the norm) or if the exclusion is from a specific profession rather than from the workforce entirely.
2. As with sellers of any other good, sellers of labor who wish to maximize their slice of the pie are striving to hit the optimal compromise between units sold and price per unit: If you simply gave labor away, you'd sure see a lot of new factories; but it wouldn't help you much. If you charge $1,000/hr, you probably won't have a job. Some number of new factories is clearly beneficial to workers; but the returns aren't unbounded: If the additional demand for labor produced by lowering its price doesn't make up for the lower price(and loss of time you could be using for other things) it isn't terribly helpful. Exactly how many factories constitutes a local optimum is, naturally, a messy empirical question.
While it is undeniable that a combination of superior machinery and fossil fuels kicked off an era of unprecedented prosperity for humans on average, there are a couple of complicating factors to consider, both boiling down to distribution issues:
The most obvious one is that child labor(since it is usually cheaper, and since children in the workforce raise the total supply of labor) tends to depress wages and reduce the slice of the industrial prosperity that accrues to the workers(especially in per-labor-hour terms). Certainly, it will generally be the case that a given household will be better off with an additional salary(especially if something prevents one or both parents from working, like being unskilled, infirm, dead, etc.); but workers as a group are better off if children are removed from the labor force, reducing labor supply and allowing children to accrue education and other human capital. Part of the "West lifted themselves out of this" process was precisely the eventual success of the working class and any allies swayed by moral sentiment in legally forcing restrictions on child labor across the board. Since, structurally, such restrictions are essentially a cartel arrangement(since any individual defector will be better off through violating the agreement; but the group as a whole wins if nobody violates it), it more or less had to be done by force of law.
Second consideration involves looking at whatever conditions in the agricultural sector are sucking so much that a ready supply of child factory workers exists. England had its 'Enclosure Movement', which helped swell the supply of impecunious urbanites. I'm less familiar with the Chinese case; but the disparity between urban and rural conditions there is pretty remarkable.
I use Tracphone as well, since it seemed to be about the cheapest option to keep a phone number alive with my minimal use habits; but I would warn the submitter not to.
Tracphone does something nonstandard with their SIMs and handset firmware. I don't know whether it is a trivial thing to hack, or serious crypto cat-and-mouse; but(at least by default) a Tracphone SIM Will. Not. Work. with anything other than one of their handsets.
Since the submitter wants to shove the SIM in a computer of some flavor, that's not going to work for him.
I assume that the fairly trivial "put some dung beetles in an enclosure covered with black paper and make your grad students poke holes matching the milky way and watch what happens" strategy didn't occur to you?
No, science is not infallible, particularly once human and institutional factors come into play; but falsifying hypotheses on animal navigation methods is hardly the most difficult challenge faced by the sciences. Want to fuck with an animal that you suspect of celestial navigation? Advanced 'planetarium' technology may be for you! Suspect pigeons of navigating with magnetic fields? Exploit natural variations in earth's magnetism or just superglue a NIB magnet to the insouciant little fucker's beak, that'll show 'im which way north is...
Oh, I don't doubt his ability to work past the interlocks, I was(attempting to, may have been unclear) contrast attacking the interlocks, which is annoying but within the capabilities of a good electronics hobbyist, with handling any more serious issues with either payload destruction or printhead fouling, which would require reworking of the mechanism to such a degree that you might as well not start with an inkjet at all, printheads are exquisitely tiny little things.
It certainly does look like his system doesn't kill its payload; but I'd be curious about whether it has fouling problems or not over time.
Fair enough. I wasn't disagreeing with you, just emphasizing that there are real-world applications, most commonly in RTS situations, where pegging the CPU is very much possible and can really ruin the game even in the presence of an otherwise adequate system.
Given that the 'default' PC configuration these days is "More CPU than you need, about half as much RAM as you really should have, a slow HDD, and integrated graphics" it isn't usually the case that being CPU-bound is your first problem; but it can bite, hard, under specific circumstances.
Aside from the ugly business of working around all the annoying interlocks that inkjets have for atypical paper feed/consumables condition/problems that exist only in their own imagination/etc. which generally stop the printer dead, regardless of how mechanically healthy it is; a problem that is annoying, but solvable with sufficient electronics hackery skill, I'd be curious to know how well biological 'inks', or any other not-formulated-for-the-purpose materials deal with the inkjet mechanism.
In piezolelectric inkjet printers, an electrically actuated piezo element provides the slight expansion necessary to shove a droplet of ink out of the nozzle. I'd assume that anything that is tolerant of small(but high frequency, a piezo head can shove out some tens of thousands of droplets per second, and at fair speed, so there are probably stresses that particularly whiny and structurally complex organic molecules can't handle) pressure waves should be fine.
However, particularly among consumer cheapies, thermal inkjets have become quite common: these use a pulse of current across a resistive element to vaporize part of the ink, the expansion of which drives the remaining ink out of the chamber and toward the target. The amount of heat is small in absolute terms(the vaporization chambers are constructed by photolithiographic techniques, to give a sense of scale; but enough heat to flash-vaporize ink is quite probably enough heat to denature common proteins and/or turn common biological materials into a layer of gooey carbon gunk that clogs the print head in short order.
Any word on whether piezo printers are best for this application, or does thermal work much better than I would naively expect?
this doesn't surprise me one bit.. the GPU does most of the heavy lifting anyway, when it comes to games
still, an i7 will show you substantial performance enhancements
It's a bit more nuanced than that: certain upgrades lean almost entirely on the GPU(say you get a fancy new monitor and want Game X to look good on a 1920x1080 or 2560x1440 instead of a 1280x1024); but you can run into situations where no CPU is really enough CPU(RTS pathfinding in games that permit a lot of units is a particularly hairy case. Supreme Commander, say, can merrily chug along at 60fps with a screen full of units cranking out idle animations; but a few hundred bots scrambling to navigate can bring your CPU to its knees.) It's certainly a less common issue than an inadequate GPU; but it can happen.
Slashdot Mirror
Obviously, selling bottled air is a 'good idea' if you can get people to buy it; but what possible sense does that make as a strategy for coping with pollution?
As a glance at the scuba gear aisle shows, the equipment needed to actually bottle useful amounts of air isn't trivial. You need a fairly sturdy(and thus heavy) tank to safely achieve pressures high enough to avoid ridiculous volume requirements, and then you need a regulator stage so the pressure doesn't blow your alveoli to hell.
Unless the pollutants are some truly alarming stuff, rather than just soot and miscellaneous VOCs, you'll get a lot more mileage out of lighter and less bulky filters.
I'm pretty sure that Cnet doesn't enjoy the feelings of vague nostalgia that a lot of the other bubble-era companies do...
"Kind of like how some refuse to shop at Walmart, Chick Fill-A, or other companies because they don't like their corporate practices."
Dubious analogy: It would be more like a restaurant critic being ordered not to praise Chick Fil-A's food because Zagat doesn't approve of them.
The story here isn't that CBS dislikes the Dish Hopper; but that the alleged 'journalists' at Cnet have neither the editorial independence nor the integrity to act in the interests of their customers instead of their owners.
Do they want Computer Science or Computer Technology, because I doubt primary children are capable of Computer Science.
Primary school children wouldn't know a Dedekind–Peano axiom if it bit them in the ass; but that doesn't stop us from teaching them things about math that are both useful in themselves and a foundation for later work...
If you don't mind the performance hit, sending everybody who comes in through the 'public' SSID out through Tor is an option...
Mac UEFI is, if anything, even weirder than the usual flavor. Apple laptops running Apple EFI in order to boot OSX work; because Apple makes all of them and none of the parts is dumb enough to lean on the other parts in an unexpected way; but once you try something different, life gets exciting(the, er, interesting transition between 32 bit and 64 bit EFI 1.x was good fun as well).
This fellow used to do EFI-related work for Redhat and is interesting reading on the matter. UEFI is a bloated bear of a 'standard', that makes ACPI look like a brutally efficient paragon of elegance, and things tend to go downhill from there once a vendor gets their sloppy hands all over it...
The BIOS interface was overdue for being updated/replaced
True. Unfortunately, UEFI was a step in the wrong direction. Yeah, the classic BIOS was older than dirt, limited, and saddled with a variety of quirks, oddities, and cruft from its years of genetic drift and backward compatibility.
However, because it sucked, there was a strong incentive not to try anything stupid with it, and to just boot the OS and GTFO. Instead of just cleaning up and rationalizing this basic firmware function, UEFI goes wildly in the opposite direction, to the point where the firmware is tantamount to a second OS; but still with all the fucked up weirdness that we know and love from BIOS features like ACPI...
It seems as though there is something badly wrong with the at least some part of the design if a bug of this flavor is possible(much less happening for reasons that even the vendor hasn't nailed down yet).
There are reasons to update/modify the firmware responsible for the first stages of the boot process; but not all that often(especially on a PC-class device, which has tons of both RAM and persistent mass storage available, this isn't some cost-reduced embedded device where the OS has to scribble configuration information in whatever bits of the teeny flash chip that also stores the bootloader).
Can anybody enlighten me as to why (outside of a BIOS update) a situation would arise where the kernel needs to scribble over the motherboard firmware, or where the firmware would be doing anything sufficiently drastic to itself based on input from the kernel that it wouldn't be recoverable?
Obviously, Boeing should simply have specified that all the contractors deliver components that accept and output plaintext, and then used pipes and awk to cobble the pieces together into a working system! What could possibly go wrong?
Given how bitterly controversial the idea that Americans really ought to have access to boring old routine healthcare is, I wouldn't be optimistic about our level of preparedness...
The turnaround time(even if you crank up your risk tolerance a bit and skip some of the approval steps) from even modestly novel pathogen to treatment/vaccine is on the order of months(something like the flu vaccine is probably the most well-oiled vaccine development and distribution operation, and even there they have to forecast the expected outbreak strain in order to have enough time to produce, distribute, and administer the result), with some diseases proving much tougher to crack.
In the meantime, the main factor determining the mortality rate, aside from the disease itself, will be the ability of your healthcare system to cope under overload conditions, your social infrastructure to cope with a heck of a lot of sick days without cascading failures, and possibly your ability to do very unpopular quarantine related things.
How lucky do you feel?
While there doesn't seem to be a 100% clear answer on how hard biological weapons actually are to make(nation states have definitely played with them, sometimes just by bottling wild nasties, sometimes by modification or selective breeding, amateurs don't seem to have managed much for the moment), the thing that makes 'biodefense' feel like something of a lost cause is that so much of it is a deeply unsexy(and surprisingly unpopular) mix of public health and infrastructure work.
Sure, somebody has to wear the cool positive-pressure suits and do Tense Movie Science in the biohazard level 4 labs; but if a novel strain of something for which there isn't presently a vaccine pops up, the only relevant question will be along the lines of 'do we have anything resembling the capacity to provide supportive care/any remedies that are available in a mass infection context?' The answer, of course, is 'ha, ha, are you joking? Have you seen the wait times for anything short of serious trauma at your local ER?'
That's the trouble: Barring some sort of technology-indistinguishable-from-magic(an immunological simulation powerful enough to take a pathogen's genetic sequence as input and spit out a vaccine formulation ready to hit production, or something similarly Not Available Now), your main defensive options are comparatively low-tech; but very broad based and probably quite expensive, improvements in healthcare capacity and epidemiological surveillance, combined with lots and lots of basic research in medicine(since a good bioweapon will be at least somewhat novel, you can't really target research against it, so you need to have as much as possible in terms of supportive care, general understanding of strategies for rapidly evaluating and countering novel pathogens, etc, etc.) Unfortunately, that's exactly the sort of plan that would never sell, and, since it involves spending lots of money every year against a threat that may not even show up, makes a great target every time budget time rolls around.
Why does Facebook even offer an API to developers if any time an app becomes popular they block them?
If you can get suckers to develop for a platform that you can shove them off to drown at any time, it ensures that you can buy their assets at firesale prices and face minimal challenges integrating them into your service, since they are already API compatible!
Perfectly sensible on Facebook's part, it's the sanity of the people who use the API that you have to worry about...
The soul-crushing thing about your story is that it suggests that somebody deliberately went to additional effort to build/install a telnet daemon while hacking the firmware together. That's just sick and wrong.
What, nobody has complained about this being an intentional backdoor yet? The Chinese are out to get us.
I'm inclined to keep "Never attribute to malice something much stupider than malice would have implemented" in mind as a variant on the usual phrase.
Given the hordes of profit-driven, variously political, and simply lulz-oriented attackers on the internet, relatively blatant backdooring(when you are in the privileged position of being the guys shipping the firmware, no less, hard to ask for more insider access than that) amounts to squandering an advantage. Had the units shipped with, say, a bugged sshd that is hardcoded to always allow access via keypair auth with a specific private key, it is both much more likely that nobody would ever have noticed, and that nobody but the intended attacker would ever have been able to make use of the vulnerability. A wholly unauthenticated hole, on the other hand, is an open invitation to every bot-herder and na'er-do-well on the planet to come and have a rummage through the systems, leading to much greater competition for the creator of the backdoor.
Thankfully, the competitors you mention are all dubiously competent, so this is unlikely to be Newegg's death-by-good-intentions.
The study of history is a perfectly valid field and has some researchers and courses of study that focus specifically on technological and scientific developments. It would certainly be quite reasonable for influential software and hardware to end up being studied here, same as any other relevant developments from fire and cave-painting to the present.
CS, though, seems like an odd place to roll out history beyond the level of name-checking discovers of algorithms and the like. Much of what is historically influential is either excessively bound to its time(writing a functional business software package in assembly may be impressive; but learning that somebody did so probably won't teach you much about modern software design or even be terribly efficient at teaching the architecture they wrote it for), or sufficiently timeless as to make its historical details a matter of politeness; but not really relevance(it is a polite convention to credit the discoverer of an algorithm or the originator of a concept; but the result stands by itself).
If anything, the expectation that 'Computer Science' would include a dose of history suggests the influence of the fairly lousy state of science education(at least among people not directly on a science track): much lower level 'Science' curriculum is heavily larded with pure history because the present state of the art is too complex or fast moving(and, unfortunately, often because even the historical science is considered too mathematically intimidating and so is taught as historical anecdote instead).
1. Very few arguments apply 'without limit', and this one certainly doesn't. In broad strokes, it starts to break down once the supply of jobs available(given the narrowed definition of the labor pool) falls below the number of economic entities who need incomes(depending on the prevailing social arrangements, such entities might be individuals, nuclear families, extended families, or other). Exactly what equilibrium point is reached in practice is mostly empirical: child labor, at least outside the family, seems to have few moralists on its side and tends to significantly retard education, so it often gets the chop. Limits on working hours are another means of reducing the labor supply that has achieved broad adoption and popularity.
Restrictions on individuals within the adult population definitely exist; but tend to be carved out by much more idiosyncratic means; formally-illicit-but-common discrimination against certain groups, various professional exams and licenses, that sort of thing. Because they tend to badly fail the 'number of jobs roughly equals number of economic entities' rule, wholesale restrictions typically only achieve support if the group excluded is supposed to be a member of some already employed entity(exclusion of women, say, becomes deeply problematic if single-income families are not the ideal and the norm) or if the exclusion is from a specific profession rather than from the workforce entirely.
2. As with sellers of any other good, sellers of labor who wish to maximize their slice of the pie are striving to hit the optimal compromise between units sold and price per unit: If you simply gave labor away, you'd sure see a lot of new factories; but it wouldn't help you much. If you charge $1,000/hr, you probably won't have a job. Some number of new factories is clearly beneficial to workers; but the returns aren't unbounded: If the additional demand for labor produced by lowering its price doesn't make up for the lower price(and loss of time you could be using for other things) it isn't terribly helpful. Exactly how many factories constitutes a local optimum is, naturally, a messy empirical question.
While it is undeniable that a combination of superior machinery and fossil fuels kicked off an era of unprecedented prosperity for humans on average, there are a couple of complicating factors to consider, both boiling down to distribution issues:
The most obvious one is that child labor(since it is usually cheaper, and since children in the workforce raise the total supply of labor) tends to depress wages and reduce the slice of the industrial prosperity that accrues to the workers(especially in per-labor-hour terms). Certainly, it will generally be the case that a given household will be better off with an additional salary(especially if something prevents one or both parents from working, like being unskilled, infirm, dead, etc.); but workers as a group are better off if children are removed from the labor force, reducing labor supply and allowing children to accrue education and other human capital. Part of the "West lifted themselves out of this" process was precisely the eventual success of the working class and any allies swayed by moral sentiment in legally forcing restrictions on child labor across the board. Since, structurally, such restrictions are essentially a cartel arrangement(since any individual defector will be better off through violating the agreement; but the group as a whole wins if nobody violates it), it more or less had to be done by force of law.
Second consideration involves looking at whatever conditions in the agricultural sector are sucking so much that a ready supply of child factory workers exists. England had its 'Enclosure Movement', which helped swell the supply of impecunious urbanites. I'm less familiar with the Chinese case; but the disparity between urban and rural conditions there is pretty remarkable.
I use Tracphone as well, since it seemed to be about the cheapest option to keep a phone number alive with my minimal use habits; but I would warn the submitter not to.
Tracphone does something nonstandard with their SIMs and handset firmware. I don't know whether it is a trivial thing to hack, or serious crypto cat-and-mouse; but(at least by default) a Tracphone SIM Will. Not. Work. with anything other than one of their handsets.
Since the submitter wants to shove the SIM in a computer of some flavor, that's not going to work for him.
I assume that the fairly trivial "put some dung beetles in an enclosure covered with black paper and make your grad students poke holes matching the milky way and watch what happens" strategy didn't occur to you?
No, science is not infallible, particularly once human and institutional factors come into play; but falsifying hypotheses on animal navigation methods is hardly the most difficult challenge faced by the sciences. Want to fuck with an animal that you suspect of celestial navigation? Advanced 'planetarium' technology may be for you! Suspect pigeons of navigating with magnetic fields? Exploit natural variations in earth's magnetism or just superglue a NIB magnet to the insouciant little fucker's beak, that'll show 'im which way north is...
Oh, I don't doubt his ability to work past the interlocks, I was(attempting to, may have been unclear) contrast attacking the interlocks, which is annoying but within the capabilities of a good electronics hobbyist, with handling any more serious issues with either payload destruction or printhead fouling, which would require reworking of the mechanism to such a degree that you might as well not start with an inkjet at all, printheads are exquisitely tiny little things.
It certainly does look like his system doesn't kill its payload; but I'd be curious about whether it has fouling problems or not over time.
Fair enough. I wasn't disagreeing with you, just emphasizing that there are real-world applications, most commonly in RTS situations, where pegging the CPU is very much possible and can really ruin the game even in the presence of an otherwise adequate system.
Given that the 'default' PC configuration these days is "More CPU than you need, about half as much RAM as you really should have, a slow HDD, and integrated graphics" it isn't usually the case that being CPU-bound is your first problem; but it can bite, hard, under specific circumstances.
Aside from the ugly business of working around all the annoying interlocks that inkjets have for atypical paper feed/consumables condition/problems that exist only in their own imagination/etc. which generally stop the printer dead, regardless of how mechanically healthy it is; a problem that is annoying, but solvable with sufficient electronics hackery skill, I'd be curious to know how well biological 'inks', or any other not-formulated-for-the-purpose materials deal with the inkjet mechanism.
In piezolelectric inkjet printers, an electrically actuated piezo element provides the slight expansion necessary to shove a droplet of ink out of the nozzle. I'd assume that anything that is tolerant of small(but high frequency, a piezo head can shove out some tens of thousands of droplets per second, and at fair speed, so there are probably stresses that particularly whiny and structurally complex organic molecules can't handle) pressure waves should be fine.
However, particularly among consumer cheapies, thermal inkjets have become quite common: these use a pulse of current across a resistive element to vaporize part of the ink, the expansion of which drives the remaining ink out of the chamber and toward the target. The amount of heat is small in absolute terms(the vaporization chambers are constructed by photolithiographic techniques, to give a sense of scale; but enough heat to flash-vaporize ink is quite probably enough heat to denature common proteins and/or turn common biological materials into a layer of gooey carbon gunk that clogs the print head in short order.
Any word on whether piezo printers are best for this application, or does thermal work much better than I would naively expect?
this doesn't surprise me one bit.. the GPU does most of the heavy lifting anyway, when it comes to games
still, an i7 will show you substantial performance enhancements
It's a bit more nuanced than that: certain upgrades lean almost entirely on the GPU(say you get a fancy new monitor and want Game X to look good on a 1920x1080 or 2560x1440 instead of a 1280x1024); but you can run into situations where no CPU is really enough CPU(RTS pathfinding in games that permit a lot of units is a particularly hairy case. Supreme Commander, say, can merrily chug along at 60fps with a screen full of units cranking out idle animations; but a few hundred bots scrambling to navigate can bring your CPU to its knees.) It's certainly a less common issue than an inadequate GPU; but it can happen.
How much does a Cisco two-pound sledge cost after you factor in the warranty coverage, firmware licensing, and maintenance contract?