But we need to pay for infrastructure. SO we need to tax electricity to recoup lost revenue form the gas tax.
It would make more sense to crank up the diesel tax. Big trucks cause about three orders of magnitude more damage to roads than cars do anyway (one 18 wheeler does as much damage as 9,600 cars, according to the GAO), so it is only fair that trucking companies should pay essentially the entire cost of upkeep. If they raise the taxes high enough, perhaps we’ll see a resurgence in the use of trains for shipping (which is more energy efficient, too).
Are this things hail resistant? Lower prices are interesting only if won't be smashed by some pieces of ice falling from the sky
Generally speaking, yes. Anything complying with international standards is required to handle a 1 inch chunk of hail at terminal velocity (50 MPH). Many panels are rated up to 4x that, for added robustness, but I doubt those are the cheap ones.:-)
Net metering is when it runs backwards? That's probably find in a single month. But to carry it out over the year doesn't seem fair because during winter months, the solar panel user really is taking advantage of the grid.
How is that not fair? As a solar panel user, you’re no different from any other generator company. If I’m producing power, I darn well expect the power company to pay me for it, just as I expect to pay them if I’m using more power than I produce. What would be unfair would be an arbitrary limit to how far ahead you can build up bill credits towards future bills, because that would mean that I produced power that the power company benefitted from, and sold to somebody else for more than they should have paid me for it, but then didn’t pay me for it. That’s called stealing where I come from.
Besides, on average, solar power users produce power during the day, when demand is high and the cost of production is relatively high (because peaker plants are expensive). They consume power mostly at night, when demand is low and the cost of production is low. So no matter how long a cycle you average it over, the power plants are making a big profit from buying relatively cheap solar power instead of expensive natural gas peaker plant power (while selling that power at the same price). That more than pays for the negligible marginal grid maintenance costs arising out of providing power to one extra home.
And if you produce more power than you consume for a whole year, the power company gets an even bigger windfall profit. In most places, net metering happens on a one-year cycle. They pay you if you use less power than you produce over the course of that one-year period, but at least here in California, they pay a whopping 3 to 4 cents per kWh (less than half the production cost for solar, last I checked). As a result, there’s really zero advantage to overbuilding; the goal is to get as close as possible to breaking even over the year, without going significantly over. And, of course, they resold your extra power at up to 38 cents per kWh....
I was about to make the same crack, but in English. Crank that baby up to solar furnace levels of energy. Then, when the bird tries to perch in front of the laser, it gets rapidly cooked and falls. As a bonus, you could start a KFC franchise right below the tower.
Alternatively (and more seriously), mount several lasers a few feet apart and use channel bonding. If one laser goes dark, turn off its mate in the opposite direction, and try again on a preset schedule. That way, the sending end immediately knows the link is down and can rate-limit the data flow and use fewer links until the problem corrects itself. You'll drop a couple of packets, but the link will hold.
The real problem here, as I see it, is that the developer of the TRIM enabler is writing bug reports that request a ridiculously complex solution that doesn't make much sense, rather than a very trivial solution that does.
The right way to solve this problem would be for Apple to add a single line of code that checks for a magic value in the device tree, and enables TRIM support if it finds it. Then, the TRIM enabler could write a codeless kext for any devices whose TRIM support seems to work, whose sole purpose is to add that magic value into the device tree, that matches at a higher priority than the Apple driver, modifies the device tree, and walks away from the table, allowing the Apple driver to attach, see the flag, and use TRIM support.
Heck, there's probably a flag like that in there already. Just looking at the device tree for my Apple-branded drive in 10.9, I see something pretty glaring:
"IOStorageFeatures" = {"Unmap"=Yes}
and thirty seconds later, found the documentation for that key here. Chances are, if you write a codeless kext that modifies the device tree to add this property to the device, and if you get your matching correct, the unmodified Apple driver will magically enable TRIM support. If so, then you just need to get a proper signing key from Apple, sign the codeless kext, and you're done. If not, file a bug asking for that approach (or a similar approach with a different key) to work.
If that approach doesn't work, then and only then should you even think about writing an actual chunk of kernel code.
I guess it depends on how bad the noise is. I could believe one in 10K or one in 100K. I'd have a hard time believing that a manufacturer would ship something with enough noise to bother one in 1K people. Usually I'd expect the noise to be in a frequency range where most adults either can't hear it or can barely hear it.
I'm deeply underqualified to tell you how DC-DC converters do work...
Me too, but I'll try anyway. After all, this is Slashdot.:-D
If I understand correctly, a buck (downstep) converter starts with an oscillator that drives a transistor. The transistor turns the power source on and off very rapidly. An inductor between the high source voltage (after the switch) and the low-voltage output effectively turns the resulting current cycling into a voltage drop, and a capacitor smooths the resulting power supply back into DC. A diode bypasses the source and switch, ensuring that current continues to flow when the switch is off.
The duty cycle of the oscillator determines the resulting output voltage, so if you're starting at 12V and need 3V, you would use a 25% duty cycle (an oscillator whose output is on 25% of the time, and off 75% of the time). The frequency of the oscillator must be well above the human hearing range for obvious acoustic reasons.
If price were not a factor, at least a tenth of the regular slashdot crowd could built a Dalek to go ont he scaffold and use a multiple jointed/gimballed arm to handle a squeegee. The Dalek can then be operated remotely from the roof with multiple live feed high res camera, with no risk to humans. Hell, I'm not even a robotics guy but I can build an admittedly fragile one out of Legos and a few NXT kits. Give me stronger bricks and a welder, with scaled up more powerful servos than the NXT kit has and and I can build something workable in a couple days and refine that over a couple builds to get a nice even spring attenuated tension so it can use a regular squeegee with reasonable (non-human) speed via RC. Even if it is 1/10 as fast, hire ten guys to RC them and you still finish as quickly. What's that? That costs too much? Well then, I guess cost is a factor so we'll just stick with humans.
I'm pretty sure it is possible to fully solve this problem without even a kindergarten level of robotics—which is to say, no robotics whatsoever. You'll need the following hardware:
Fire hose of sufficient length
Tank of concentrated soap
One or more mixing sprayer nozzles
One or more rinse nozzles
Miscellaneous water couplings
2 Large motors
High-speed blower
Cloth flap cleaning bar assembly from a car wash
Assembly instructions:
Split the output of the hose between the mixing nozzle(s) and the rinse nozzle(s).
Connect the soap tank to the mixing nozzle(s).
Mount the mixing nozzle(s) to the underside of the existing platform in such a way that you spray the entire window surface.
Mount the cloth flap bar above the mixing nozzle(s).
Mount the rinse nozzle(s) above the cloth bar.
Mount the blower above the rinse nozzle.
Attach one motor to the blower.
Attach the other motor to the cloth flap bar.
Adjust the spring tension of the flap bar assembly to ensure sufficient contact with the window.
Turn everything on, and slowly lower the washer unit from the top of the building to the bottom.
For added efficiency, if the building is not solid glass, add some basic reflection sensors to avoid spraying water that would miss the windows entirely.
Ah. I missed the fact that you were talking about inductors on a DC-DC converter on the graphics card itself. In that case, yeah, that's just shoddy. On the other hand, it is easy to fix:
No, it didn't. It meant that the guns had been properly tested.
You're both partially correct. A well-regulated militia, in the context of that century, meant that the militia was a precision organization, which by extension means properly trained and coordinated and ready to fight (e.g. with working weapons), as opposed to a loose-knit bunch of random people with guns that may or may not work. To that end, we have a well-regulated militia. It has five branches: the Army, the Navy, the Air Force, the Marines, and the Coast Guard.
This is not to say that we shouldn't allow people outside of that militia to own firearms, just that a strict interpretation of that amendment using the meaning of the word "regulated" from the 1700s does not require such an allowance.
You are mis-interpreting the phrase well regulated incorrectly, I believe. It has nothing to do with regulations, or something that is regulated. In this context, in 18th centurty english, the phrase well regulated means properly functioning or working well. A clock that keeps good time was said to be well regulated (i. e. working well).
Although on the surface, that statement is technically correct (the best kind of correct), it is a bit disingenuous when folks stretch that definition to imply a lack of rules. It is difficult to imagine any complex system that would qualify as well-regulated in the "functioning properly" sense without also being well-regulated in the "has a specific set of rules or constraints that govern its operation" sense. So by definition, your definition implies the other definition.
For example, any properly working mechanical clock has hardware that controls its speed. In fact, the term "regulator clock" came into common use long before the Constitution was written and during the period, and was a household term by the late 1700s. It got its name because of the escapement regulator that governed its operation. So "well-regulated", even in the 1700s, could not realistically have be interpreted to imply an absence of governance—quite the opposite, in fact. In the context of clocks, the primary meaning of the term in that era would have been "precision", not "properly functioning". Precision, in turn, demands some form of either internal or external regimentation.
Because 99.999% of users don't care enough to complain. When you get enough whine that a sizable number of users scream bloody murder, something gets done. But for a more typical amount of supply whine, why spend the extra buck or two? And chances are, it never makes it to the BOM penny pinching stage, because unless the design is producing serious noise, corrective actions probably won't be taken in the first place.
Besides, assuming you use a standard-shape power supply, the users who really care about noise will buy ultra-low-noise power supplies to replace whatever $15 junk PSU you put in the machine from the factory anyway.:-)
USB-wired Ethernet means reverse tethering. Unfortunately, it really isn't practical on a classroom scale, because of the distances involved, not to mention that general-purpose computers aren't really all that great at handling high-speed network routing for thirty or forty machines to begin with, and USB's excessive CPU overhead just piles on top of that.
It would be cheaper and more reliable to install a dedicated Wi-Fi hot spot in every classroom with a fairly directional antenna on the ceiling, and set the maximum transmit power really low so each classroom acts like its own microcell that is roughly limited to the bounds of the room. Chances are, a single shared Wi-Fi connection is plenty fast enough for a single classroom, and in my experience, as long as you aren't doing tethering, Wi-FI works very well on iOS (the recent WPA2 Enterprise networking authentication changes in iOS 8 notwithstanding). It's only a nightmare on Windows, which is probably one of the reasons that Microsoft is getting stomped into the ground in school markets.... But I digress.
BTW, does anybody else find it odd for an article to say that MS is losing the market? Normally "-ing" verbs imply that something is happening right now. I was under the impression that they had pretty much lost the K-12 market to iPads years ago.
Or worse, imagine that they do understand they have to fill the tractors with gasoline... but the tractors run on diesel. (And then they wonder why the tractor engine keeps blowing up.)
None of those things is dependent on low level coding experience.
That's one way to learn those things. A CS degree is another. The point was that they need to at least have some concept of what's happening below them, regardless of how they got that understanding, and that more and more often, developers lack that understanding because we've made it too easy for people to dive in and write working (but badly written) software. By taking away the steepness of the learning curve, we've eliminated the impetus to actually get a degree, and to take the time needed for reading complex documentation and learning how to write software correctly.
Well, possibly the network data one, but even there you're more likely to screw up by trying to do something low level (like send a byte at a time by hand) than you are by just using the appropriate library functions.
If you're able to do everything with HTTP, there are some decent libraries out there, but if you're doing raw socket networking, the higher level libraries seem even clumsier and easier to screw up than POSIX to me. YMMV.
To clarify, I'm not saying you have to have low-level programming experience; that's just one possible way to get the requisite understanding of what's happening lower down in the stack; a good CS degree is another. The point was that more and more developers seem to lack that understanding, in large part because they're starting with progressively higher-level cookie cutter pieces that separate them farther and farther from the bare metal, and they lack the CS background to understand what those layers of abstraction are hiding from them, so they make wrong assumptions. Either a CS background or experience at a moderately low level (e.g. POSIX-level networking, PThreads, etc.) would result in better assumptions.:-)
It's been a while since I worked on LTE (call processing, not RF or hardware or even baseband), but I thought that with UTRAN there was a 350 km/h "speed limit" (perhaps up to 500 km/h under certain circumstances) with motion relative to the base station.
Yeah, and that's about half the cruising sped of a modern aircraft. They would probably have to use a modified LTE with wider guard bands on either side of the expected frequency range, and they'd probably need to modify the radio firmware on both ends to do so, at which point it wouldn't technically still be LTE, but some variant thereof. Of course, they could enable that mode only when talking to aircraft, so it wouldn't be dramatically reducing the spectrum for everyone.
This. That modern developers suck at assembler is a bad thing assumes there's a reason you'd want them doing assembler in the first place. If a farmer's tractor breaks down he doesn't get out and start shoveling, he calls for a tractor repairman which specializes in that sort of thing. If you call a low level library from a high level language and it crashes, check the documentation again. If you're still sure you're doing it right, the efficient thing to do might be to file a bug and let someone used to poking around in C/ASM take a look at it. It's specialization at work and it might not make sense for one person to know the whole stack top to bottom. Or at least that person would be a guru and companies aren't full of those.
That's sort of missing the point, though. We're not talking about people sucking at assembler anymore. We're talking about people who have never done any programming at a low level, so they have little to no concept of what is going on below their application. And that is a problem. Developers don't have to know every detail of what's happening down at the bare metal, but if they don't at least understand it at a coarse-grained level, they will invariably write terrible code. It isn't at all uncommon to find developers that:
don't understand why the O(n!) code that worked fine on a ten-item list suddenly performs horribly with a twenty-item list.
don't understand why sending network data one byte at a time results in horrible performance.
don't understand that they shouldn't keep waking up the CPU over and over, and then wonder why their app is sucking down battery power like there's no tomorrow.
don't understand the basics of multithreaded programming, run everything on the main thread, and wonder why their app freezes while they are doing I/O.
And so on. Not to put too fine a point on it, CS degrees matter, and the increasing percentage of self-taught developers is a big part of the problem. The more companies dumb down their tools and documentation to make it easier for those developers to get things done, and the more ready-to-use snippets they provide, the longer it will take bad developers to realize that they are in over their heads, the longer it will be before they take the time to learn the basics, and the more bad code they'll produce in the meantime. This is almost inarguably not a good thing. As I've said many times before, "The great thing about making it easier to write software is that more people write software. The bad thing about making it easier to write software is that more people write software."
To use a farmer analogy, imagine farmers buying a new tractor every week because they don't know enough about their tractors to understand that you have to fill them with gasoline every so often. You don't have to know precisely how a tractor works, but you do have to know that it requires fuel, oil, and possibly coolant; you do have to know to check those levels regularly; and you do have to know the limitations of the hardware so that you don't get stuck in a ditch.
Sorry, I've been in a coma for the last 6 years. Did I miss something?
No, Senator. We managed to pull off your reelection campaign without you using a cardboard cutout, and surprisingly, nobody noticed the difference. And almost nothing of importance happened on the Senate floor while you were out, so I think you're good. Oh, except for that pesky Affordable Care Act. If anybody asks, you abstained, but you would have voted against it..
1) Residential broadband networks were never engineered as video delivery systems. The advent of mainstream streaming video completely changed the engineering calculus for last mile networks. Over subscription ratios need to change to accommodate the higher peak hour bitrates; this takes time and costs money. Where should this money come from? Why should I pay the same for my connection as the household that's running three or four simultaneous HD streams during peak hours? My 95th percentile is less than 0.5mbit/s, yet I pay the same as my neighbor who regularly runs three HD streams at the same time. Hardly seems fair, does it?
This is why you should offer cheap broadband plans to the tiny percentage of people who are willing to put up with slow service.
The reason that cable companies shouldn't try to find ways to stick it to the top 5% is that those early adopters are the ones who make new, cool technology financially feasible. They drive the Internet forward, allowing interesting services to come into existence. Eventually, the use of those services filters down to more and more customers. If you penalize the folks whose bandwidth usage falls within the top 5%, the Internet as a whole will inevitably stagnate. More importantly, there will always be a top 5% to penalize, so even if those folks stop doing what they are doing, the cable companies will then penalize a different group of people, leading to progressively declining quality of service.
3) IPTV is inherently inefficient vis-a-vis point-to-multipoint delivery systems (i.e., cable, OTA, satellite)
And yet the VoD services from your cable company work the same way. The difference is that their service is not throttled, because it travels only between the cable company offices and your home, without traversing any of the saturated external links. And that is what Netflix has to compete with.
5) Netflix has a history of trying to offload their costs onto third parties, be they ISPs, Tier 1 networks, CDNs, etc.
They pay CDNs to make content available closer to their customers. That's not offloading costs; it is distributing the load to reduce the impact on the Tier 1 networks. Besides, they are paying their bandwidth bill. They pay for access to the Internet, and their ISP pays their upstream, and so on, eventually resulting in the Tier 1 networks getting paid. The other side of the connection is the responsibility of the person on the other end, which means the individual residential customers, who pay for their own access to the internet, whose ISPs pay their ISPs, and so on, up to the Tier 1 backbone providers.
What the cable companies are trying to do is force one end of the connection to pay for the entire connection from one end to the other, which is pure bulls**t in any sane universe. That's just not the way the Internet works. The cable companies are the ones who are trying to offload what should legitimately be their costs onto a third party (Netflix), solely because that third party provides a service that is popular among their end user customers.
Sorry, but there's really no grey area here; Netflix is clearly on the right side of this, and the cable companies are clearly on the wrong side.
But according to Wikitionary [wiktionary.org], "Ars" meant "burn" in ancient french.
And in Helvetica and Arial, burn = bum. It makes perfect sense, indeed. The British were just using an illegible font when they came up with their slang.
Without looking at the data, I'm speculating a lot with that suggestion, but I don't think you should dismiss the possibility of inverse causation out of hand.
There's a huge difference between two completely unrelated things being correlated and two different expressions of the same basic psychological urges being correlated. Internet explorer use and CO2 levels are only very distantly related in that both represent signs of a strong economy in a technological society. So odds are good that such a correlation is a fluke, or at best reflects a common cause (more money allowing people to buy more computers and cars).
By contrast, expressing violence in a game and expressing it in real life are similar activities in a lot of ways. If you see a strong reverse correlation there, the odds are reasonably good that you have causation, reverse causation, or a single common cause of both changes. Of course, this assumes a truly strong correlation, as opposed to just a crudely opposite trend, where only the changes in one direction are inversely correlated. And even with a strong correlation, I wouldn't call it solid evidence of inverse causation unless you could find similar inverse correlations at other levels of granularity (e.g. states, cities, and neighborhoods), from other countries, and so on. With that said, the hint that such inverse causation might exist would make it worth further study.
If, on the other hand, you just have a crude trend match (where one is trending upwards and the other is trending downwards, but they don't change directions at about the same time), then yeah, I'd agree that the inverse correlation is probably more like pirates on the high seas protecting against global warming....
You however forget the obvious counterpoint. People use these mediums to vent their natural violent tendencies, leaving them with less active natural violent tendencies in real life.
The study's researchers dismissed the inverse correlation they found, saying that they didn't believe violent video games could decrease violence, but their data did actually suggest it... which is pretty much what most folks on this board have been saying for years.
Slashdot Mirror
It would make more sense to crank up the diesel tax. Big trucks cause about three orders of magnitude more damage to roads than cars do anyway (one 18 wheeler does as much damage as 9,600 cars, according to the GAO), so it is only fair that trucking companies should pay essentially the entire cost of upkeep. If they raise the taxes high enough, perhaps we’ll see a resurgence in the use of trains for shipping (which is more energy efficient, too).
Generally speaking, yes. Anything complying with international standards is required to handle a 1 inch chunk of hail at terminal velocity (50 MPH). Many panels are rated up to 4x that, for added robustness, but I doubt those are the cheap ones. :-)
How is that not fair? As a solar panel user, you’re no different from any other generator company. If I’m producing power, I darn well expect the power company to pay me for it, just as I expect to pay them if I’m using more power than I produce. What would be unfair would be an arbitrary limit to how far ahead you can build up bill credits towards future bills, because that would mean that I produced power that the power company benefitted from, and sold to somebody else for more than they should have paid me for it, but then didn’t pay me for it. That’s called stealing where I come from.
Besides, on average, solar power users produce power during the day, when demand is high and the cost of production is relatively high (because peaker plants are expensive). They consume power mostly at night, when demand is low and the cost of production is low. So no matter how long a cycle you average it over, the power plants are making a big profit from buying relatively cheap solar power instead of expensive natural gas peaker plant power (while selling that power at the same price). That more than pays for the negligible marginal grid maintenance costs arising out of providing power to one extra home.
And if you produce more power than you consume for a whole year, the power company gets an even bigger windfall profit. In most places, net metering happens on a one-year cycle. They pay you if you use less power than you produce over the course of that one-year period, but at least here in California, they pay a whopping 3 to 4 cents per kWh (less than half the production cost for solar, last I checked). As a result, there’s really zero advantage to overbuilding; the goal is to get as close as possible to breaking even over the year, without going significantly over. And, of course, they resold your extra power at up to 38 cents per kWh....
I was about to make the same crack, but in English. Crank that baby up to solar furnace levels of energy. Then, when the bird tries to perch in front of the laser, it gets rapidly cooked and falls. As a bonus, you could start a KFC franchise right below the tower.
Alternatively (and more seriously), mount several lasers a few feet apart and use channel bonding. If one laser goes dark, turn off its mate in the opposite direction, and try again on a preset schedule. That way, the sending end immediately knows the link is down and can rate-limit the data flow and use fewer links until the problem corrects itself. You'll drop a couple of packets, but the link will hold.
Turns out it's bad for your teeth. Who knew?
The real problem here, as I see it, is that the developer of the TRIM enabler is writing bug reports that request a ridiculously complex solution that doesn't make much sense, rather than a very trivial solution that does.
The right way to solve this problem would be for Apple to add a single line of code that checks for a magic value in the device tree, and enables TRIM support if it finds it. Then, the TRIM enabler could write a codeless kext for any devices whose TRIM support seems to work, whose sole purpose is to add that magic value into the device tree, that matches at a higher priority than the Apple driver, modifies the device tree, and walks away from the table, allowing the Apple driver to attach, see the flag, and use TRIM support.
Heck, there's probably a flag like that in there already. Just looking at the device tree for my Apple-branded drive in 10.9, I see something pretty glaring:
"IOStorageFeatures" = {"Unmap"=Yes}
and thirty seconds later, found the documentation for that key here. Chances are, if you write a codeless kext that modifies the device tree to add this property to the device, and if you get your matching correct, the unmodified Apple driver will magically enable TRIM support. If so, then you just need to get a proper signing key from Apple, sign the codeless kext, and you're done. If not, file a bug asking for that approach (or a similar approach with a different key) to work.
If that approach doesn't work, then and only then should you even think about writing an actual chunk of kernel code.
I guess it depends on how bad the noise is. I could believe one in 10K or one in 100K. I'd have a hard time believing that a manufacturer would ship something with enough noise to bother one in 1K people. Usually I'd expect the noise to be in a frequency range where most adults either can't hear it or can barely hear it.
Me too, but I'll try anyway. After all, this is Slashdot. :-D
If I understand correctly, a buck (downstep) converter starts with an oscillator that drives a transistor. The transistor turns the power source on and off very rapidly. An inductor between the high source voltage (after the switch) and the low-voltage output effectively turns the resulting current cycling into a voltage drop, and a capacitor smooths the resulting power supply back into DC. A diode bypasses the source and switch, ensuring that current continues to flow when the switch is off.
The duty cycle of the oscillator determines the resulting output voltage, so if you're starting at 12V and need 3V, you would use a 25% duty cycle (an oscillator whose output is on 25% of the time, and off 75% of the time). The frequency of the oscillator must be well above the human hearing range for obvious acoustic reasons.
I'm pretty sure it is possible to fully solve this problem without even a kindergarten level of robotics—which is to say, no robotics whatsoever. You'll need the following hardware:
Assembly instructions:
For added efficiency, if the building is not solid glass, add some basic reflection sensors to avoid spraying water that would miss the windows entirely.
Ah. I missed the fact that you were talking about inductors on a DC-DC converter on the graphics card itself. In that case, yeah, that's just shoddy. On the other hand, it is easy to fix:
:-)
You're both partially correct. A well-regulated militia, in the context of that century, meant that the militia was a precision organization, which by extension means properly trained and coordinated and ready to fight (e.g. with working weapons), as opposed to a loose-knit bunch of random people with guns that may or may not work. To that end, we have a well-regulated militia. It has five branches: the Army, the Navy, the Air Force, the Marines, and the Coast Guard.
This is not to say that we shouldn't allow people outside of that militia to own firearms, just that a strict interpretation of that amendment using the meaning of the word "regulated" from the 1700s does not require such an allowance.
Although on the surface, that statement is technically correct (the best kind of correct), it is a bit disingenuous when folks stretch that definition to imply a lack of rules. It is difficult to imagine any complex system that would qualify as well-regulated in the "functioning properly" sense without also being well-regulated in the "has a specific set of rules or constraints that govern its operation" sense. So by definition, your definition implies the other definition.
For example, any properly working mechanical clock has hardware that controls its speed. In fact, the term "regulator clock" came into common use long before the Constitution was written and during the period, and was a household term by the late 1700s. It got its name because of the escapement regulator that governed its operation. So "well-regulated", even in the 1700s, could not realistically have be interpreted to imply an absence of governance—quite the opposite, in fact. In the context of clocks, the primary meaning of the term in that era would have been "precision", not "properly functioning". Precision, in turn, demands some form of either internal or external regimentation.
Because 99.999% of users don't care enough to complain. When you get enough whine that a sizable number of users scream bloody murder, something gets done. But for a more typical amount of supply whine, why spend the extra buck or two? And chances are, it never makes it to the BOM penny pinching stage, because unless the design is producing serious noise, corrective actions probably won't be taken in the first place.
Besides, assuming you use a standard-shape power supply, the users who really care about noise will buy ultra-low-noise power supplies to replace whatever $15 junk PSU you put in the machine from the factory anyway. :-)
USB-wired Ethernet means reverse tethering. Unfortunately, it really isn't practical on a classroom scale, because of the distances involved, not to mention that general-purpose computers aren't really all that great at handling high-speed network routing for thirty or forty machines to begin with, and USB's excessive CPU overhead just piles on top of that.
It would be cheaper and more reliable to install a dedicated Wi-Fi hot spot in every classroom with a fairly directional antenna on the ceiling, and set the maximum transmit power really low so each classroom acts like its own microcell that is roughly limited to the bounds of the room. Chances are, a single shared Wi-Fi connection is plenty fast enough for a single classroom, and in my experience, as long as you aren't doing tethering, Wi-FI works very well on iOS (the recent WPA2 Enterprise networking authentication changes in iOS 8 notwithstanding). It's only a nightmare on Windows, which is probably one of the reasons that Microsoft is getting stomped into the ground in school markets.... But I digress.
BTW, does anybody else find it odd for an article to say that MS is losing the market? Normally "-ing" verbs imply that something is happening right now. I was under the impression that they had pretty much lost the K-12 market to iPads years ago.
They're their there.
"A little learning is a dangerous thing..."
—Alexander Pope
That's one way to learn those things. A CS degree is another. The point was that they need to at least have some concept of what's happening below them, regardless of how they got that understanding, and that more and more often, developers lack that understanding because we've made it too easy for people to dive in and write working (but badly written) software. By taking away the steepness of the learning curve, we've eliminated the impetus to actually get a degree, and to take the time needed for reading complex documentation and learning how to write software correctly.
If you're able to do everything with HTTP, there are some decent libraries out there, but if you're doing raw socket networking, the higher level libraries seem even clumsier and easier to screw up than POSIX to me. YMMV.
To clarify, I'm not saying you have to have low-level programming experience; that's just one possible way to get the requisite understanding of what's happening lower down in the stack; a good CS degree is another. The point was that more and more developers seem to lack that understanding, in large part because they're starting with progressively higher-level cookie cutter pieces that separate them farther and farther from the bare metal, and they lack the CS background to understand what those layers of abstraction are hiding from them, so they make wrong assumptions. Either a CS background or experience at a moderately low level (e.g. POSIX-level networking, PThreads, etc.) would result in better assumptions. :-)
Yeah, and that's about half the cruising sped of a modern aircraft. They would probably have to use a modified LTE with wider guard bands on either side of the expected frequency range, and they'd probably need to modify the radio firmware on both ends to do so, at which point it wouldn't technically still be LTE, but some variant thereof. Of course, they could enable that mode only when talking to aircraft, so it wouldn't be dramatically reducing the spectrum for everyone.
That's sort of missing the point, though. We're not talking about people sucking at assembler anymore. We're talking about people who have never done any programming at a low level, so they have little to no concept of what is going on below their application. And that is a problem. Developers don't have to know every detail of what's happening down at the bare metal, but if they don't at least understand it at a coarse-grained level, they will invariably write terrible code. It isn't at all uncommon to find developers that:
And so on. Not to put too fine a point on it, CS degrees matter, and the increasing percentage of self-taught developers is a big part of the problem. The more companies dumb down their tools and documentation to make it easier for those developers to get things done, and the more ready-to-use snippets they provide, the longer it will take bad developers to realize that they are in over their heads, the longer it will be before they take the time to learn the basics, and the more bad code they'll produce in the meantime. This is almost inarguably not a good thing. As I've said many times before, "The great thing about making it easier to write software is that more people write software. The bad thing about making it easier to write software is that more people write software."
To use a farmer analogy, imagine farmers buying a new tractor every week because they don't know enough about their tractors to understand that you have to fill them with gasoline every so often. You don't have to know precisely how a tractor works, but you do have to know that it requires fuel, oil, and possibly coolant; you do have to know to check those levels regularly; and you do have to know the limitations of the hardware so that you don't get stuck in a ditch.
No, Senator. We managed to pull off your reelection campaign without you using a cardboard cutout, and surprisingly, nobody noticed the difference. And almost nothing of importance happened on the Senate floor while you were out, so I think you're good. Oh, except for that pesky Affordable Care Act. If anybody asks, you abstained, but you would have voted against it..
This is why you should offer cheap broadband plans to the tiny percentage of people who are willing to put up with slow service.
The reason that cable companies shouldn't try to find ways to stick it to the top 5% is that those early adopters are the ones who make new, cool technology financially feasible. They drive the Internet forward, allowing interesting services to come into existence. Eventually, the use of those services filters down to more and more customers. If you penalize the folks whose bandwidth usage falls within the top 5%, the Internet as a whole will inevitably stagnate. More importantly, there will always be a top 5% to penalize, so even if those folks stop doing what they are doing, the cable companies will then penalize a different group of people, leading to progressively declining quality of service.
And yet the VoD services from your cable company work the same way. The difference is that their service is not throttled, because it travels only between the cable company offices and your home, without traversing any of the saturated external links. And that is what Netflix has to compete with.
They pay CDNs to make content available closer to their customers. That's not offloading costs; it is distributing the load to reduce the impact on the Tier 1 networks. Besides, they are paying their bandwidth bill. They pay for access to the Internet, and their ISP pays their upstream, and so on, eventually resulting in the Tier 1 networks getting paid. The other side of the connection is the responsibility of the person on the other end, which means the individual residential customers, who pay for their own access to the internet, whose ISPs pay their ISPs, and so on, up to the Tier 1 backbone providers.
What the cable companies are trying to do is force one end of the connection to pay for the entire connection from one end to the other, which is pure bulls**t in any sane universe. That's just not the way the Internet works. The cable companies are the ones who are trying to offload what should legitimately be their costs onto a third party (Netflix), solely because that third party provides a service that is popular among their end user customers.
Sorry, but there's really no grey area here; Netflix is clearly on the right side of this, and the cable companies are clearly on the wrong side.
And in Helvetica and Arial, burn = bum. It makes perfect sense, indeed. The British were just using an illegible font when they came up with their slang.
Without looking at the data, I'm speculating a lot with that suggestion, but I don't think you should dismiss the possibility of inverse causation out of hand.
There's a huge difference between two completely unrelated things being correlated and two different expressions of the same basic psychological urges being correlated. Internet explorer use and CO2 levels are only very distantly related in that both represent signs of a strong economy in a technological society. So odds are good that such a correlation is a fluke, or at best reflects a common cause (more money allowing people to buy more computers and cars).
By contrast, expressing violence in a game and expressing it in real life are similar activities in a lot of ways. If you see a strong reverse correlation there, the odds are reasonably good that you have causation, reverse causation, or a single common cause of both changes. Of course, this assumes a truly strong correlation, as opposed to just a crudely opposite trend, where only the changes in one direction are inversely correlated. And even with a strong correlation, I wouldn't call it solid evidence of inverse causation unless you could find similar inverse correlations at other levels of granularity (e.g. states, cities, and neighborhoods), from other countries, and so on. With that said, the hint that such inverse causation might exist would make it worth further study.
If, on the other hand, you just have a crude trend match (where one is trending upwards and the other is trending downwards, but they don't change directions at about the same time), then yeah, I'd agree that the inverse correlation is probably more like pirates on the high seas protecting against global warming....
The study's researchers dismissed the inverse correlation they found, saying that they didn't believe violent video games could decrease violence, but their data did actually suggest it... which is pretty much what most folks on this board have been saying for years.