The grid tie fee would have to be a lot more than $4.90/month to make the batteries look economical. Have you priced an off-the-grid system? Have you tried living on one? It either requires major lifestyle changes, a truly immense investment in panels and batteries (plus ongoing maintenance costs for the batteries) or a generator that will be running more often than you'd like, burning fossil fuels less efficiently than a big plant would. Anybody who buys batteries in response to this policy is cutting off their nose to spite their face.
It's not as simple as you're trying to make it. Adding batteries is not the same as "off-the-grid". In some places, a single meter is used, and the net power consumption is charged at retail rate. In other places, two meters are used; one measures power consumed from the grid, which is charged at retail rate, the other measures power generated, which is credited at wholesale rate. For single-meter systems, batteries are pointless aside from off-grid capability (thus I suspect you may have been thinking about these); for the two-meter systems, though, they can make sense.
Consider a simplified model: the solar panel generates 1 kW from 0600 to 1800, and the only power consumption is lighting, which consumes 1 kW from 1800 to 0600. With a single meter, the meter runs forward 12 kWh every night, then rolls back those same 12 kWh the next day. Net consumption, zero kWh, so why would you buy a battery? You wouldn't! Not only will it not save you anything, it'll actually cost you, because it takes more energy to charge than you recover on discharge -- so now your net consumption is positive.
But with two meters, suppose the wholesale pricing is 3c/kWh, while the retail pricing is 12c/kWh. Your consumption meter racks up 12 kWh a night, and your generation meter racks up 12 kWh a day. You pay $1.44 a day, minus $0.36 a day for your generation, or $1.08/day.
Now suppose you add 1 kWh of battery storage with 50% round trip efficiency (so it takes 2 kWh to charge, but you only get 1 kWh on discharge) -- now you're consuming 11kWh for $1.32/day, and generating 10kWh for $0.30/day -- your power bill decreases from $1.08/day to $1.02/day!
Better yet, if you can afford it, you'll buy a whole 6kWh of battery, and your solar panel will spend all day charging it, and it will power your lights for 6 hours.* Now your consumption meter only shows up 6 kWh/day ($0.72/day), and your generation meter shows nothing! Now it may or may not make economic sense to buy this battery -- you're saving 36 cents a day under our assumptions, but the battery system may cost more or less than the actual savings depending on the relationship of actual battery system prices with actual electric prices (both wholesale and retail), the actual round-trip efficiency, and the relationship of your real-world system (where both generation and loads vary day to day) to the model used here. But for some people, this is likely to come out very close to break-even, to the point where the prospect of saving $5/month is enough to tip the scales. The big question is whether such a near-break-even outcome is typical enough that a large fraction of PV-equipped homes will find it profitable to buy batteries and lose the second meter. I don't think it is, so I agree with you as to the ultimate outcome, but I don't have numbers to back that up.
*Note this is not an off-grid system -- for that you'd either need lifestyle changes (like turning the lights out half the night), or doubling your solar panel and storage capacity, and that's with our criminally simplified model; once you factor in short, cloudy winter days and realistic loads, off-grid is something you really pay for, in $$$ or convenience, as you rightly pointed out.
I see a whole lot of ego on slashdot. This post is a great example.... the supreme badass you believe yourself to be
Please read what I wrote. I didn't say I would whup any ass whatsoever; in fact I wouldn't, for a number of reasons, including that I think physical violence would be an overreaction, that I have somewhat limited ass-whupping skills, and perhaps most importantly that I'm in the habit of providing my own entertainment (on the rare occasions I fly), so I'd likely not even notice. I was merely suggesting a reasonably plausible (and to my mind comical) outcome for a would-be terrorist who tries to bring down the plane, but only succeeds in killing the in-flight movie for everyone in coach.
I believe it's customary at this point to suggest that your inference of an internet tough-guy attitude in my post is a case of projecting your own attitudes on others, so consider it suggested pro forma.;)
How the fuck would you even know if someone plugged 90V into the headphone jack,
Well, if somebody's fiddling about with a 30-cell pack of CR123s, it would likely be noticeable to some of the people sitting near them. (Note that this discussion is in the context of "using stuff bought in the secure zone to build weapons in the secure zone", so it's not likely that such a field-assembled battery pack would be disguised or even particularly tidily wrapped up -- it may have the sort of exposed wiring that makes a lot of people think "bomb"!) If the inflight movie cuts out exactly when they plug anything, but especially such an unusual/suspicious gizmo, into the armrest, those nearest them might well notice the correlation, rightly or wrongly infer causality, and raise a hue and cry.
Might not happen that way, but it might, which is all I ever claimed.
How about chaining lithium batteries together to make a tazer or device to overload the planes circuits?
Tasers have an open-circuit voltage of 50kV IIRC. Combining seventeen thousand CR123 cells seems like it might result in a slightly unwieldy weapon.
As for overloading the plane's circuits... which circuits? As a passenger, you have access to the inflight entertainment system, maybe some power outlets (28VDC or 110VAC), and that's about it. This isn't Star Trek, where an overload in holodeck 5 causes an explosion of sparks from the navigation console -- if you plug 90V or so into the headphone jack, you might fry your seat's electronics only, or you might take out the whole entertainment system (and get your ass whupped shoebomber-style), but you won't take out anything essential for flight.
the electricity to charge it (in the USA) is 68% fossil fuel derived.
Which is 32% less than ICE cars. And a lot of the 68% is from coal, which (1) we have a lot more of than oil and (2) is hard to use in ICEs (yeah, gassification's an option) but easy to use for electricity generation. It's not a renewable paradise or anything, but it's not half bad.
Software that 99.9% of us will never use has been re-licensed with an even more restrictive license.
You're not familiar with the old POV-Ray license, are you?
The original license didn't let you even distribute a modified version. You had to distribute your changes as a patchset, so anyone wanting to use your version could get the official code, patch it with your changes, then compile it.* So GPLv2, despite all its restrictions, is less restrictive!
Now this is AGPLv3, not GPLv2, but the differences (A=restrictions on using it to provide a network service, v3=patent-defense and tivoisation stuff) are simply not relevant to typical POV-Ray users. There may be an argument (especially in a jurisdiction where the AGPL is binding on non-distributors -- basically jurisdictions that enforce shrinkwrap EULAs) that these are, for some hypothetical user, "more restrictive" than the old license, but for the ordinary POV-Ray user, it's substantially less restrictive in practice.
* This sort of thing was actually not uncommon in more-or-less open-source software from the '80s and early '90s, for a couple reasons. First, the lack of established licenses to use (the 3-clause BSD didn't exist till '99, and the GPL wasn't well-known beyond in the UNIX community until Linux became popular) meant people were making up their own licenses, perhaps without thinking through all the implications. Second, before home internet access was wide-spread, users of home computers shared software via a hodgepodge of BBSes and sneakernet, so the risk of someone receiving a modified version, finding a bug or limitation due to the modifications, and not having the ability to simply download the original version was not the far-fetched silliness it is today. While I think, even under the conditions of the early '90s, the freedom to distribute modified versions should outweigh the benefit of "protecting" users from problems with those modifications, a lot of people didn't.
Bobby was a cowboy. Bobby was a cracksman, a burglar, casing mankind's extended electronic nervous system, rustling data and credit in the crowded matrix, monochrome nonspace where the only stars are dense concentrations of information, and high above it all burn corporate galaxies and the cold spiral arms of military systems.
So, if this stands does this mean it's lawful for Google to make the full text available of these books, or not?
From TFS:
Judge Chin also felt that it was impossible to use Google's scanned material, either for making full copies, or for reading the books, so that it did not compete with the books themselves.
If Google were to make the full text available, this ruling obviously wouldn't apply.
I'd guess he got a plastic framework to establish correct parabolic figure and a correctly-positioned mounting point to locate the feed antenna at the focus, and then covered it with metal foil, mesh, or wires for reflectivity.
Also, as soon as some high school student prints a gun with the 3D printer, that'll go away.
Yes, just like metal shop went away because students built zip guns (and some "real", if primitive, guns)? Oh, wait, that happened, but high school metal shop only (mostly) went away once, as a culture, we decided that being a pencil-pushing office drone is generally a desirable job, but the dirty work of manufacturing products is an undesirable job. Nobody in rich school districts wants the school to waste Johnny's time teaching him to work with his hands when he'll never need that (we know he'll have a better career than that), and poor districts don't have funds for a shop if they wanted it.
Yeah, some kids will get hold of the liberator (or some descendant or alternative design) STL files and sneak one through. But being kids trying to build a gun in shop class, rather than attention-seeking activists, they'll try not to get caught, so I think we have a while before such a build is both sufficiently (1) well-documented and (2) consequence-laden (ideally: the gun blows up during test-firing and hurts an innocent bystander with no (documented) connection to the gun build -- second-best: the gun works as designed and is used in a crime) to make that hype-dripping news story needed; I think it's likely to go away due to 3D printers becoming more-or-less ubiquituous in homes and therefore boring before that happens.
From TFA, it stated that the defendants had files with the same hash value as known kiddy porn files. Now I know a hash collision is unlikely, but by its very nature it is possible. Since they did not download the file, how can they claim to have probable cause? That's kind of scary...
Hmmm....
hash collision is unlikely
claim to have probable cause
I wonder if there's a reason it's called "probable cause" instead of "absolutely proven cause", and why it legally has a different standard of (un)certainty than needed for conviction?
If google had never lied willingly then they can get the benefit of the dought . But Google has long past the benefit of the dought lying and getting caught and fined many time.
Are you suggesting Google is doughty, but unable to benefit from their "fearless resolution"?
The sane thing to do is absolutely to not use them at all, unless you absolutely need to connect to some network whose administrator you are unable to knock the requisite sense into, in which case the best recourse is for the OS to not automatically probe for them, but rather to require you to manually trigger probing and connection when you actually need to connect to the hidden-ssid network. Unfortunately, I don't know of a single OS that does this correct behavior by default for hidden-SSID networks, and AFAICT there's no way to make Android do it at all.
I know of no such tools on Android -- which is not to say that there are none, I didn't really look. I think it might be as simple (given root access) as grepping/data/misc/wifi/wpa_supplicant.conf (or the equivalent file, sometimes it's located or named differently) for scan_ssid=1 or so, but I haven't looked into it.
I discovered the issue by seeing the probe requests pop up in kismet on my laptop, then googled about to figure out why Android was treating all my networks as hidden. Upon understanding it, and after a brief imprecatory interlude, I just wiped out all network definitions in my tablet, copied all the SSIDs and encryption credentials to a text file which I stored on the tablet, and redefined each network next time I was within range of it. Ugly, but as long as I only have to do it once, easier than casting about for an app or for the information to poke at it myself (at the time, I wasn't even aware android used a more-or-less standard wpa_supplicant rather than some completely home-grown thing).
I do live in the US, but I'm fortunate enough to live where T-mobile coverage is good, and the only smartphones I've ever had were Nokia Meego/Maemo hacktoys, an N900 and an N9; since the N9 died I've been getting by with larger devices (a couple tablets and a UMPC) + a dumbphone serving as bluetooth modem. I've never used Verizon, and though I realized they were evil, I didn't realize they were that evil. (Actually, I wasn't really sure it was possible to be that evil...) My condolences to those that have to put up with that.
This shouldn't be true. (Note, I'm not particularly familiar with the CDMA family of protocols, but some assumptions seem pretty reasonable.)
I assume you mean because Verizon uses CDMA instead of GSM, so there's no timing-advance value, so you don't get a distance-from-tower measure. Which is true, and means you'll never get anything like the accuracy from GSM.
However, CDMA networks still have to do handoffs when moving from one cell to another, so it seems to me the mobile terminal must (1) be aware of more than one tower to decide which one to handoff to, and (2) have some measure of signal strength to decide when to handoff. One can easily improve on "location of associated tower" by simply averaging (in some sense) the positions of all currently-observed towers. And while it still won't be real accurate, you should get a further improvement by considering the signal strength (possibly in conjunction with a database of EIRP for each tower) as a proxy for distance, and weighting the average accordingly.
If there's some reason this can't be done, I'm curious to know what it is.
AIUI, Android uses a heuristic to classify networks as hidden or non-hidden. If no hidden networks are defined, your device passively listens until it hears a beacon from a known network, and won't transmit anything till then. If one or more hidden networks are defined, it will periodically query all hidden networks, wasting a bit of battery life and conveniently transmitting both your current MAC and your list of known hidden-SSID networks to any 802.11 radios that happen to be listening (thus enabling a sufficiently widespread network of APs to track your position).
The heuristic is simple. If the network's ESSID shows up in the scanned list (which only happens if it's not in fact hidden-SSID) and you attempt to connect from the list, then fill in encryption values, etc., it's classified as non-hidden. If, however, you select "Add network..." (or whatever it's called in your particular version of android) and manually enter the ESSID as well as other parameters, it gets flagged as a hidden-SSID.
The reason this is broken: Say you just got a new Android tablet, and already have SSID and encryption parameters for some networks (belonging to parents, acquaintances, or anywhere else you might visit and use the wifi) saved on your old phone/MID/laptop. You might very reasonably attempt to define these networks on your tablet while sitting at home, with none of the networks in sight... so you choose "Add network", and add one, repeat until they're all in there. The result, stupidly enough, is that Android decides those networks are all hidden-ssid, and thus goes around querying them everywhere you go. Worst, unless you habitually fire up kismet and have a look at what your tablet is sending you'll never know it, because Android is apparently designed by disciples of the GNOME crew who've internalized the "options are the enemy" philosophy.
The right answer, of course, is to have a "Non-standards-conforming hidden-SSID network" checkbox in the settings, which defaults to checked when adding a network manually, so that people like me can uncheck it when deliberately configuring a standards-conforming network from out of sight. The slightly-less-right, but user-friendlier, option would be having that checkbox only appear when editing an already-defined network (not when defining a new one), to prevent morons accidentally unchecking it when defining a hidden-SSID network. The WRONG answer is to make it a secret property whose value is set when the network is first defined, is unsettable thereafter, and is entirely unreadable from the UI, but changes how things work behind the scenes.
(The user-unfriendly answer is to not support hidden-SSID networks at all, since they're a stupid idea that no knowledgeable and sane person would configure that way, and the best way to make the less-knowledgable clean up their act (can't do much for the insane) is to make their shiny new phone fail to connect until they fix their AP configuration. (One hopes that within a few weeks, googling "why won't Android connect to my wifi" will direct the unfortunate to an invective-laden screed explaining just how dumb hidden-SSID is, and how you can and should turn it off with step-by-step directions for the most common routers' configuration pages.) While I have a certain attraction to the LARTiness of this, I'm not really BOFH enough to seriously recommend it...)
I'm not sure how to display a link in slashdot, but I'll try again:
The same way you "display a link" anywhere else using html.
Type this: <a href="http://all-the-numbers.com/credit-cards.html">credit card list</a> and get this: credit card list
It really doesn't get simpler than that -- no square-bracket pseudo-html with incompletely defined semantics, no url autodetection that keeps grabbing stuff you don't want linkified, just html. (If you, somehow, have managed to remain ignorant of even that basic bit of html, then your options are to learn or GTFO.)
It's always remarkable what people do with 802.11, but a lot of it strikes me as a mediocre standard being (over)extended with gimmicks.
Out of the box it works well enough for simple use, but more complex use cases (distance, density, broader coverage) seem to involve a lot of complexity
Distance -- ye cannae change the laws of physics. You need one or more of: more power, more RF bandwidth, a higher gain antenna, or a coding system with less bits/s/Hz. Since you claimed power and bandwidth as problems below, I'll address them in a minute. You've already written off directional antennas as "gimmicks", and 802.11b already includes coding as low as 1Mb/s -- I don't think it's really worth putting even lower bitrates in the standard just so people can make >1 km links without having to spend $20 on a directional antenna. Density -- this one is legitimately improvable by abandoning CSMA-CD (probably in favor of CDMA), but that's a big and complicating change to the standard to improve the minority of cases that actually have high density. I'd be receptive, in theory, but in practice, there's other ways to accomodate the few cases where this would be helpful, and I'm not sure how well you could make a CDMA-based WiFi standard interoperate with 802.11 WiFi in the same band (aside from just having two separate radios), and that sort of interoperability (like the way 802.11g supported 802.11b devices) is essential to getting the new standard phased in. Other options (both commercially deployed already) are either TDMA-ish coordination amongst APs (which is an ugly gimmick, but does work, and importantly works with unmodified clients, only adding complexity to the infrastructure) or curtailing physical size of each AP's domain with directional antennas (as in TFA, again only requires changing infrastructure, and only in those cases where density is problematically high -- and it's not an ugly gimmick in any way I can see.) Broader Coverage -- TANSTAAFL; this is the same as Distance, except you can't even use higher gain antennas.
to make up for the overall weakness of the standard (limited channel selection, radio power, etc).
Seriously? those are your weaknesses? Not CSMA-CD? Well, OK... Limited channel selection -- turns out, the 2.4GHz band is pretty tiny and sucktastic. That's a function of the band, not the radio protocol, and nothing running in the 2.4GHz band is going to do a whole lot better with it than 802.11n does. However, this problem can be (and, it turns out has been) solved without abandoning 802.11, by just picking a different band. Behold, the 5GHz band used with 802.11a/n (and 802.11ac). Loads of non-overlapping channels! Radio power -- seriously? Because apartment buildings don't have enough trouble with APs on the same channel screaming over each other? We'll just make them all louder? Seriously, there's nothing really wrong with increasing the power limits, but it solves very nearly zero problems. The only cases where you really want more power is long-distance links, which are a tiny minority anyway, and the difference there will usually be between an expensive very-high-gain antenna, and a slightly less expensive moderately-high-gain antenna. There's very little that an ordinary AP, with an ordinary antenna, can almost do, and thus could do if the legal limit was 5 or 10dB more.
Are there any changes on the horizon to generate new standards that would fix this? Such as designs tailored to high-density environments (hundreds or thousands of clients off a single radio), greater channel selections, better distance capabilities, etc?
Well, 802.11ac will only support 5 GHz band, thus putting 2.4GHz behind us once and for all (which 802.11n failed to do), but it won't do much for high-density or long distance. But it's still part of 802.11, not a "new standard", because there's really not near as much wrong with 802.11 as you seem to think.
The directional antenna on AP A only helps AP A on receive, not transmit.
However, there's substantial benefits in both receive and transmit when you change all the antennas from omnis to patches: The directional antennas on APs B, C, D and E prevent their transmissions from interfering with AP A's transmissions to AP A's clients, and likewise the directional antenna on A helps B, C, D, and E.
It is a PASSIVE microstrip patch antenna. The gain adds to the TX as well as the RX.
The law doesn't care what sort of antenna it is -- the law specifies a maximum EIRP, and if you're already at that EIRP with a 6dB omni, your legal options are either (1) don't use a 12dB patch or (2) reduce your transmit power by 6dB to have the same EIRP.
In the US, at least, the FCC recognizes the benefit of highly directional antennas in that they reduce interference with other networks in the same channel, in every direction except where they're pointed, and therefore has established a "reward" for using them by permitting more EIRP with higher-gain directional antennas (ISTR for each 3dB of antenna gain, you get 1 dB more EIRP allowed, so you only have to decrease tx power by 2dB -- or something like that).
However, this only applies to fixed point-to-point links -- an AP with multiple portable/mobile clients doesn't count, and has a fixed maximum EIRP, just like in Europe, no matter what antenna you use.
That's not a one-time pad if you use it more than one time. It's extremely insecure to use a one-time pad twice.
Er, yeah. I actually did know that, considering it's right there in the name.
I was trying (and from both your reply and the downmod, obviously failing) to point out in a humorous way that it's not inherently a bad property for an algorithm as per GP, but rather any system including an algorithm with that property must prevent the same (or related) keys from being used for encrypting different files or different versions of the same file. (Of course, as applied to "rsyncrypto", it comes down to the same thing, since it depends on not rekeying.)
The head never moves, the disk spins under it. Putting a wing shape on the head wouldn't do anything.
It's too bad the disk doesn't drag some air along with it as it spins. If there was a layer of moving air along the boundary between the solid and gas, the heads could fly in that region.
It's a problem with SOME approaches to incremental backups. As you also said:
> then do an rsync into that incremental backup with --ignore-times
That's one way to do incremental without the "corrupt forever" problem, it works as one type of validation.
OK, I haven't actually used btrfs (or any other fs with similar snapshot/CoW capabilities), so I may be missing something in that case. But at least with rdiff-backup and such, and in my understanding with btrfs snapshots, too, what I was talking about converts the latest incremental backup into a full backup -- all the hardlinks for unchanged files get replaced with new copies, so you now have the extra disk consumption etc. associated with a full backup.
So incremental can be done without that problem.
But even though what I said doesn't do this, now that you say that, I realize you can do all incremental backups, and periodically use rsync to validate without the disk consumption of a full backup. The solution is to use not --ignore-times (which "transfers" each file whether it needs it or not) but --checksum (which hashes each file, and compares the hash to decide whether or not to "transfer" the file). This still reads back every file from disk, and thus catches any corrupted data, but doesn't take up extra disk space by duplicating uncorrupted files.
I think he actually meant the oxygen tank to allow it to make an insertion burn once it's in space. Y'know, space, where nothing burns unless you bring your own oxidizer?
Slashdot Mirror
The grid tie fee would have to be a lot more than $4.90/month to make the batteries look economical. Have you priced an off-the-grid system? Have you tried living on one? It either requires major lifestyle changes, a truly immense investment in panels and batteries (plus ongoing maintenance costs for the batteries) or a generator that will be running more often than you'd like, burning fossil fuels less efficiently than a big plant would. Anybody who buys batteries in response to this policy is cutting off their nose to spite their face.
It's not as simple as you're trying to make it. Adding batteries is not the same as "off-the-grid". In some places, a single meter is used, and the net power consumption is charged at retail rate. In other places, two meters are used; one measures power consumed from the grid, which is charged at retail rate, the other measures power generated, which is credited at wholesale rate. For single-meter systems, batteries are pointless aside from off-grid capability (thus I suspect you may have been thinking about these); for the two-meter systems, though, they can make sense.
Consider a simplified model: the solar panel generates 1 kW from 0600 to 1800, and the only power consumption is lighting, which consumes 1 kW from 1800 to 0600. With a single meter, the meter runs forward 12 kWh every night, then rolls back those same 12 kWh the next day. Net consumption, zero kWh, so why would you buy a battery? You wouldn't! Not only will it not save you anything, it'll actually cost you, because it takes more energy to charge than you recover on discharge -- so now your net consumption is positive.
But with two meters, suppose the wholesale pricing is 3c/kWh, while the retail pricing is 12c/kWh. Your consumption meter racks up 12 kWh a night, and your generation meter racks up 12 kWh a day. You pay $1.44 a day, minus $0.36 a day for your generation, or $1.08/day.
Now suppose you add 1 kWh of battery storage with 50% round trip efficiency (so it takes 2 kWh to charge, but you only get 1 kWh on discharge) -- now you're consuming 11kWh for $1.32/day, and generating 10kWh for $0.30/day -- your power bill decreases from $1.08/day to $1.02/day!
Better yet, if you can afford it, you'll buy a whole 6kWh of battery, and your solar panel will spend all day charging it, and it will power your lights for 6 hours.* Now your consumption meter only shows up 6 kWh/day ($0.72/day), and your generation meter shows nothing! Now it may or may not make economic sense to buy this battery -- you're saving 36 cents a day under our assumptions, but the battery system may cost more or less than the actual savings depending on the relationship of actual battery system prices with actual electric prices (both wholesale and retail), the actual round-trip efficiency, and the relationship of your real-world system (where both generation and loads vary day to day) to the model used here. But for some people, this is likely to come out very close to break-even, to the point where the prospect of saving $5/month is enough to tip the scales. The big question is whether such a near-break-even outcome is typical enough that a large fraction of PV-equipped homes will find it profitable to buy batteries and lose the second meter. I don't think it is, so I agree with you as to the ultimate outcome, but I don't have numbers to back that up.
*Note this is not an off-grid system -- for that you'd either need lifestyle changes (like turning the lights out half the night), or doubling your solar panel and storage capacity, and that's with our criminally simplified model; once you factor in short, cloudy winter days and realistic loads, off-grid is something you really pay for, in $$$ or convenience, as you rightly pointed out.
I see a whole lot of ego on slashdot. This post is a great example. ... the supreme badass you believe yourself to be
Please read what I wrote. I didn't say I would whup any ass whatsoever; in fact I wouldn't, for a number of reasons, including that I think physical violence would be an overreaction, that I have somewhat limited ass-whupping skills, and perhaps most importantly that I'm in the habit of providing my own entertainment (on the rare occasions I fly), so I'd likely not even notice. I was merely suggesting a reasonably plausible (and to my mind comical) outcome for a would-be terrorist who tries to bring down the plane, but only succeeds in killing the in-flight movie for everyone in coach.
I believe it's customary at this point to suggest that your inference of an internet tough-guy attitude in my post is a case of projecting your own attitudes on others, so consider it suggested pro forma. ;)
How the fuck would you even know if someone plugged 90V into the headphone jack,
Well, if somebody's fiddling about with a 30-cell pack of CR123s, it would likely be noticeable to some of the people sitting near them. (Note that this discussion is in the context of "using stuff bought in the secure zone to build weapons in the secure zone", so it's not likely that such a field-assembled battery pack would be disguised or even particularly tidily wrapped up -- it may have the sort of exposed wiring that makes a lot of people think "bomb"!) If the inflight movie cuts out exactly when they plug anything, but especially such an unusual/suspicious gizmo, into the armrest, those nearest them might well notice the correlation, rightly or wrongly infer causality, and raise a hue and cry.
Might not happen that way, but it might, which is all I ever claimed.
How about chaining lithium batteries together to make a tazer or device to overload the planes circuits?
Tasers have an open-circuit voltage of 50kV IIRC. Combining seventeen thousand CR123 cells seems like it might result in a slightly unwieldy weapon.
As for overloading the plane's circuits... which circuits? As a passenger, you have access to the inflight entertainment system, maybe some power outlets (28VDC or 110VAC), and that's about it. This isn't Star Trek, where an overload in holodeck 5 causes an explosion of sparks from the navigation console -- if you plug 90V or so into the headphone jack, you might fry your seat's electronics only, or you might take out the whole entertainment system (and get your ass whupped shoebomber-style), but you won't take out anything essential for flight.
the electricity to charge it (in the USA) is 68% fossil fuel derived.
Which is 32% less than ICE cars. And a lot of the 68% is from coal, which (1) we have a lot more of than oil and (2) is hard to use in ICEs (yeah, gassification's an option) but easy to use for electricity generation. It's not a renewable paradise or anything, but it's not half bad.
Software that 99.9% of us will never use has been re-licensed with an even more restrictive license.
You're not familiar with the old POV-Ray license, are you?
The original license didn't let you even distribute a modified version. You had to distribute your changes as a patchset, so anyone wanting to use your version could get the official code, patch it with your changes, then compile it.* So GPLv2, despite all its restrictions, is less restrictive!
Now this is AGPLv3, not GPLv2, but the differences (A=restrictions on using it to provide a network service, v3=patent-defense and tivoisation stuff) are simply not relevant to typical POV-Ray users. There may be an argument (especially in a jurisdiction where the AGPL is binding on non-distributors -- basically jurisdictions that enforce shrinkwrap EULAs) that these are, for some hypothetical user, "more restrictive" than the old license, but for the ordinary POV-Ray user, it's substantially less restrictive in practice.
* This sort of thing was actually not uncommon in more-or-less open-source software from the '80s and early '90s, for a couple reasons. First, the lack of established licenses to use (the 3-clause BSD didn't exist till '99, and the GPL wasn't well-known beyond in the UNIX community until Linux became popular) meant people were making up their own licenses, perhaps without thinking through all the implications. Second, before home internet access was wide-spread, users of home computers shared software via a hodgepodge of BBSes and sneakernet, so the risk of someone receiving a modified version, finding a bug or limitation due to the modifications, and not having the ability to simply download the original version was not the far-fetched silliness it is today. While I think, even under the conditions of the early '90s, the freedom to distribute modified versions should outweigh the benefit of "protecting" users from problems with those modifications, a lot of people didn't.
Quine, Bobby.
Bobby was a cowboy. Bobby was a cracksman, a burglar, casing mankind's extended electronic nervous system, rustling data and credit in the crowded matrix, monochrome nonspace where the only stars are dense concentrations of information, and high above it all burn corporate galaxies and the cold spiral arms of military systems.
So, if this stands does this mean it's lawful for Google to make the full text available of these books, or not?
From TFS:
Judge Chin also felt that it was impossible to use Google's scanned material, either for making full copies, or for reading the books, so that it did not compete with the books themselves.
If Google were to make the full text available, this ruling obviously wouldn't apply.
I'd guess he got a plastic framework to establish correct parabolic figure and a correctly-positioned mounting point to locate the feed antenna at the focus, and then covered it with metal foil, mesh, or wires for reflectivity.
Also, as soon as some high school student prints a gun with the 3D printer, that'll go away.
Yes, just like metal shop went away because students built zip guns (and some "real", if primitive, guns)? Oh, wait, that happened, but high school metal shop only (mostly) went away once, as a culture, we decided that being a pencil-pushing office drone is generally a desirable job, but the dirty work of manufacturing products is an undesirable job. Nobody in rich school districts wants the school to waste Johnny's time teaching him to work with his hands when he'll never need that (we know he'll have a better career than that), and poor districts don't have funds for a shop if they wanted it.
Yeah, some kids will get hold of the liberator (or some descendant or alternative design) STL files and sneak one through. But being kids trying to build a gun in shop class, rather than attention-seeking activists, they'll try not to get caught, so I think we have a while before such a build is both sufficiently (1) well-documented and (2) consequence-laden (ideally: the gun blows up during test-firing and hurts an innocent bystander with no (documented) connection to the gun build -- second-best: the gun works as designed and is used in a crime) to make that hype-dripping news story needed; I think it's likely to go away due to 3D printers becoming more-or-less ubiquituous in homes and therefore boring before that happens.
From TFA, it stated that the defendants had files with the same hash value as known kiddy porn files. Now I know a hash collision is unlikely, but by its very nature it is possible. Since they did not download the file, how can they claim to have probable cause? That's kind of scary...
Hmmm....
hash collision is unlikely
claim to have probable cause
I wonder if there's a reason it's called "probable cause" instead of "absolutely proven cause", and why it legally has a different standard of (un)certainty than needed for conviction?
If google had never lied willingly then they can get the benefit of the dought . But Google has long past the benefit of the dought lying and getting caught and fined many time.
Are you suggesting Google is doughty, but unable to benefit from their "fearless resolution"?
The sane thing to do is absolutely to not use them at all, unless
you absolutely need to connect to some network whose administrator you are unable to knock the requisite sense into, in which case the best recourse is for the OS to not automatically probe for them, but rather to require you to manually trigger probing and connection when you actually need to connect to the hidden-ssid network. Unfortunately, I don't know of a single OS that does this correct behavior by default for hidden-SSID networks, and AFAICT there's no way to make Android do it at all.
I know of no such tools on Android -- which is not to say that there are none, I didn't really look. I think it might be as simple (given root access) as grepping /data/misc/wifi/wpa_supplicant.conf (or the equivalent file, sometimes it's located or named differently) for scan_ssid=1 or so, but I haven't looked into it.
I discovered the issue by seeing the probe requests pop up in kismet on my laptop, then googled about to figure out why Android was treating all my networks as hidden. Upon understanding it, and after a brief imprecatory interlude, I just wiped out all network definitions in my tablet, copied all the SSIDs and encryption credentials to a text file which I stored on the tablet, and redefined each network next time I was within range of it. Ugly, but as long as I only have to do it once, easier than casting about for an app or for the information to poke at it myself (at the time, I wasn't even aware android used a more-or-less standard wpa_supplicant rather than some completely home-grown thing).
Ouch! Thanks for the info.
(I take it that you don't live in the US.)
I do live in the US, but I'm fortunate enough to live where T-mobile coverage is good, and the only smartphones I've ever had were Nokia Meego/Maemo hacktoys, an N900 and an N9; since the N9 died I've been getting by with larger devices (a couple tablets and a UMPC) + a dumbphone serving as bluetooth modem. I've never used Verizon, and though I realized they were evil, I didn't realize they were that evil. (Actually, I wasn't really sure it was possible to be that evil...) My condolences to those that have to put up with that.
This shouldn't be true. (Note, I'm not particularly familiar with the CDMA family of protocols, but some assumptions seem pretty reasonable.)
I assume you mean because Verizon uses CDMA instead of GSM, so there's no timing-advance value, so you don't get a distance-from-tower measure. Which is true, and means you'll never get anything like the accuracy from GSM.
However, CDMA networks still have to do handoffs when moving from one cell to another, so it seems to me the mobile terminal must (1) be aware of more than one tower to decide which one to handoff to, and (2) have some measure of signal strength to decide when to handoff. One can easily improve on "location of associated tower" by simply averaging (in some sense) the positions of all currently-observed towers. And while it still won't be real accurate, you should get a further improvement by considering the signal strength (possibly in conjunction with a database of EIRP for each tower) as a proxy for distance, and weighting the average accordingly.
If there's some reason this can't be done, I'm curious to know what it is.
AIUI, Android uses a heuristic to classify networks as hidden or non-hidden. If no hidden networks are defined, your device passively listens until it hears a beacon from a known network, and won't transmit anything till then. If one or more hidden networks are defined, it will periodically query all hidden networks, wasting a bit of battery life and conveniently transmitting both your current MAC and your list of known hidden-SSID networks to any 802.11 radios that happen to be listening (thus enabling a sufficiently widespread network of APs to track your position).
The heuristic is simple. If the network's ESSID shows up in the scanned list (which only happens if it's not in fact hidden-SSID) and you attempt to connect from the list, then fill in encryption values, etc., it's classified as non-hidden. If, however, you select "Add network..." (or whatever it's called in your particular version of android) and manually enter the ESSID as well as other parameters, it gets flagged as a hidden-SSID.
The reason this is broken: Say you just got a new Android tablet, and already have SSID and encryption parameters for some networks (belonging to parents, acquaintances, or anywhere else you might visit and use the wifi) saved on your old phone/MID/laptop. You might very reasonably attempt to define these networks on your tablet while sitting at home, with none of the networks in sight... so you choose "Add network", and add one, repeat until they're all in there. The result, stupidly enough, is that Android decides those networks are all hidden-ssid, and thus goes around querying them everywhere you go. Worst, unless you habitually fire up kismet and have a look at what your tablet is sending you'll never know it, because Android is apparently designed by disciples of the GNOME crew who've internalized the "options are the enemy" philosophy.
The right answer, of course, is to have a "Non-standards-conforming hidden-SSID network" checkbox in the settings, which defaults to checked when adding a network manually, so that people like me can uncheck it when deliberately configuring a standards-conforming network from out of sight. The slightly-less-right, but user-friendlier, option would be having that checkbox only appear when editing an already-defined network (not when defining a new one), to prevent morons accidentally unchecking it when defining a hidden-SSID network. The WRONG answer is to make it a secret property whose value is set when the network is first defined, is unsettable thereafter, and is entirely unreadable from the UI, but changes how things work behind the scenes.
(The user-unfriendly answer is to not support hidden-SSID networks at all, since they're a stupid idea that no knowledgeable and sane person would configure that way, and the best way to make the less-knowledgable clean up their act (can't do much for the insane) is to make their shiny new phone fail to connect until they fix their AP configuration. (One hopes that within a few weeks, googling "why won't Android connect to my wifi" will direct the unfortunate to an invective-laden screed explaining just how dumb hidden-SSID is, and how you can and should turn it off with step-by-step directions for the most common routers' configuration pages.) While I have a certain attraction to the LARTiness of this, I'm not really BOFH enough to seriously recommend it...)
There _are_ some rather worrying reports floating around on Steve's agenda.
http://www.droid-life.com/2013/07/29/cyanogenmod-founder-contemplating-abolishing-root-requirements-for-custom-roms/
https://plus.google.com/106978520009932034644/posts/L8FJkrcahPs
http://www.landofdroid.com/2013/more-on-whats-going-on-at-cyanogenmod/
We'll see.
lrn2html, dumbass.
http://www.droid-life.com/2013/07/29/cyanogenmod-founder-contemplating-abolishing-root-requirements-for-custom-roms/
https://plus.google.com/106978520009932034644/posts/L8FJkrcahPs
http://www.landofdroid.com/2013/more-on-whats-going-on-at-cyanogenmod/
And there are no crazy people or murderers. Only GUNMEN.
Who the hell do you think I am?
I'm not sure how to display a link in slashdot, but I'll try again:
The same way you "display a link" anywhere else using html.
Type this:
<a href="http://all-the-numbers.com/credit-cards.html">credit card list</a>
and get this:
credit card list
It really doesn't get simpler than that -- no square-bracket pseudo-html with incompletely defined semantics, no url autodetection that keeps grabbing stuff you don't want linkified, just html. (If you, somehow, have managed to remain ignorant of even that basic bit of html, then your options are to learn or GTFO.)
It's always remarkable what people do with 802.11, but a lot of it strikes me as a mediocre standard being (over)extended with gimmicks.
Out of the box it works well enough for simple use, but more complex use cases (distance, density, broader coverage) seem to involve a lot of complexity
Distance -- ye cannae change the laws of physics. You need one or more of: more power, more RF bandwidth, a higher gain antenna, or a coding system with less bits/s/Hz. Since you claimed power and bandwidth as problems below, I'll address them in a minute. You've already written off directional antennas as "gimmicks", and 802.11b already includes coding as low as 1Mb/s -- I don't think it's really worth putting even lower bitrates in the standard just so people can make >1 km links without having to spend $20 on a directional antenna.
Density -- this one is legitimately improvable by abandoning CSMA-CD (probably in favor of CDMA), but that's a big and complicating change to the standard to improve the minority of cases that actually have high density. I'd be receptive, in theory, but in practice, there's other ways to accomodate the few cases where this would be helpful, and I'm not sure how well you could make a CDMA-based WiFi standard interoperate with 802.11 WiFi in the same band (aside from just having two separate radios), and that sort of interoperability (like the way 802.11g supported 802.11b devices) is essential to getting the new standard phased in.
Other options (both commercially deployed already) are either TDMA-ish coordination amongst APs (which is an ugly gimmick, but does work, and importantly works with unmodified clients, only adding complexity to the infrastructure) or curtailing physical size of each AP's domain with directional antennas (as in TFA, again only requires changing infrastructure, and only in those cases where density is problematically high -- and it's not an ugly gimmick in any way I can see.)
Broader Coverage -- TANSTAAFL; this is the same as Distance, except you can't even use higher gain antennas.
to make up for the overall weakness of the standard (limited channel selection, radio power, etc).
Seriously? those are your weaknesses? Not CSMA-CD? Well, OK...
Limited channel selection -- turns out, the 2.4GHz band is pretty tiny and sucktastic. That's a function of the band, not the radio protocol, and nothing running in the 2.4GHz band is going to do a whole lot better with it than 802.11n does. However, this problem can be (and, it turns out has been) solved without abandoning 802.11, by just picking a different band. Behold, the 5GHz band used with 802.11a/n (and 802.11ac). Loads of non-overlapping channels!
Radio power -- seriously? Because apartment buildings don't have enough trouble with APs on the same channel screaming over each other? We'll just make them all louder? Seriously, there's nothing really wrong with increasing the power limits, but it solves very nearly zero problems. The only cases where you really want more power is long-distance links, which are a tiny minority anyway, and the difference there will usually be between an expensive very-high-gain antenna, and a slightly less expensive moderately-high-gain antenna. There's very little that an ordinary AP, with an ordinary antenna, can almost do, and thus could do if the legal limit was 5 or 10dB more.
Are there any changes on the horizon to generate new standards that would fix this? Such as designs tailored to high-density environments (hundreds or thousands of clients off a single radio), greater channel selections, better distance capabilities, etc?
Well, 802.11ac will only support 5 GHz band, thus putting 2.4GHz behind us once and for all (which 802.11n failed to do), but it won't do much for high-density or long distance. But it's still part of 802.11, not a "new standard", because there's really not near as much wrong with 802.11 as you seem to think.
The directional antenna on AP A only helps AP A on receive, not transmit.
However, there's substantial benefits in both receive and transmit when you change all the antennas from omnis to patches: The directional antennas on APs B, C, D and E prevent their transmissions from interfering with AP A's transmissions to AP A's clients, and likewise the directional antenna on A helps B, C, D, and E.
It is a PASSIVE microstrip patch antenna. The gain adds to the TX as well as the RX.
The law doesn't care what sort of antenna it is -- the law specifies a maximum EIRP, and if you're already at that EIRP with a 6dB omni, your legal options are either (1) don't use a 12dB patch or (2) reduce your transmit power by 6dB to have the same EIRP.
In the US, at least, the FCC recognizes the benefit of highly directional antennas in that they reduce interference with other networks in the same channel, in every direction except where they're pointed, and therefore has established a "reward" for using them by permitting more EIRP with higher-gain directional antennas (ISTR for each 3dB of antenna gain, you get 1 dB more EIRP allowed, so you only have to decrease tx power by 2dB -- or something like that).
However, this only applies to fixed point-to-point links -- an AP with multiple portable/mobile clients doesn't count, and has a fixed maximum EIRP, just like in Europe, no matter what antenna you use.
That's not a one-time pad if you use it more than one time. It's extremely insecure to use a one-time pad twice.
Er, yeah. I actually did know that, considering it's right there in the name.
I was trying (and from both your reply and the downmod, obviously failing) to point out in a humorous way that it's not inherently a bad property for an algorithm as per GP, but rather any system including an algorithm with that property must prevent the same (or related) keys from being used for encrypting different files or different versions of the same file. (Of course, as applied to "rsyncrypto", it comes down to the same thing, since it depends on not rekeying.)
The head never moves, the disk spins under it. Putting a wing shape on the head wouldn't do anything.
It's too bad the disk doesn't drag some air along with it as it spins. If there was a layer of moving air along the boundary between the solid and gas, the heads could fly in that region.
It's a problem with SOME approaches to incremental backups. As you also said:
> then do an rsync into that incremental backup with --ignore-times
That's one way to do incremental without the "corrupt forever" problem, it works as one type of validation.
OK, I haven't actually used btrfs (or any other fs with similar snapshot/CoW capabilities), so I may be missing something in that case. But at least with rdiff-backup and such, and in my understanding with btrfs snapshots, too, what I was talking about converts the latest incremental backup into a full backup -- all the hardlinks for unchanged files get replaced with new copies, so you now have the extra disk consumption etc. associated with a full backup.
So incremental can be done without that problem.
But even though what I said doesn't do this, now that you say that, I realize you can do all incremental backups, and periodically use rsync to validate without the disk consumption of a full backup. The solution is to use not --ignore-times (which "transfers" each file whether it needs it or not) but --checksum (which hashes each file, and compares the hash to decide whether or not to "transfer" the file). This still reads back every file from disk, and thus catches any corrupted data, but doesn't take up extra disk space by duplicating uncorrupted files.
I think he actually meant the oxygen tank to allow it to make an insertion burn once it's in space. Y'know, space, where nothing burns unless you bring your own oxidizer?