> kids learned programming by reading magazines and books.
As someone who was a teen in the 80s, I can say, "sort of". For books about Commodore 64-related topics in the mid-80s, you're kind of right. If you lived in a big city or a college town, you MIGHT have had access to good books about computers and programming (at least, if you were talking about the Commodore 64, Apple II, or MAYBE "PC"). If you lived in a small town whose book store situation could be fully described as, "Waldenbooks and B. Dalton at the mall" and had an Amiga or Atari ST, probably not. Even for Macintosh, you weren't going to find anything that even vaguely resembled a book about Macintosh assembly language at a small-town mall bookstore... you'd have been lucky if you found a book or two about Hypercard, Macwrite, and MAYBE Pagemaker.
When I got to college, my university's library was almost as useless... I think the NEWEST book in the entire QA76.* section was 2 or 3 years old, and the only topics they seemed to have any interest in covering were Unix, PDP-11, and Cobol. If you were an 18-24 year old circa 1990 at a University that wasn't Standford or MIT (and thus had no access to anything that vaguely resembled a graphics workstation from SGI), books about Unix, PDP-11, and/or Cobol programming were about as interesting as... er... nothing, because they weren't interesting at all. Compared to an Amiga or high-end PC, a text terminal was an artifact from the stone age of computing.
Pre-Internet, even discovering the EXISTENCE of books about semi-niche topics was hard. At various points between 1986 and 1992, I made random stabs at ordering books with "Amiga" in the title based upon nothing more than what was on the microfiche of books you could special order at Waldenbooks and B. Dalton, and every single one of them ultimately ended up being money that was completely wasted. Decades later, I randomly tripped over scanned pdf copies of books that supposedly existed circa 1990 and 1991, and all I could think was, "Where the holy FUCK were those books back when I NEEDED them, and would have bought them in a heartbeat?" They sure as HELL didn't exist in small-town mall bookstores.
Things weren't a whole lot better on the PC side. Circa 1992 and 1993, I spent MONTHS trying to figure out how to use linear memory addressing on a 486DX. A few years later, the answer was obvious... DOS4GW. At the time, though, even people who understood PC assembly language would just give me blank stares & say, "you HAVE to use 64k segments". I could stand on the roof in 1993 and scream, "what the fuck is 386enh mode, and how do I use it?" and get nothing but stony silence and weird stares. I knew it was possible (ever since the 386DX) to use linear addressing, but learning how to actually use it was another matter entirely.
Circa 1993, I would have literally KILLED for a copy of Richard Ferraro's book about VGA programming... had I even known it EXISTED (I think I first stumbled across a later edition sometime around 1995 or 1996).
That was the harsh reality of life back then. It was an information dark age. There was no Google. There was *barely* an "internet". Even if you had internet access, Usenet replies were (easily) overlooked, scrolled into history within a week or two, and were gone forever until the arrival of DejaNews YEARS later. All of the libraries I had access to in the 1980s and 1990s were basically worthless for books about computer-related topics... they all had really long purchasing cycles, took even LONGER to get purchased or donated books into circulation, and by the time any book made it to the shelves, it had probably been obsolete for years. It wasn't until the early 2000s that libraries really started to preemptively buy newly-released books about computer-related topics (from publishers regarded as generally producing high-quality books) and get them quickly placed on shelves before the books were obsolete. In my entire life prior to ~2000, I think I remember finding ONE useful book about pro
> In that case why wouldn't you just use local on device controls to adjust configuration?
Because lots of newer devices barely HAVE local on-device controls anymore. You're lucky to have real buttons for 'toggle power', 'cycle through inputs', 'volume up', 'volume down', 'menu', 'channel up/next', 'channel down/prev'. When you run into some really weird edge case, like 'old DVD that was authored with incorrect flags, so the aspect ratio and/or letterboxing is all fsck'ed up', you have to manually adjust the SD aspect ratio/zoom settings. They're something that you shouldn't have to worry about, and rarely do... but WHEN you do, it kind of sucks if you have to remember that the function was mapped to the button on the universal remote marked 'sleep' (or some other even more obscure function whose button you had to recycle, because there was no button on the universal remote explicitly labeled as 'SD Zoom/Aspect Ratio').
Of course, some universal remotes DO have buttons labeled for every conceivable function... and usually, those remotes have dozens and dozens of identical tiny buttons with labels that can't easily be read in dim light... or bright light, for that matter (Japanese remotes in particular are bad about this... consumers in Japan apparently LOVE having lots and lots of tiny little identical buttons in neat, orderly rows).
The problem with asking, "why not just use the original remote for things like that?" is the fact that the original remote is probably buried somewhere, and once you finally DO find it, the likelihood that its batteries are still good (after years of sitting unused, buried under assorted stuff) is low. Add 5-10 minutes to hunt down the right batteries (inevitably, you'll need 3 AAA batteries, and discover you have TWO AAA batteries and a crate of AA batteries). That's the benefit of being able to dig through the remote's LCD menu for those obscure functions... it spares you from having to hunt down the original remote, then go on a second hunt for batteries.
> What difference does it make if it's a soundbar or an AVR?
A soundbar is a very, very simplified and dumbed-down peripheral -- it's a single device, connected to a single source via a single cable, with a very limited range of constrained settings. In contrast, an AVR is a lot more open-ended and configurable, in terms of inputs, outputs, AND any processing done to the signals between the two. A really good soundbar is a net improvement over most built-in speakers on a TV, but has nowhere NEAR the capabilities of a good AVR with left, right, center, left-surround, right-surround, left-rear-surround, right-rear-surround, and one or two subwoofers. Since it's physically impossible to get true surround from a single soundbar, that itself eliminates ~70% of the settings and configurations you'd have to deal with when setting up and tweaking surround settings to optimize the setup for your room's inevitably-imperfect sonic environment.
My point was that a simple, lower-end consumer who buys a select few matched components and has relatively low expectations to begin with might have an easy setup experience with a cheap TV and soundbar from Walmart, but someone who demands at a minimum 5.1 surround with non-absurdly-undersized speakers and wants it tweaked to handle their room's audio characteristics is unlikely to be satisfied with that, and is likely to find CEC to be quite a bit more constraining (and buggy). CEC is the control system of tomorrow. And tomorrow is still quite far away if you're the kind of user who benchmarks his system, owns at least one analyzer, annoys his spouse and/or family and/or friends by insisting upon tweaking the settings for every movie to achieve perfection (when all THEY seemingly want to do is "watch the movie", and don't *care* if the surround timing sounds like it's a bit delayed on the rear-right channel in scene 23).
Last weekend, I was at Sawgrass Mills (a large outlet mall at the western edge of Fort Lauderdale). I have a Nexus 6P and use AT&T. According to the signal strength icon, I had perfect RF signal quality... and couldn't even ping 8.8.8.8 or access Google. I changed the settings to force 3G, and instantly everything worked perfectly.
This afternoon, I was at Pembroke Lakes Mall (in Pembroke Pines, southwestern Fort Lauderdale area). Same story. With LTE enabled, I supposedly had perfect connectivity, but couldn't access anything over the internet reliably. The moment I set the phone to force 3G, my problems went away.
Sure, it's probably the fault of AT&T and not LTE itself... but it still speaks poorly of a mode that seems to have a HUGE problem (at least, by default) dealing with use cases like "tower site adjacent to large regional mall the weekend before Christmas" that older modes can somehow handle just fine.
My point is that every US provider HAS coverage that's deficient in some respect.
LTE was developed for neat, orderly, well-planned & properly-executed networks. The harsh reality is, US networks are more variable in quality & a lot more adhoc.
In messy networks, CDMA (including HSPA+) is more robust & resilient, and tolerates a greater amount of chaos without breaking down.
That robustness comes at a price -- more power consumption and less efficient spectral efficiency. In places like Scandinavia and South Korea, LTE works extraordinarily well. In post-Hurricane Florida, or San Francisco on an average NIMBY-limited day, it has Issues.
With HSPA+, almost any capacity problem can be solved through brute force if you dump enough nanocells & femtocells into a problematic area until the problem sorts itself out. You can call it wasteful & you'd be right... but people bitch a lot more about efficient networks that hiccup & glitch than wasteful abundance that "just works anyway".
With LTE, you have to actually understand the problem & solve it deliberately. Both approaches have real world merit, but in the US, the approach that requires less coordination & planning is usually the one more likely to succeed.
LTE is unquestionably the future, especially as networks mature & early problems eventually get resolved... but in the early rag-tag days of inconsistent & compromised deployment, the leap from HSPA+ to LTE is not a consequence-free upgrade... it's "two steps forward, 1.7 to 2.4 steps backward (to the left or right, with an occasional spin)".
LTE might be more efficient, but HSPA+ still wins by pure brute force when you're in a moving vehicle speeding through an area at 80-150mph if you value uninterrupted realtime connectivity.
LTE's single-tower orientation causes other problems, too. After Hurricane Irma, there were a lot of dysfunctional LTE tower sites in Florida for several weeks due to backhaul problems. The problem was, sites with dysfunctional backhaul still acceptet connections. So your phone might connect to a dysfunctional tower & hold on to the connection, even if there's a second tower nearby that's working properly. With HSPA+, it's not a big deal... you'd connect to both towers, the one with working backhaul would carry the whole load, and the dysfunctional tower would just sit there and not interfere. With LTE, you'd have "5 bars, but no actual connectivity" (because it would be like a wi-fi access point that's plugged in, but is connected to a malfunctioning dsl/cable modem).
Put another way, LTE doesn't handle dysfunctional conditions as gracefully as HSPA+ does, even if it IS more efficient under ideal conditions. In a place like Florida where hurricanes happen every few years, ability to "just work" amidst malfunctioning & dysfunctional tower sites matters.
Sprint sucked, but WiMax WAS "4G", every bit as much as American LTE was "4G".
The main reason why Sprint's Wimax was inferior to Verizon's first stab at LTE was because of the frequency band it ran in. The latest iteration of LTE is better than Wimax was, but the FIRST generation of LTE was barely any different (in terms of bare-metal radio modulation) than Wimax (slightly more efficient encoding to make better use of RF energy, but it was more of a minor tweak than anything). If Sprint's Wimax had run at 700MHz instead of 3.5GHz, it would have been functionally no different from Verizon's first-generation LTE.
Sprint made their transition to LTE a thousand times worse than it had to be by allowing/requiring Samsung to make the Galaxy S3 LTE-only, instead of spending $5 more and building it with the pin-identical chip that could do Wimax too. If the S3 had been dual-mode (even if it required rebooting to switch between Wimax or LTE), it would have bought Sprint another year to gracefully transition... they could have left Wimax where it was, deployed LTE to markets with no Wimax, then switched Wimax to LTE after they'd given customers a year or two of dual-mode phones that could do either one.
Instead, Sprint ended up in a situation where their Wimax network became nearly useless almost overnight as (former) customers upgraded to new LTE-only phones, then returned them and left Sprint in disgust after realizing just HOW BAD Sprint's 3G network had become without having Wimax as a crutch to fall back on.
Personally, I was pissed when T-Mobile decided to go "all LTE" just for the sake of a marketing bullet point. HSPA+ might not be LTE, but in urban areas with dense tower deployment, HSPA+ is technically SUPERIOR to LTE (at least, LTE at the time it was deployed to replace HSPA+), especially if you're in a moving vehicle.
Unlike LTE, HSPA+ allows your phone to connect to MULTIPLE different towers & split your data between them (basically, like using a shotgun modem with PPP multilink). That comes in handy if you're in an area with dense tower deployment and in a fast-moving vehicle (like high-speed rail, or a car doing 80mph on a freeway) -- the phone can metaphorically swing like a monkey from tower/branch to tower/branch, always keeping one metaphorical hand on a tower/branch while the other reaches for the next so it's never COMPLETELY offline and disconnected. In contrast, LTE has "hard" disconnects -- the phone connects to exactly one tower at a time, and when it disconnects it has no data connectivity (or IP address) AT ALL until it establishes its next connection to a different tower.
This also means that HSPA+ can be a lot more aggressive about hunting for better connectivity... it can hedge its bets by remaining connected to its "best" known tower, while aggressively connecting around in search of a better one. In contrast, LTE tends to hang on until it literally can't sustain a connection at all, even if there's a "better" tower it COULD use instead... in order to "try out" that tower, it has to break its connection and do a hard switch to the new one... and if it's TOO aggressive about hunting for a better tower, you can end up with the kind of thrashing Sprint phones had back in the wimax era (if you were in an area where two wimax towers were in view, but BOTH were marginal, Sprint phones would thrash back and forth between them every few seconds... made worse by the fact that those phones ALSO shared components between wimax and wifi, so you couldn't use both simultaneously.)
In rural areas (and large parts of suburbia), it's kind of academic because there's probably only one tower in view at a time ANYWAY... but in areas with the tower density to support it properly, HSPA+ is arguably a step UP from LTE.
That said... I don't think AT&T ever actually HAD HSPA+. I know AT&T had HSDPA, and I'm pretty sure they were in the process of deploying HSUPA at some point, but AFAIK, AT&T quit upgrading 3G at some point before HSPA+ and decided to focus entirely on LTE... then started attacking T-Mobile for not being "all LTE".
Personally, if I'd been in charge at T-Mobile, I would have hit back hard at AT&T and run ads calling them "LTE Lemmings" for blindly chasing after buzzwords instead of pure technical merit. I would have shown happy T-Mobile customers on Acela (or in cars driving side by side on an open freeway) enjoying uninterrupted connectivity while frustrated AT&T and Verizon customers kept having their Facetime chats glitch and break up every couple of minutes when the phones moved too far from their past tower & had a second or two of network disruption while connecting to the next tower. Or worse, having their banking and VPN apps kicking them offline every few minutes because it detected an IP address change (go search old messages at XDA-developers.com & you can read about how people used to have to lock their phone to 3G to use it with a VPN or banking app when riding on Acela, because otherwise the IP address would keep changing every few minutes & they'd get logged out automatically).
IMHO, LTE was actually a technological step backwards. Most of the "benefits" people ascribe to "LTE" over HSPA+ have nothing to do with "4G", and EVERYTHING to do with "carriers used their best new frequency bands to deploy it". Had HSPA+ been deployed at 600 & 700MHz, with the same amount of fiber backhaul as LTE, the difference between HSPA+ and LTE would have been mostly an academic footnote. LTE does make some improvements to the way voi
Hmmm... that's interesting. I haven't actually tried using the dimmable ones with LCDs... I actually did a huge round of X10 replacements sometime around 2010 when I replaced all of my remaining dimmable/incandescent modules with 3-prong appliance-type modules (usually, in conjunction with a 6" extension cord and a 4w nightlight whose only purpose was to provide a constant resistive load to keep the modules from turning themselves on without actually going all the way and disabling the local power control feature.
The main issue I had with LED lights is that even the relay-equipped 3-prong appliance modules send a brief power pulse every few seconds (as far as I can tell, cutting the trace doesn't stop it from pulsing power through the bulb, it just makes the ASIC ignore the outcome so the module won't think you toggled the local power switch and turn itself back on), which causes the bulb to visibly flash. I guess now that you mention it, dimmable-type LCDs might actually BE compatible with the older incandescent/dimmable-type X10 controllers. I'm going to have to go dig out the box with the old dimmable/incandescent-type modules and try them:-)
I'm lucky in the signal area... once I put the X-10 crossover/bridge module on my dryer outlet a few years ago, all of my problems seemed to go away. If I can get the incandescent modules to work, that'll be great news... I have an Elk M1 home automation controller & security system and did a fair amount of programming circa 2013 to add lighting control using their M1-to-X10 bridge (so I could do things like call home, let the answering machine pick up while it eavesdrops, then remotely turn lights on and off).
I thought about switching to Z-wave or Insteon a couple of years ago, but Insteon's main appeal was cross-compatibility with X-10. If all the X10 gear is moot, Insteon's main selling point goes out the window.... and cost-wise, it's as expensive as Z-wave. Elk's Z-wave module was REALLY expensive, Z-wave switches and light modules were OUTRAGEOUSLY expensive, and reading the horror stories about interoperability between licensed Z-wave devices and generic "Zigbee, but not literally Z-wave" devices just turned me off of the whole thing. And then, right around the point when Z-wave devices started becoming halfway sane price-wise, the tsunami of "wi-fi" control modules arrived. I'll probably go with wi-fi eventually, but only when I'm satisfied that they're interoperable with standards that don't depend upon the continued existence and reliable operation of some vendor's cloud infrastructure that could vanish tomorrow & leave me with yet another collection of paperweights.
The appeal of Harmony remotes isn't being able to reprogram buttons... it's being able to reprogram buttons that have dynamic labels provided by the adjacent LCD screen.
The LCD screen is what spares you from having to remember that {some function you might use once in three years} is mapped to {non-obvious button}. It enables you to use the main, logically-arranged buttons for functions you use every day, and still have LCD-labeled buttons for the obscure, little-used functions close at hand (so you don't have to go digging out the original remote, find working batteries, etc) every few months.
Besides Harmony, the number of companies selling computer-programmable universal remotes that have real buttons, LCD screens, and have programming software that isn't restricted to ONLY their "value added resellers" (burn in hell, UEI) is... well... zero. If you want a LCD display, real buttons, and the ability to program it yourself without being forever dependent upon someone else, your choice is Harmony, Harmony, Harmony, and... er.... Harmony. There are a few open ones that are entirely LCD touchscreens... but those really suck, because you can't use them by feel with one hand, or without actively diverting your full attention to looking at what's on the display.
Harmony remotes suck... but they suck less than the alternatives.
As for CEC... HAHAHAHAHAHAHA(...)HAHAHAHA. That's a good one. Especially insofar as interoperability goes. If the extent of your "Home Theater" system is a TV from Walmart, a crap soundbar, and a Blu-Ray player, CEC might be adequate... if all three are from the same manufacturer, the same product line, and are fairly new. Now try setting up a 4K TV with multiple media sources, a receiver made by someone else with surround-sound speaker setup, and throw in a few "legacy" video sources for good measure. Have fun with CEC. Hell, TV manufacturers still keep finding creative new ways to screw up DISCRETE POWER AND INPUT SELECTION... usually, via things like automatically selecting the most recently-turned-on HDMI source (ok, unless they make the behavior something you CAN'T disable), or by making HDMI input-selection a "dynamic" function (so there's no way to deterministically tell it, "select HDMI input #6, regardless of what (or whether) anything is connected and active on HDMI ports 1-5"). Thankfully, external HDMI switchboxes are cheap... but still, seriously? We've been bitching about dysfunctional TVs with messed up discrete codes for what, 25 years now? And the industry STILL can't manage to get it right?!? It's just insane.
Some new TVs sold in the US ship with disabled ATSC tuners that require at least a one-time internet connection to enable. Basically, they didn't want to pay the licensing fees for EVERY TV that gets sold, so they negotiated a deal whereby they ship with the ATSC tuner disabled & only have to pay royalties for the tuners that someone explicitly enables.
It's basically a power strip with relay that's controlled by an optoisolated pair of wires. AFAIK, it's not UL approved, but it's "CPI Tested", for whatever that's worth. One outlet is always-on, one is normally-on, two are normally-off.
X10 has been pretty much dead and useless ever since CFLs and LEDs took over. The problem isn't with the X10 protocol per se, but rather with the ASIC used by nearly every X10 module in modern history. Between CFLs with active ballasts & LED drivers, basically every module that has ever existed is now unusable. Even with the relay-based appliance modules, the "local power control" feature STILL fucks them up... EVEN IF you cut the trace that supposedly disables it (it still sends a pulse of current every 10 seconds or so). If I were really determined, I could still get CFLs to work by connecting an incandescent night light in parallel, but I've NEVER seen an X10 module that works properly with LED lights.
It's a shame, because I literally grew up in an X10 house... my parents had a bunch of X10 modules going all the way back to 1980s Radio Shack, I had two in my college dorm room to control lights that were inconveniently far from the door and my bed, and my collection multiplied after college & especially after I bought a house, only for all of them to become functionally obsolete as I switched to LEDs and even my nightlight work-around ceased to work. X-10 had a good run, only to ultimately get killed off by something not directly related to the standard itself.
Guns aren't quite as pervasive, but it's not like the UK is some gun-free idyllic paradise. British *criminals* (esp. organized crime) have been pretty well armed since the 70s & 80s. It's more like, you'd never see British police responding to a suicidal person by shooting them dead for failing to comply immediately (or attacking them with a butter knife). British police are more patient... they'll secure the perimeter & go into 'siege' mode for a few days if necessary, because they know the person will *eventually* get hungry, tired, have to poop, whatever. American police aren't expected to *have* that kind of patience... and they really *should*.
It's one thing to kill a suspect who presents an active danger to bystanders. It's another matter *entirely* to aggressively escalate the situation into a gun battle just because the police felt impatient, or felt "threatened" because they insisted upon PUTTING themselves directly INTO a situation THEY largely escalated into existence THEMSELVES instead of calmly digging in for a siege.
In Britain, police who intentionally escalate a siege into a shootout are scrutinized, looked down upon, and seen as a danger to themselves and the public. In America, all that matters is, "was the LEO in danger *at that instant*, regardless of who escalated the confrontation to get there". In America, it's always the criminal's fault for triggering police action in the first place, regardless of outcome. British police are held to a higher standard of restraint, and are better-trained AT practicing restraint.
That's not to say British police are all saints, or that all American police are gun-slinging alpha-male cowboys... but there are unquestionably different expectations for police behavior in the US & Britain. In the US, the only real standard a LEO has to meet to legally justify killing a suspect is, "did the officer feel endangered?" In Britain, impatiently escalating a confrontation into a shootout would probably be a career-ending screwup that, at best, would limit that officer to only UN-armed duties thereafter.
British police DO seem to try a lot harder than American police to de-escalate situations & resolve them without bloodshed, and take immense pride in their ability to do it.
American police see movies with lines like, "The terrorist has a hostage. What do you do? (bam!) Shoot the hostage to disorient the terrorist." and think, "Fuck YEAH!"
Yeah, I remember a demo I had circa 1984 that played a few seconds of some Van Halen song (I think it was "Why can't this be Love"). It took an *eternity* to load... even WITH Epyx FastLoad... and played around 7-10 seconds of audio once it did. But it seemed immensely cool at the time.
I still remember the 2-3 minutes Impossible Mission (Epyx) made us wait just to hear, "Another visitor? Stay a while... stay FOREVER!"
AFAIK, it's never been done... but if you had low-level programming access to the radio in an 802.11ac chipset (enough to detect TDWR radar bursts as they sweep by) and a source of extremely accurate timestamps, you could probably combine that with tower data and external data-aggregators (who, among other things, would have to monitor the radar beam's sweep) and obtain EXTREMELY accurate location data, even without involving GPS or wi-fi at all, and even if you were in an area that had access to only a single cellular tower.
Actually, if you had a local source of extremely stable, high-precision timestamp data, you could even probably log the radar bursts offline (along with their local timestamps), then LATER (when you GOT network connectivity of some kind), correlate those local timestamps to some "global" timestamp reference (and external log of observed radar beam rotations with their own accurate timestamps) & figure out with some degree of confidence where the user was at the time the radar bursts were noted. If you were in an area with multiple TDWR sites, you could probably narrow it down to an area roughly 1x3 kilometers. If you were in an area with three or more TDWR sites (basically, South Florida and Washington DC), you could probably narrow it down to a square kilometer or less (depending entirely upon the precision of your timestamp).
That said, I'm not confident you could actually DO this with a production mobile phone (at least, not without having access to programming and component information not generally available to the public, and not necessarily even readily available to phone manufacturers), but AFAIK, chipsets like the ones used by Broadcom are little more than software-defined radios with fairly open-ended capabilities that are more like a "blurry bucket" than a bright line (ie, some things work better than others, and not all frequencies have equal performance, but the Venn Diagram of "things that kind of work unreliably if you're really stubborn and willing to accept flakiness" is likely to be HUGE compared to "things that are certified to work reliably".
Personally, I'd LOVE to find a way of at least sniffing LTE tower data (tower id, reported signal strength, observed signal strength). It's still mostly a theory, but I suspect that you could probably use observed differences between reported & observed signal strength to detect rain nearby... especially if you had a phone that was built to work on multiple networks & could monitor towers from many networks on diverse frequencies (because not all frequencies are attenuated by precipitation... a fact you could use to disambiguate and distinguish moment-to-monent signal strength variance from variance due to falling raindrops attenuating signal strength). Basically, a form of "passive weather radar".
I got the idea a few years ago when I noticed that the signal strength of Sprint's ~3.5GHz WiMax was PROFOUNDLY reduced by rain. I'm not sure how much lower frequencies are affected by rain (Sprint WiMax was kind of an aberration... I'm not even sure WHAT is using Clear's old WiMax license anymore, if anything), but with new 5G service using higher frequency bands, it might become viable in the near future even if the death of Sprint WiMax made the approach temporarily moot.
Calling "911" doesn't really "tie up" much of anything... it's not like there's LITERALLY a single phone line whose number is '911' and causes everyone else to get a literal busy signal. It's a hunt group to a call center, quite possibly with hundreds of agents, often serving a very large area.. and EVERYONE knows that {n}% of the calls at any moment in time are going to be misdialed/stupid/irrelevant. It's baked into the staffing count.
Some people act like every inappropriate 911 call is some needy person's death sentence. The reality is, if a 911 center is SO overwhelmed by calls that calls are going literally unanswered, chances are the local first-responders *themselves* are hopelessly overwhelmed at that point & can't do anything to help *anyway*.
Years ago, FedEx Ground was REALLY BAD about not bothering to even attempt delivery. I had orders from buy.com where I didn't even get a delivery note, and could prove the truck came nowhere near my street (I had cameras recording). Their drivers would refuse to take the package & it would just get automatically flagged in their system as a "failed attempt" (FedEx Ground was formerly RPS, and their drivers could do things FedEx Air & UPS could never get away with). I'm still deeply-prejudiced against FedEx Ground, even though this happened ~15 years ago.
Do laws involving crimes committed via USPS fully apply if USPS is technically a contractor doing "last-mile" delivery for Amazon/FedEx/UPS?
My guess is that they do... but only as "local" crimes, not "interstate" crimes, because USPS's responsibility was limited to a cross-town delivery (though there ARE quite a few metro areas that sprawl across state lines & conceivably involve even local packages crossing them). Ex: Kansas City, parts of Florida that have Alabama zipcodes because the PO is in Alabama even though the recipient is in Florida, etc
Jury trials don't work like that. The jury is only allowed to decide contested "matters of fact", and usually neither the defense nor prosecution is allowed to make them aware of *motive* (unless the motive itself is contested). That's why juries render verdicts every day that look completely *outrageous* to anyone who knows the context. Often, the jury members are often the only ones who *officially* DON'T know the context (at least, not until 10 minutes after leaving the courtroom and being completely horrified).
It's also why, when a jury *does* engage in nullification, the members get grilled by the judge to explain how they reached the verdict... and the judge declares a mistrial if anyone lets it slip that they found the defendant innocent because they disagreed with the law itself rather than reaching the verdict solely by considering only the evidence presented and without disregarding the judge's explicit instructions.
I'm pretty sure "Salt & Vinegar" flavor comes from anhydrous aluminum acetate... basically, aluminum combined with acetic acid to make an ionic crystalline salt not unlike sodium chloride.
It's also handy as an aqueous solution ("Burrow Solution") for preventing swimmer's ear (by making the ear canal too acidic for fungi to grow).
I'm guessing, but I think it might be sold in grocery stores as the stuff you'd use to make homemade pickles (or to "pickle" food in general).
Lactic acid is probably used to tweak its physical properties without negatively affecting the taste.
Interesting trivia: "white vinegar" is literally watered-down acetic acid, but it's illegal (in the US, Europe, and most places) to literally add water to acetic acid & sell it as "vinegar" -- they have to be able to prove it came from a "food" process (like fermentation) rather than being chemically synthesized and diluted.
In retrospect, Amiga-era PC games sucked a lot worse than they really HAD to, because PC game programmers (with the nearly sole exception of John Carmack) were still enslaved by the perceived need for BIOS compatibility. If you said "fuck BIOS compatibility" and hit the hardware of a PC directly (the way nearly all Amiga games did), you could actually do some pretty impressive things with CGA, EGA, and VGA. It's just that at the time, very few people actually understood HOW CGA, EGA, and VGA worked at the bit-and-register level, and most of the few who did were afraid of the inevitable tech support nightmare of complaints from people who bought a game to use on a computer whose videocard chipset wasn't explicitly on the "supported" list.
Case in point: most people have NO IDEA that VGA could actually do tiled graphics... because (AFAIK) it wasn't a supported BIOS function (at least, not until SVGA BIOS extensions appeared a few years later). But if you hit the hardware directly, you could do it (and in fact, this is how the file manager for DOS 6, and at least one.mod editor, rendered their mouse pointers). Likewise, I'm pretty sure it WAS actually possible to use the ISA timer with an interrupt to do things like reload color registers and change graphics modes mid-screen... but it only worked reliably on video cards with VRAM. I might be confused with something else, but I'm pretty sure you could also use one of the DMA controllers to do blitter-like copying on SOME computers (but only from one 64k block of system ram to one 64k block of video ram... and it HAD to be VRAM, not DRAM, and it could only do literal copies... no XOR or anything like that).
The point is, computer graphics in general were poorly understood by most programmers at the time, and both Amiga AND PC programmers were constrained by a general lack of knowledge about what the hardware could REALLY do, as opposed to what it could OFFICIALLY do. Once you know something is possible, it's a lot easier to back-port it to older architectures where nobody would have EVER tried doing it a few years earlier.
To this day, most people have no idea that the Commodore 64 actually HAD real wavetable audio (but lacked DMA, so it was up to you to stuff values directly into the PWM registers in realtime), or that the Commodore 64 was capable of 320x400 interlaced video if you manually toggled a bit at the right instant to generate an interlace field pulse for the video display & switched the bank pointer. Or that the first-generation accelerated SVGA cards (like the S3 '911) had a full-blown hardware blitter AND a real 16x16 sprite (used by the mouse pointer, but totally capable of being hijacked if you weren't running under Windows).
There's a HUGE difference noise-wise between Boom's proposed supersonic engines, and even the quietest rocket engine that anybody can even FANTASIZE about. VERY FEW cities have airports positioned where an plane on final approach can almost totally avoid flying over populated areas. Fort Lauderdale, JFK, and LAX? Sure. SFO and Tampa? Er... not so much (the approaches are over water, but they're adjacent to expensive populated areas). Even Miami and Orlando have sprawled to the point where the area directly under the approach path might be mostly empty... but move a mile or two to either side (and still very much within the noise path), and you're right back into populated areas again.
Could Musk or Branson land spaceplanes at Cape Canaveral? Sure... that's what it's there for, and Brevard County can't do a thing about it. But just about anywhere else (besides the aforementioned Fort Lauderdale, LAX, and JFK... maybe add new airports way out in the desert an hour away from Las Vegas & Phoenix...) is going to be a seriously difficult obstacle due to noise complaints by residents.
And those noise complaints wouldn't be entirely invalid. Yes, people might buy property near an airport knowing it's an airport... but it's one thing to buy property in the flight path when the loudest thing that flies over is couple of planes per day the size and loudness of an A380 or a 747. It's another matter ENTIRELY when you start talking about space planes that make as much noise as a Falcon 9 at lift-off, or jets even remotely close to being as loud as a Concorde was... and having them fly over every few minutes, almost nonstop, from early dawn until late at night.
> x86-64 instructions are power-sucking, ARM is power-sipping.
Bullshit. ARM is power-sipping because a power-sipping ARM can't even FANTASIZE about holding its own against an i7/i9-class x86-64 CPU.
Yes, ARM can be made as powerful as an x86/AMD64 i7/i9... and by the time you do it, it's consuming as much power, and costs at least as much AS an i7/i9-class x86/AMD64 CPU.
For the most part, we've basically run into a wall insofar as increasing clock speed goes. With ARM, you have one real strategy to move forward... add threads running on more cores. With x86/AMD64, there's still "Plan B" -- find ways behind the scenes to make individual complex instructions execute in fewer clock cycles so you can still get faster performance from the same (albeit recompiled) source code. With RISC, you can't get faster than one instruction per clock cycle. With CISC'ified RISC (which modern x86/AMD64 processors really are), you can occasionally get lucky and get a complex operation to execute in fewer clock cycles than even highly-optimized RISC code could execute in (because the CPU itself can split pipelines internally and do things in parallel behind the scenes that would be an absolute NIGHTMARE to try and manage directly with multithreaded code).
You want to argue that mainstream ARM is as good as mainstream x86/AMD64? Fine... write programs for Android (with 4+ core ARM) and Windows (with a 4-core i7) that use the Stockfish chess engine, and compare their performance when running on CPUs with comparable nominal clock speeds. The engine running under Windows on the i7 will absolutely DESTROY the Android ARM's performance by several orders of magnitude. It's not even a close race.
Slashdot Mirror
> kids learned programming by reading magazines and books.
As someone who was a teen in the 80s, I can say, "sort of". For books about Commodore 64-related topics in the mid-80s, you're kind of right. If you lived in a big city or a college town, you MIGHT have had access to good books about computers and programming (at least, if you were talking about the Commodore 64, Apple II, or MAYBE "PC"). If you lived in a small town whose book store situation could be fully described as, "Waldenbooks and B. Dalton at the mall" and had an Amiga or Atari ST, probably not. Even for Macintosh, you weren't going to find anything that even vaguely resembled a book about Macintosh assembly language at a small-town mall bookstore... you'd have been lucky if you found a book or two about Hypercard, Macwrite, and MAYBE Pagemaker.
When I got to college, my university's library was almost as useless... I think the NEWEST book in the entire QA76.* section was 2 or 3 years old, and the only topics they seemed to have any interest in covering were Unix, PDP-11, and Cobol. If you were an 18-24 year old circa 1990 at a University that wasn't Standford or MIT (and thus had no access to anything that vaguely resembled a graphics workstation from SGI), books about Unix, PDP-11, and/or Cobol programming were about as interesting as... er... nothing, because they weren't interesting at all. Compared to an Amiga or high-end PC, a text terminal was an artifact from the stone age of computing.
Pre-Internet, even discovering the EXISTENCE of books about semi-niche topics was hard. At various points between 1986 and 1992, I made random stabs at ordering books with "Amiga" in the title based upon nothing more than what was on the microfiche of books you could special order at Waldenbooks and B. Dalton, and every single one of them ultimately ended up being money that was completely wasted. Decades later, I randomly tripped over scanned pdf copies of books that supposedly existed circa 1990 and 1991, and all I could think was, "Where the holy FUCK were those books back when I NEEDED them, and would have bought them in a heartbeat?" They sure as HELL didn't exist in small-town mall bookstores.
Things weren't a whole lot better on the PC side. Circa 1992 and 1993, I spent MONTHS trying to figure out how to use linear memory addressing on a 486DX. A few years later, the answer was obvious... DOS4GW. At the time, though, even people who understood PC assembly language would just give me blank stares & say, "you HAVE to use 64k segments". I could stand on the roof in 1993 and scream, "what the fuck is 386enh mode, and how do I use it?" and get nothing but stony silence and weird stares. I knew it was possible (ever since the 386DX) to use linear addressing, but learning how to actually use it was another matter entirely.
Circa 1993, I would have literally KILLED for a copy of Richard Ferraro's book about VGA programming... had I even known it EXISTED (I think I first stumbled across a later edition sometime around 1995 or 1996).
That was the harsh reality of life back then. It was an information dark age. There was no Google. There was *barely* an "internet". Even if you had internet access, Usenet replies were (easily) overlooked, scrolled into history within a week or two, and were gone forever until the arrival of DejaNews YEARS later. All of the libraries I had access to in the 1980s and 1990s were basically worthless for books about computer-related topics... they all had really long purchasing cycles, took even LONGER to get purchased or donated books into circulation, and by the time any book made it to the shelves, it had probably been obsolete for years. It wasn't until the early 2000s that libraries really started to preemptively buy newly-released books about computer-related topics (from publishers regarded as generally producing high-quality books) and get them quickly placed on shelves before the books were obsolete. In my entire life prior to ~2000, I think I remember finding ONE useful book about pro
> In that case why wouldn't you just use local on device controls to adjust configuration?
Because lots of newer devices barely HAVE local on-device controls anymore. You're lucky to have real buttons for 'toggle power', 'cycle through inputs', 'volume up', 'volume down', 'menu', 'channel up/next', 'channel down/prev'. When you run into some really weird edge case, like 'old DVD that was authored with incorrect flags, so the aspect ratio and/or letterboxing is all fsck'ed up', you have to manually adjust the SD aspect ratio/zoom settings. They're something that you shouldn't have to worry about, and rarely do... but WHEN you do, it kind of sucks if you have to remember that the function was mapped to the button on the universal remote marked 'sleep' (or some other even more obscure function whose button you had to recycle, because there was no button on the universal remote explicitly labeled as 'SD Zoom/Aspect Ratio').
Of course, some universal remotes DO have buttons labeled for every conceivable function... and usually, those remotes have dozens and dozens of identical tiny buttons with labels that can't easily be read in dim light... or bright light, for that matter (Japanese remotes in particular are bad about this... consumers in Japan apparently LOVE having lots and lots of tiny little identical buttons in neat, orderly rows).
The problem with asking, "why not just use the original remote for things like that?" is the fact that the original remote is probably buried somewhere, and once you finally DO find it, the likelihood that its batteries are still good (after years of sitting unused, buried under assorted stuff) is low. Add 5-10 minutes to hunt down the right batteries (inevitably, you'll need 3 AAA batteries, and discover you have TWO AAA batteries and a crate of AA batteries). That's the benefit of being able to dig through the remote's LCD menu for those obscure functions... it spares you from having to hunt down the original remote, then go on a second hunt for batteries.
> What difference does it make if it's a soundbar or an AVR?
A soundbar is a very, very simplified and dumbed-down peripheral -- it's a single device, connected to a single source via a single cable, with a very limited range of constrained settings. In contrast, an AVR is a lot more open-ended and configurable, in terms of inputs, outputs, AND any processing done to the signals between the two. A really good soundbar is a net improvement over most built-in speakers on a TV, but has nowhere NEAR the capabilities of a good AVR with left, right, center, left-surround, right-surround, left-rear-surround, right-rear-surround, and one or two subwoofers. Since it's physically impossible to get true surround from a single soundbar, that itself eliminates ~70% of the settings and configurations you'd have to deal with when setting up and tweaking surround settings to optimize the setup for your room's inevitably-imperfect sonic environment.
My point was that a simple, lower-end consumer who buys a select few matched components and has relatively low expectations to begin with might have an easy setup experience with a cheap TV and soundbar from Walmart, but someone who demands at a minimum 5.1 surround with non-absurdly-undersized speakers and wants it tweaked to handle their room's audio characteristics is unlikely to be satisfied with that, and is likely to find CEC to be quite a bit more constraining (and buggy). CEC is the control system of tomorrow. And tomorrow is still quite far away if you're the kind of user who benchmarks his system, owns at least one analyzer, annoys his spouse and/or family and/or friends by insisting upon tweaking the settings for every movie to achieve perfection (when all THEY seemingly want to do is "watch the movie", and don't *care* if the surround timing sounds like it's a bit delayed on the rear-right channel in scene 23).
OK, here are some real-world experiences.
Last weekend, I was at Sawgrass Mills (a large outlet mall at the western edge of Fort Lauderdale). I have a Nexus 6P and use AT&T. According to the signal strength icon, I had perfect RF signal quality... and couldn't even ping 8.8.8.8 or access Google. I changed the settings to force 3G, and instantly everything worked perfectly.
This afternoon, I was at Pembroke Lakes Mall (in Pembroke Pines, southwestern Fort Lauderdale area). Same story. With LTE enabled, I supposedly had perfect connectivity, but couldn't access anything over the internet reliably. The moment I set the phone to force 3G, my problems went away.
Sure, it's probably the fault of AT&T and not LTE itself... but it still speaks poorly of a mode that seems to have a HUGE problem (at least, by default) dealing with use cases like "tower site adjacent to large regional mall the weekend before Christmas" that older modes can somehow handle just fine.
My point is that every US provider HAS coverage that's deficient in some respect.
LTE was developed for neat, orderly, well-planned & properly-executed networks. The harsh reality is, US networks are more variable in quality & a lot more adhoc.
In messy networks, CDMA (including HSPA+) is more robust & resilient, and tolerates a greater amount of chaos without breaking down.
That robustness comes at a price -- more power consumption and less efficient spectral efficiency. In places like Scandinavia and South Korea, LTE works extraordinarily well. In post-Hurricane Florida, or San Francisco on an average NIMBY-limited day, it has Issues.
With HSPA+, almost any capacity problem can be solved through brute force if you dump enough nanocells & femtocells into a problematic area until the problem sorts itself out. You can call it wasteful & you'd be right... but people bitch a lot more about efficient networks that hiccup & glitch than wasteful abundance that "just works anyway".
With LTE, you have to actually understand the problem & solve it deliberately. Both approaches have real world merit, but in the US, the approach that requires less coordination & planning is usually the one more likely to succeed.
LTE is unquestionably the future, especially as networks mature & early problems eventually get resolved... but in the early rag-tag days of inconsistent & compromised deployment, the leap from HSPA+ to LTE is not a consequence-free upgrade... it's "two steps forward, 1.7 to 2.4 steps backward (to the left or right, with an occasional spin)".
LTE might be more efficient, but HSPA+ still wins by pure brute force when you're in a moving vehicle speeding through an area at 80-150mph if you value uninterrupted realtime connectivity.
LTE's single-tower orientation causes other problems, too. After Hurricane Irma, there were a lot of dysfunctional LTE tower sites in Florida for several weeks due to backhaul problems. The problem was, sites with dysfunctional backhaul still acceptet connections. So your phone might connect to a dysfunctional tower & hold on to the connection, even if there's a second tower nearby that's working properly. With HSPA+, it's not a big deal... you'd connect to both towers, the one with working backhaul would carry the whole load, and the dysfunctional tower would just sit there and not interfere. With LTE, you'd have "5 bars, but no actual connectivity" (because it would be like a wi-fi access point that's plugged in, but is connected to a malfunctioning dsl/cable modem).
Put another way, LTE doesn't handle dysfunctional conditions as gracefully as HSPA+ does, even if it IS more efficient under ideal conditions. In a place like Florida where hurricanes happen every few years, ability to "just work" amidst malfunctioning & dysfunctional tower sites matters.
No, but it *does* unambiguously have jurisdiction over the transmitters the company operated in Georgia.
Sprint sucked, but WiMax WAS "4G", every bit as much as American LTE was "4G".
The main reason why Sprint's Wimax was inferior to Verizon's first stab at LTE was because of the frequency band it ran in. The latest iteration of LTE is better than Wimax was, but the FIRST generation of LTE was barely any different (in terms of bare-metal radio modulation) than Wimax (slightly more efficient encoding to make better use of RF energy, but it was more of a minor tweak than anything). If Sprint's Wimax had run at 700MHz instead of 3.5GHz, it would have been functionally no different from Verizon's first-generation LTE.
Sprint made their transition to LTE a thousand times worse than it had to be by allowing/requiring Samsung to make the Galaxy S3 LTE-only, instead of spending $5 more and building it with the pin-identical chip that could do Wimax too. If the S3 had been dual-mode (even if it required rebooting to switch between Wimax or LTE), it would have bought Sprint another year to gracefully transition... they could have left Wimax where it was, deployed LTE to markets with no Wimax, then switched Wimax to LTE after they'd given customers a year or two of dual-mode phones that could do either one.
Instead, Sprint ended up in a situation where their Wimax network became nearly useless almost overnight as (former) customers upgraded to new LTE-only phones, then returned them and left Sprint in disgust after realizing just HOW BAD Sprint's 3G network had become without having Wimax as a crutch to fall back on.
Personally, I was pissed when T-Mobile decided to go "all LTE" just for the sake of a marketing bullet point. HSPA+ might not be LTE, but in urban areas with dense tower deployment, HSPA+ is technically SUPERIOR to LTE (at least, LTE at the time it was deployed to replace HSPA+), especially if you're in a moving vehicle.
Unlike LTE, HSPA+ allows your phone to connect to MULTIPLE different towers & split your data between them (basically, like using a shotgun modem with PPP multilink). That comes in handy if you're in an area with dense tower deployment and in a fast-moving vehicle (like high-speed rail, or a car doing 80mph on a freeway) -- the phone can metaphorically swing like a monkey from tower/branch to tower/branch, always keeping one metaphorical hand on a tower/branch while the other reaches for the next so it's never COMPLETELY offline and disconnected. In contrast, LTE has "hard" disconnects -- the phone connects to exactly one tower at a time, and when it disconnects it has no data connectivity (or IP address) AT ALL until it establishes its next connection to a different tower.
This also means that HSPA+ can be a lot more aggressive about hunting for better connectivity... it can hedge its bets by remaining connected to its "best" known tower, while aggressively connecting around in search of a better one. In contrast, LTE tends to hang on until it literally can't sustain a connection at all, even if there's a "better" tower it COULD use instead... in order to "try out" that tower, it has to break its connection and do a hard switch to the new one... and if it's TOO aggressive about hunting for a better tower, you can end up with the kind of thrashing Sprint phones had back in the wimax era (if you were in an area where two wimax towers were in view, but BOTH were marginal, Sprint phones would thrash back and forth between them every few seconds... made worse by the fact that those phones ALSO shared components between wimax and wifi, so you couldn't use both simultaneously.)
In rural areas (and large parts of suburbia), it's kind of academic because there's probably only one tower in view at a time ANYWAY... but in areas with the tower density to support it properly, HSPA+ is arguably a step UP from LTE.
That said... I don't think AT&T ever actually HAD HSPA+. I know AT&T had HSDPA, and I'm pretty sure they were in the process of deploying HSUPA at some point, but AFAIK, AT&T quit upgrading 3G at some point before HSPA+ and decided to focus entirely on LTE... then started attacking T-Mobile for not being "all LTE".
Personally, if I'd been in charge at T-Mobile, I would have hit back hard at AT&T and run ads calling them "LTE Lemmings" for blindly chasing after buzzwords instead of pure technical merit. I would have shown happy T-Mobile customers on Acela (or in cars driving side by side on an open freeway) enjoying uninterrupted connectivity while frustrated AT&T and Verizon customers kept having their Facetime chats glitch and break up every couple of minutes when the phones moved too far from their past tower & had a second or two of network disruption while connecting to the next tower. Or worse, having their banking and VPN apps kicking them offline every few minutes because it detected an IP address change (go search old messages at XDA-developers.com & you can read about how people used to have to lock their phone to 3G to use it with a VPN or banking app when riding on Acela, because otherwise the IP address would keep changing every few minutes & they'd get logged out automatically).
IMHO, LTE was actually a technological step backwards. Most of the "benefits" people ascribe to "LTE" over HSPA+ have nothing to do with "4G", and EVERYTHING to do with "carriers used their best new frequency bands to deploy it". Had HSPA+ been deployed at 600 & 700MHz, with the same amount of fiber backhaul as LTE, the difference between HSPA+ and LTE would have been mostly an academic footnote. LTE does make some improvements to the way voi
Hmmm... that's interesting. I haven't actually tried using the dimmable ones with LCDs... I actually did a huge round of X10 replacements sometime around 2010 when I replaced all of my remaining dimmable/incandescent modules with 3-prong appliance-type modules (usually, in conjunction with a 6" extension cord and a 4w nightlight whose only purpose was to provide a constant resistive load to keep the modules from turning themselves on without actually going all the way and disabling the local power control feature.
The main issue I had with LED lights is that even the relay-equipped 3-prong appliance modules send a brief power pulse every few seconds (as far as I can tell, cutting the trace doesn't stop it from pulsing power through the bulb, it just makes the ASIC ignore the outcome so the module won't think you toggled the local power switch and turn itself back on), which causes the bulb to visibly flash. I guess now that you mention it, dimmable-type LCDs might actually BE compatible with the older incandescent/dimmable-type X10 controllers. I'm going to have to go dig out the box with the old dimmable/incandescent-type modules and try them :-)
I'm lucky in the signal area... once I put the X-10 crossover/bridge module on my dryer outlet a few years ago, all of my problems seemed to go away. If I can get the incandescent modules to work, that'll be great news... I have an Elk M1 home automation controller & security system and did a fair amount of programming circa 2013 to add lighting control using their M1-to-X10 bridge (so I could do things like call home, let the answering machine pick up while it eavesdrops, then remotely turn lights on and off).
I thought about switching to Z-wave or Insteon a couple of years ago, but Insteon's main appeal was cross-compatibility with X-10. If all the X10 gear is moot, Insteon's main selling point goes out the window.... and cost-wise, it's as expensive as Z-wave. Elk's Z-wave module was REALLY expensive, Z-wave switches and light modules were OUTRAGEOUSLY expensive, and reading the horror stories about interoperability between licensed Z-wave devices and generic "Zigbee, but not literally Z-wave" devices just turned me off of the whole thing. And then, right around the point when Z-wave devices started becoming halfway sane price-wise, the tsunami of "wi-fi" control modules arrived. I'll probably go with wi-fi eventually, but only when I'm satisfied that they're interoperable with standards that don't depend upon the continued existence and reliable operation of some vendor's cloud infrastructure that could vanish tomorrow & leave me with yet another collection of paperweights.
The appeal of Harmony remotes isn't being able to reprogram buttons... it's being able to reprogram buttons that have dynamic labels provided by the adjacent LCD screen.
The LCD screen is what spares you from having to remember that {some function you might use once in three years} is mapped to {non-obvious button}. It enables you to use the main, logically-arranged buttons for functions you use every day, and still have LCD-labeled buttons for the obscure, little-used functions close at hand (so you don't have to go digging out the original remote, find working batteries, etc) every few months.
Besides Harmony, the number of companies selling computer-programmable universal remotes that have real buttons, LCD screens, and have programming software that isn't restricted to ONLY their "value added resellers" (burn in hell, UEI) is... well... zero. If you want a LCD display, real buttons, and the ability to program it yourself without being forever dependent upon someone else, your choice is Harmony, Harmony, Harmony, and ... er.... Harmony. There are a few open ones that are entirely LCD touchscreens... but those really suck, because you can't use them by feel with one hand, or without actively diverting your full attention to looking at what's on the display.
Harmony remotes suck... but they suck less than the alternatives.
As for CEC... HAHAHAHAHAHAHA(...)HAHAHAHA. That's a good one. Especially insofar as interoperability goes. If the extent of your "Home Theater" system is a TV from Walmart, a crap soundbar, and a Blu-Ray player, CEC might be adequate... if all three are from the same manufacturer, the same product line, and are fairly new. Now try setting up a 4K TV with multiple media sources, a receiver made by someone else with surround-sound speaker setup, and throw in a few "legacy" video sources for good measure. Have fun with CEC. Hell, TV manufacturers still keep finding creative new ways to screw up DISCRETE POWER AND INPUT SELECTION... usually, via things like automatically selecting the most recently-turned-on HDMI source (ok, unless they make the behavior something you CAN'T disable), or by making HDMI input-selection a "dynamic" function (so there's no way to deterministically tell it, "select HDMI input #6, regardless of what (or whether) anything is connected and active on HDMI ports 1-5"). Thankfully, external HDMI switchboxes are cheap... but still, seriously? We've been bitching about dysfunctional TVs with messed up discrete codes for what, 25 years now? And the industry STILL can't manage to get it right?!? It's just insane.
Some new TVs sold in the US ship with disabled ATSC tuners that require at least a one-time internet connection to enable. Basically, they didn't want to pay the licensing fees for EVERY TV that gets sold, so they negotiated a deal whereby they ship with the ATSC tuner disabled & only have to pay royalties for the tuners that someone explicitly enables.
Adafruit makes something like this -- https://www.adafruit.com/produ...
It's basically a power strip with relay that's controlled by an optoisolated pair of wires. AFAIK, it's not UL approved, but it's "CPI Tested", for whatever that's worth. One outlet is always-on, one is normally-on, two are normally-off.
X10 has been pretty much dead and useless ever since CFLs and LEDs took over. The problem isn't with the X10 protocol per se, but rather with the ASIC used by nearly every X10 module in modern history. Between CFLs with active ballasts & LED drivers, basically every module that has ever existed is now unusable. Even with the relay-based appliance modules, the "local power control" feature STILL fucks them up... EVEN IF you cut the trace that supposedly disables it (it still sends a pulse of current every 10 seconds or so). If I were really determined, I could still get CFLs to work by connecting an incandescent night light in parallel, but I've NEVER seen an X10 module that works properly with LED lights.
It's a shame, because I literally grew up in an X10 house... my parents had a bunch of X10 modules going all the way back to 1980s Radio Shack, I had two in my college dorm room to control lights that were inconveniently far from the door and my bed, and my collection multiplied after college & especially after I bought a house, only for all of them to become functionally obsolete as I switched to LEDs and even my nightlight work-around ceased to work. X-10 had a good run, only to ultimately get killed off by something not directly related to the standard itself.
Guns aren't quite as pervasive, but it's not like the UK is some gun-free idyllic paradise. British *criminals* (esp. organized crime) have been pretty well armed since the 70s & 80s. It's more like, you'd never see British police responding to a suicidal person by shooting them dead for failing to comply immediately (or attacking them with a butter knife). British police are more patient... they'll secure the perimeter & go into 'siege' mode for a few days if necessary, because they know the person will *eventually* get hungry, tired, have to poop, whatever. American police aren't expected to *have* that kind of patience... and they really *should*.
It's one thing to kill a suspect who presents an active danger to bystanders. It's another matter *entirely* to aggressively escalate the situation into a gun battle just because the police felt impatient, or felt "threatened" because they insisted upon PUTTING themselves directly INTO a situation THEY largely escalated into existence THEMSELVES instead of calmly digging in for a siege.
In Britain, police who intentionally escalate a siege into a shootout are scrutinized, looked down upon, and seen as a danger to themselves and the public. In America, all that matters is, "was the LEO in danger *at that instant*, regardless of who escalated the confrontation to get there". In America, it's always the criminal's fault for triggering police action in the first place, regardless of outcome. British police are held to a higher standard of restraint, and are better-trained AT practicing restraint.
That's not to say British police are all saints, or that all American police are gun-slinging alpha-male cowboys... but there are unquestionably different expectations for police behavior in the US & Britain. In the US, the only real standard a LEO has to meet to legally justify killing a suspect is, "did the officer feel endangered?" In Britain, impatiently escalating a confrontation into a shootout would probably be a career-ending screwup that, at best, would limit that officer to only UN-armed duties thereafter.
British police DO seem to try a lot harder than American police to de-escalate situations & resolve them without bloodshed, and take immense pride in their ability to do it.
American police see movies with lines like, "The terrorist has a hostage. What do you do? (bam!) Shoot the hostage to disorient the terrorist." and think, "Fuck YEAH!"
Yeah, I remember a demo I had circa 1984 that played a few seconds of some Van Halen song (I think it was "Why can't this be Love"). It took an *eternity* to load... even WITH Epyx FastLoad... and played around 7-10 seconds of audio once it did. But it seemed immensely cool at the time.
I still remember the 2-3 minutes Impossible Mission (Epyx) made us wait just to hear, "Another visitor? Stay a while... stay FOREVER!"
AFAIK, it's never been done... but if you had low-level programming access to the radio in an 802.11ac chipset (enough to detect TDWR radar bursts as they sweep by) and a source of extremely accurate timestamps, you could probably combine that with tower data and external data-aggregators (who, among other things, would have to monitor the radar beam's sweep) and obtain EXTREMELY accurate location data, even without involving GPS or wi-fi at all, and even if you were in an area that had access to only a single cellular tower.
Actually, if you had a local source of extremely stable, high-precision timestamp data, you could even probably log the radar bursts offline (along with their local timestamps), then LATER (when you GOT network connectivity of some kind), correlate those local timestamps to some "global" timestamp reference (and external log of observed radar beam rotations with their own accurate timestamps) & figure out with some degree of confidence where the user was at the time the radar bursts were noted. If you were in an area with multiple TDWR sites, you could probably narrow it down to an area roughly 1x3 kilometers. If you were in an area with three or more TDWR sites (basically, South Florida and Washington DC), you could probably narrow it down to a square kilometer or less (depending entirely upon the precision of your timestamp).
That said, I'm not confident you could actually DO this with a production mobile phone (at least, not without having access to programming and component information not generally available to the public, and not necessarily even readily available to phone manufacturers), but AFAIK, chipsets like the ones used by Broadcom are little more than software-defined radios with fairly open-ended capabilities that are more like a "blurry bucket" than a bright line (ie, some things work better than others, and not all frequencies have equal performance, but the Venn Diagram of "things that kind of work unreliably if you're really stubborn and willing to accept flakiness" is likely to be HUGE compared to "things that are certified to work reliably".
Personally, I'd LOVE to find a way of at least sniffing LTE tower data (tower id, reported signal strength, observed signal strength). It's still mostly a theory, but I suspect that you could probably use observed differences between reported & observed signal strength to detect rain nearby... especially if you had a phone that was built to work on multiple networks & could monitor towers from many networks on diverse frequencies (because not all frequencies are attenuated by precipitation... a fact you could use to disambiguate and distinguish moment-to-monent signal strength variance from variance due to falling raindrops attenuating signal strength). Basically, a form of "passive weather radar".
I got the idea a few years ago when I noticed that the signal strength of Sprint's ~3.5GHz WiMax was PROFOUNDLY reduced by rain. I'm not sure how much lower frequencies are affected by rain (Sprint WiMax was kind of an aberration... I'm not even sure WHAT is using Clear's old WiMax license anymore, if anything), but with new 5G service using higher frequency bands, it might become viable in the near future even if the death of Sprint WiMax made the approach temporarily moot.
Calling "911" doesn't really "tie up" much of anything... it's not like there's LITERALLY a single phone line whose number is '911' and causes everyone else to get a literal busy signal. It's a hunt group to a call center, quite possibly with hundreds of agents, often serving a very large area.. and EVERYONE knows that {n}% of the calls at any moment in time are going to be misdialed/stupid/irrelevant. It's baked into the staffing count.
Some people act like every inappropriate 911 call is some needy person's death sentence. The reality is, if a 911 center is SO overwhelmed by calls that calls are going literally unanswered, chances are the local first-responders *themselves* are hopelessly overwhelmed at that point & can't do anything to help *anyway*.
Years ago, FedEx Ground was REALLY BAD about not bothering to even attempt delivery. I had orders from buy.com where I didn't even get a delivery note, and could prove the truck came nowhere near my street (I had cameras recording). Their drivers would refuse to take the package & it would just get automatically flagged in their system as a "failed attempt" (FedEx Ground was formerly RPS, and their drivers could do things FedEx Air & UPS could never get away with). I'm still deeply-prejudiced against FedEx Ground, even though this happened ~15 years ago.
Do laws involving crimes committed via USPS fully apply if USPS is technically a contractor doing "last-mile" delivery for Amazon/FedEx/UPS?
My guess is that they do... but only as "local" crimes, not "interstate" crimes, because USPS's responsibility was limited to a cross-town delivery (though there ARE quite a few metro areas that sprawl across state lines & conceivably involve even local packages crossing them). Ex: Kansas City, parts of Florida that have Alabama zipcodes because the PO is in Alabama even though the recipient is in Florida, etc
Jury trials don't work like that. The jury is only allowed to decide contested "matters of fact", and usually neither the defense nor prosecution is allowed to make them aware of *motive* (unless the motive itself is contested). That's why juries render verdicts every day that look completely *outrageous* to anyone who knows the context. Often, the jury members are often the only ones who *officially* DON'T know the context (at least, not until 10 minutes after leaving the courtroom and being completely horrified).
It's also why, when a jury *does* engage in nullification, the members get grilled by the judge to explain how they reached the verdict... and the judge declares a mistrial if anyone lets it slip that they found the defendant innocent because they disagreed with the law itself rather than reaching the verdict solely by considering only the evidence presented and without disregarding the judge's explicit instructions.
I'm pretty sure "Salt & Vinegar" flavor comes from anhydrous aluminum acetate... basically, aluminum combined with acetic acid to make an ionic crystalline salt not unlike sodium chloride.
It's also handy as an aqueous solution ("Burrow Solution") for preventing swimmer's ear (by making the ear canal too acidic for fungi to grow).
I'm guessing, but I think it might be sold in grocery stores as the stuff you'd use to make homemade pickles (or to "pickle" food in general).
Lactic acid is probably used to tweak its physical properties without negatively affecting the taste.
Interesting trivia: "white vinegar" is literally watered-down acetic acid, but it's illegal (in the US, Europe, and most places) to literally add water to acetic acid & sell it as "vinegar" -- they have to be able to prove it came from a "food" process (like fermentation) rather than being chemically synthesized and diluted.
In retrospect, Amiga-era PC games sucked a lot worse than they really HAD to, because PC game programmers (with the nearly sole exception of John Carmack) were still enslaved by the perceived need for BIOS compatibility. If you said "fuck BIOS compatibility" and hit the hardware of a PC directly (the way nearly all Amiga games did), you could actually do some pretty impressive things with CGA, EGA, and VGA. It's just that at the time, very few people actually understood HOW CGA, EGA, and VGA worked at the bit-and-register level, and most of the few who did were afraid of the inevitable tech support nightmare of complaints from people who bought a game to use on a computer whose videocard chipset wasn't explicitly on the "supported" list.
Case in point: most people have NO IDEA that VGA could actually do tiled graphics... because (AFAIK) it wasn't a supported BIOS function (at least, not until SVGA BIOS extensions appeared a few years later). But if you hit the hardware directly, you could do it (and in fact, this is how the file manager for DOS 6, and at least one .mod editor, rendered their mouse pointers). Likewise, I'm pretty sure it WAS actually possible to use the ISA timer with an interrupt to do things like reload color registers and change graphics modes mid-screen... but it only worked reliably on video cards with VRAM. I might be confused with something else, but I'm pretty sure you could also use one of the DMA controllers to do blitter-like copying on SOME computers (but only from one 64k block of system ram to one 64k block of video ram... and it HAD to be VRAM, not DRAM, and it could only do literal copies... no XOR or anything like that).
The point is, computer graphics in general were poorly understood by most programmers at the time, and both Amiga AND PC programmers were constrained by a general lack of knowledge about what the hardware could REALLY do, as opposed to what it could OFFICIALLY do. Once you know something is possible, it's a lot easier to back-port it to older architectures where nobody would have EVER tried doing it a few years earlier.
To this day, most people have no idea that the Commodore 64 actually HAD real wavetable audio (but lacked DMA, so it was up to you to stuff values directly into the PWM registers in realtime), or that the Commodore 64 was capable of 320x400 interlaced video if you manually toggled a bit at the right instant to generate an interlace field pulse for the video display & switched the bank pointer. Or that the first-generation accelerated SVGA cards (like the S3 '911) had a full-blown hardware blitter AND a real 16x16 sprite (used by the mouse pointer, but totally capable of being hijacked if you weren't running under Windows).
There's a HUGE difference noise-wise between Boom's proposed supersonic engines, and even the quietest rocket engine that anybody can even FANTASIZE about. VERY FEW cities have airports positioned where an plane on final approach can almost totally avoid flying over populated areas. Fort Lauderdale, JFK, and LAX? Sure. SFO and Tampa? Er... not so much (the approaches are over water, but they're adjacent to expensive populated areas). Even Miami and Orlando have sprawled to the point where the area directly under the approach path might be mostly empty... but move a mile or two to either side (and still very much within the noise path), and you're right back into populated areas again.
Could Musk or Branson land spaceplanes at Cape Canaveral? Sure... that's what it's there for, and Brevard County can't do a thing about it. But just about anywhere else (besides the aforementioned Fort Lauderdale, LAX, and JFK... maybe add new airports way out in the desert an hour away from Las Vegas & Phoenix...) is going to be a seriously difficult obstacle due to noise complaints by residents.
And those noise complaints wouldn't be entirely invalid. Yes, people might buy property near an airport knowing it's an airport... but it's one thing to buy property in the flight path when the loudest thing that flies over is couple of planes per day the size and loudness of an A380 or a 747. It's another matter ENTIRELY when you start talking about space planes that make as much noise as a Falcon 9 at lift-off, or jets even remotely close to being as loud as a Concorde was... and having them fly over every few minutes, almost nonstop, from early dawn until late at night.
> x86-64 instructions are power-sucking, ARM is power-sipping.
Bullshit. ARM is power-sipping because a power-sipping ARM can't even FANTASIZE about holding its own against an i7/i9-class x86-64 CPU.
Yes, ARM can be made as powerful as an x86/AMD64 i7/i9... and by the time you do it, it's consuming as much power, and costs at least as much AS an i7/i9-class x86/AMD64 CPU.
For the most part, we've basically run into a wall insofar as increasing clock speed goes. With ARM, you have one real strategy to move forward... add threads running on more cores. With x86/AMD64, there's still "Plan B" -- find ways behind the scenes to make individual complex instructions execute in fewer clock cycles so you can still get faster performance from the same (albeit recompiled) source code. With RISC, you can't get faster than one instruction per clock cycle. With CISC'ified RISC (which modern x86/AMD64 processors really are), you can occasionally get lucky and get a complex operation to execute in fewer clock cycles than even highly-optimized RISC code could execute in (because the CPU itself can split pipelines internally and do things in parallel behind the scenes that would be an absolute NIGHTMARE to try and manage directly with multithreaded code).
You want to argue that mainstream ARM is as good as mainstream x86/AMD64? Fine... write programs for Android (with 4+ core ARM) and Windows (with a 4-core i7) that use the Stockfish chess engine, and compare their performance when running on CPUs with comparable nominal clock speeds. The engine running under Windows on the i7 will absolutely DESTROY the Android ARM's performance by several orders of magnitude. It's not even a close race.