The loophole is, there's nothing in the constitution that says the federal government can't tax citizens directly, then use those funds to bribe/cajole state governments into delegating powers implicitly reserved for states TO federal agencies as a condition of receiving those funds. That's part of the reason why the constitution originally didn't allow the federal government to tax citizens directly. Previously, Congress determined how much each state owed & states had to pay it, but states viewed the funds they paid to the federal gov't. as "their" money to begin with & bitterly resented strings placed on funds "given" back to them (or spent elsewhere). Direct taxation flipped the equation & power balance in favor of the federal government, and more or less directly enabled the federal government's scope to grow to its present size.
That's not to say it's entirely a bad thing. Expanded federal scope is a major reason why an American can move to pretty much any state without having to worry about having his life thrown into relative chaos. If states imposed the equivalent of waiting periods on new residents for what are now federally-funded benefit programs, it would be economically impossible for poorer Americans to relocate -- even if in the long term, they'd be better off. Long-term improvement means little for people like a poor single parent or disabled adult if the short-term consequences would be homelessness, hunger, and/or lack of medical care. Even for more average Americans, the "paperwork cost" of moving to another state would be a significant barrier to moving... even something as trivial as moving 2 miles to get a new apartment that's on the "wrong" side of a state line.
Federal funding is also why we have roads like I-94 across North Dakota. ND probably doesn't get enough direct benefit from it to have spent its own money building a freeway to Montana, but the net long-term benefits to other states (like having a good route between Minneapolis & Seattle) make it worthwhile. For a vivid illustration of what things USED to be like, notice the routes of I-80 & I-76 at the Ohio-PA state line. They're the original Ohio & Pensylvania Turnpikes. Neither state could agree where they should meet, so they both just picked their own routes & dumped into old roads at the state line... approx 10 miles apart. That used to be the norm... good roads within some states, but poor long-distance continuity ACROSS them. Every state line was a detour & traffic jam... and most state governments were ok with that (because getting two states to cooperate on ANYTHING is hard unless you have the feds waving cash under their noses to MOTIVATE them to cooperate).
Chill. Nobody genuinely expects exponential growth to continue indefinitely. Most estimates are that the human race will hit 9-10 billion within the next century, with growth leveling off over time and eventually stabilizing at around a billion per century once the time the world's population hits ~15 billion.
Will humanity survive? Almost certainly, as long as nothing sets us back technologically for more than a year or two (since that level of population can only be sustained via technology-intensive farming & logistics).
Sirius was awesome ~15 years ago... good sound quality, channels that were like hypothetical big-city radio stations... but without ads... and worked even in "radio deserts" like northern Florida.
Emphasis on "was".
Now, even their music channels are bitrate-starved... piss-poor imaging & stereo separation, weird higher-order artifacts, and general "dead" sound. Content-wise, they've become more "XM"-like... good if you used to prefer XM over Sirius, awful if you didn't.
Would I pay $48/year for it? Yeah, I guess. Would I pay full price for it? Not even in HELL. I ditched it 3 years ago when I got tired of playing their silly pricing games every 6 months.
AFAIK, RSA key generation uses a Riemann-inspired algorithm to reduce the time it takes to generate a new key by making it faster to determine whether or not a particular large number is LIKELY to be prime (and thus, a candidate or non-candidate for use in the key).
As I understand it, early RSA keygens produced "weak" keys because their algorithm OVERLOOKED many primes & prematurely eliminated them as candidates. So, an attacker could considerably reduce the number of keys to try by identifying & skipping those same overlooked primes.
It's kind of like saying "I have an 8-character password" & assuming it's equal to 64 bits of entropy (8 single-byte chars x 8 bits/byte). In reality, an attacker knows that it's likely to use only a tiny subset of values (characters that can be directly typed with a normal US keyboard), and likely that they're used in a way that vaguely resembles English words, dates, etc. So it's REALLY more like 50-55 bits at best, and more like 30-40 bits in reality.
In the same way, a "weak" key whose generation ignored a deterministic subset of potential values might "have" 4096 bits if you blindly counted the size of the largest possible values for each prime & added them up, but there might only be 2^128 actual primes within that universe of values, and only 2^48 primes a weak keygen might have actually chosen from.
In other words, the historical problem RSA has had with Riemann isn't that it might be "wrong", but rather that it (or ESPECIALLY software implementations of it) might be TOO conservatively "right" (never mistaking a non-prime for a prime, but occasionally determining that an ACTUAL prime is non-prime).
At worst, if Riemann were "proven" wrong (by identifying non-primes it identifies as prime), it might mean there are a few RSA keys that are fundamentally-flawed & using non-prime numbers, but in real life now, it's more likely for an implementation of it to be flawed... the underlying theory itself has generally worked as expected. The thing is, in advanced math, "always works for me" isn't good enough... formal proof is much more rigorous & difficult.
Traffic at a given intensity might be safer now than it was 20-40 years ago, but traffic intensity HAS generally increased. The population of the US has increased by ~40% over the past 40 years... partly due to immigration, mostly due to Baby Boomers having kids of their own.
Another difference is that young suburban kids are now commuters, too. 50 years ago, an "average" American baby boomer lived in a suburban single-family home & walked less than a mile to an elementary school with a few hundred students. Now, their grandkids in suburbia live in walled townhouse developments (or single-family homes whose roofs practically touch) & attend elementary schools with more students than an average 1950s high school... and usually NOT the geographically-nearest one (thanks to desegregation, magnet schools, and shifting population patterns that mean urban neighborhoods have too many old schools, while new suburban neighborhoods don't have nearly enough).
So, yeah. Net daily travel by school kids HAS increased overall, and most of them do encounter significantly more-intense traffic conditions than their parents & grandparents did.
Java's performance has mostly been a complete non-issue for at least a decade, now.
In language a 1980s programmer would understand, a modern Java app is basically precompiled from source to intermediate object code, then gets its final round of compilation & linking when it runs for the first time on the computer where it's "installed". The "JVM" is now little more than library code that manages the heaps and runtime bindings.
When you consider how much work Windows & Linux now do behind the scenes to keep legacy C++ programs from being a security exploit waiting to happen, an average legacy C++ program NOW runs while wrapped in more of a de-facto "VM" than oldschool Java EVER did.
> but don't know how to write things from scratch.
The problem is, when developers write things like code to do asynchronous http requests "from scratch", they ALMOST NEVER do it "well", let alone "in a way that isn't brittle or completely dysfunctional". Libraries like Volley are like a gift from god to developers AND end users, compared to the clusterfuck mess that we USED to have before Volley'. Async HTTP involves SO MUCH tedious boilerplate code for EVERYTHING, there's ALWAYS going to be the temptation for someone trying to do it all themselves to cut lots of corners... and the only way they WON'T cut those corners is if they end up writing a Volley-like library of their own, which will end up being every bit as huge (but have a lot more bugs, since it won't have the benefit of a few years worth of peer review to stamp out most of the blatant bugs).
Crypto is the golden example of something nobody should EVER attempt to implement on their own, because you WILL inevitably fuck it up and get it wrong. The world is filled with broken, insecure code written by people who treated Bruce Schneier's "Applied Cryptography" book like a howto-cookbook instead of a very, very old & out of date high-level overview. There's even a name for the category of attacks against software whose RSA encryption is based on example code found in old textbooks -- "Textbook RSA".
Location services are another. Before Google created a library wrapper around all of Android's various location sources (tower-based coarse location, GPS-based fine location, third-party services that sniffed wifi SSIDs to guess location based on crowdsourced database lookups, etc), Android location was almost a textbook example of how something so seemingly straightforward could become a tangled mess. The way Play Services does it now isn't perfect, but at least any software that USES Play Services for location will automatically benefit from future improvements to it, instead of stagnating into a timewarp (that was probably still dysfunctional to begin with) the moment the developer ceases active daily development on the program.
There's a good reason why Android apps are now so huge... each app basically carries around its own personal copy of Android's libraries by necessity. By now, everyone has learned that shared libraries are a Really Bad Idea (they seemed like a reasonable compromise back when storage space was scarce and valuable, but over the long term they cause a thousand times as much misery as any short-term benefits they might provide). As a practical matter, most Android devices are AT LEAST an entire version behind Google's "current" release of Android, and few devices EVER get more than a patch or two, let alone a complete version update. If it WEREN'T for things like Google's AppCompat library, we'd have basically been stuck in Android 4.0 forever... developers wouldn't have been able to use newer features of the OS since 90% of devices would have used an older version, and manufacturers wouldn't have bothered to update to newer versions because 99% of commercial software would only require that old version ANYWAY. Chicken, meet egg.
The practical logic that recognizes that ~94% of people have close to zero autonomy over their working hours, but employers blindly follow the clock. It's politically easier to change the clock than it is to convince individual HR departments to deviate from their blindly-followed norms.
From what I've heard, the problem in Britain is that almost everyone prefers BST to GMT, but there's an equally-strong nostalgic draw to being on GMT for at least a few months per year... an enduring reminder that Britain was once the literal center and reference point of the civilized world, and everyone *else* defined their local time relative to London's time.
I suspect France will have a similar national dilemma. It didn't get to name GMT, but it DID get to name UTC (or at least, SI did). Europe's geopolitical center might have shifted eastward after Germany reunified and the EU grew... but as long as France gets to have UTC for a few months per year, it can still feel smugly superior and regard itself as the world's timekeeping reference point. Moving to CET year-round would be yet another psychological concession that continental Europe no longer revolves around Paris.
Predictions:
1. France will stick with UTC for the sake of national pride initially, decide it hates early sunsets, and join the rest of Europe in UTC+1 within a couple of years.
2. Britain will come up with a solution worthy of a Terry Pratchett novel... UTC+1 year-round, except on Boxing Day. On Boxing Day, clocks will be turned back an hour sometime early in the morning, solar noon will occur at 12:00 GMT somewhere in Britain (often in London, occasionally near the site of the Greenwich Observatory itself (or at least, somewhere above its parking lot, since the actual meridian is a few hundred feet away from the "ceremonial" meridian's painted line), then clocks will skip from 22:59:59 GMT to 00:00:00 UTC+1, ensuring that the madness & confusion persist for only a single calendar day.
The first year, everyone will think it's cute in the days leading up to it, the day itself will end with thousands of people missing flights and trains due to mass confusion about whether or not the time change is a joke, and a few weeks later Parliament will quietly pass a law making Britain UTC+1 year-round, except for the literal sites of the Greenwich Observatory and Stonehenge (which will be GMT year-round... preserving the symbolism, while sparing 99.999% of Britain's population from having to deal with its consequences).
Personally, I'd be cool with just splitting the difference, and making "Eastern" time UTC-4.5 year-round (and presumably, making "Central" time UTC-5.5, "Mountain" time UTC-6.5, and "Pacific" time UTC-7.5). There's no international law that says timezones HAVE to be limited to whole-hour offsets from UTC.
But yeah, where all the "abolish clock-changing" proposals (besides Florida's) have historically dropped the ball was in their attempt to drop "summer" time, rather than stay on it all year. People hate changing the clock, but they hate driving home from work in the dark(*) even more.
(*) Other parts of the US might be different, but in Miami, evening gridlock gets PROFOUNDLY worse the day after DST ends. Why? Morning traffic is naturally spread out over the span of a few hours. During the summer, so is peak evening traffic... some people leave at 5,a few people with kids might leave earlier, but lots of people don't bother heading home and hitting the road until 6 or 6:30 (figuring traffic will start to let up & they'll get home around the same time anyway). The moment DST ends, though, literally EVERYONE in the office goes running for the door at 5pm & hits the road at once, causing instant gridlock that persists beyond 7pm. A drive that might have taken 45-60 minutes during the summer INSTANTLY turns into a daily 60-100 minute marathon.
It might be a first-world problem, but it's a BULLSHIT problem that doesn't HAVE to exist, and one example of a way we've literally gone backwards in TV design over the past 50 years.
1960s: TV had sound within a few seconds, stable picture within 20-30 seconds, correct picture within 50-60 seconds.
1970s: TV had sound instantly, stable picture within a few seconds.
1980s: hit the power button, TV has picture and sound before you have time to lift your finger from the button.
1990s: same, but if you REALLY objected to the TV drawing 5-10 watts when "turned off", you could go into the setup menu and make it act like a 1970s TV again.
2000s: early CRT HDTVs were like a 1990s CRT TV, but DLP TVs took us back to the 1970s. Nobody noticed HDCP handshaking delay, because the TV itself took even longer for the color wheels to spin up.
2010s: LCD TVs that now require booting (several seconds) when first plugged in (sometimes, even when "warm-started"), and take several more seconds on top of that to make the HDCP copy protection happy. Time-wise, we're back to the goddamn 1970s.
I don't object to progress... I just object to having nice things taken away from me. Compromising usability to save 10-20w 24/7 with a CRT (especially one somewhere like a guest bedroom) was one thing... compromising usability to save some tiny fraction of a watt is silly. My central AC draws around 5,000 watts when it's running, and runs about 60-80% of every hour. Compared to that, the 10-50mW a TV might draw to keep its HDMI link 'hot' isn't even on the radar. I probably use a hundred times that much energy keeping all my goddamn devices with embedded lithium batteries eternally recharged so they won't get ruined by battery failure after 6 months of self-draining nonuse.
Or at least, if they HAVE to put "smart" functions into the TV for the sake of marketing another feature, at LEAST have the decency to do it in a way that doesn't get in the way of using it as a raw computer monitor with a half-dozen HDMI inputs.
Also... don't do stupid things like put a 3840x2160 LCD behind a slightly-oversized bezel so the outer 50 pixels are hidden. On my hierarchy of "shitty, stupid things TV manufacturers do", this goes near the top of the list. It makes life absolute HELL for anyone trying to use the TV as a monitor with Windows. If it's a non-negotiable requirement for some reason, at least give us a menu option to have the TV report its REAL, VISIBLE resolution to Windows, so we won't end up having just about every location Windows uses for "important" things end up hidden behind the bezel.
And please... make sure every meaningful function that's on a menu can be deterministically triggered via the remote control (and HDMI CEC). It's fine to put a single button on the remote that toggles the power state, as long as you include discrete codes that unambiguously mean "turn on" and "turn off" (or, if they listen to my idea about having an intermediate power state that maintains an active HDCP handshake despite the display itself being mostly shut down, discrete codes for "on", "doze", and "off"). Likewise, it's shitty-but-semi-tolerable to have one button on the remote for "input select", as long as there are discrete codes that unambiguously mean, "switch to hdmi{n}, regardless of the display's current state or whether there's even an active signal ON hdmi{n} right now".
Some features that would cost little to nothing to add, but would get some people to actively seek them out:
* Explicit, native support for BOTH 1080p50 and 1080p59.94 (AFAIK, *all* 60fps is REALLY 59.94fps for the sake of backwards-compatibility with NTSC). Seriously, it's 2018. Why the FUCK do we still have TVs sold in America that reject 720p50 and 1080p50 over HDMI, EVEN THOUGH the EXACT SAME GODDAMN HARDWARE (with slightly-tweaked firmware) can do both framerates on TVs sold elsewhere?
* By extension, explicit native support for both 25fps & 30fps "4k" modes (and ideally, 48, 50, 60, 72, 96, 100, 120, and/or 144, bandwidth permitting). Even if it requires sacrificing color depth (due to HDMI-imposed constraints, and/or PWM-imposed constraints).
* Ability to natively be driven at 1080p100 and 1080p120 via HDMI2.x. Or better yet, support for AMD FreeSync or NVidia G-sync. I mean, hell... if a TV is "internally" 100/120hz ANYWAY, why the FUCK arbitrarily limit it to 50/60fps HDMI framerate? Expose it directly as supported display modes, and advertise it as a competitive feature nobody else offers. Call competitors' "100/120hz" modes "fake" in your adds, and promote yours as the only REAL "100/120hz"
* Give us an "instant on" option. Making us wait 5+ seconds for picture & sound after pressing the power button is BULLSHIT. To make HDCP-handshaking happy, keep the link "hot" even when the display is "off" (ie, turn off the LED backlight & LCD itself, but keep the interface powered up & making the HDMI source THINK the TV is "on").
In other words, the display has four power states:
1. HDMI on, Display lit up & active
2. HDMI on, display dark (but HDMI source doesn't know that)
3. HDMI off, display dark. What most LCD TVs now call "off"
4. No power. Physically switched off or unplugged.
I'll pay for the extra quarter-watt of power, dammit. Just don't make me stare at a blank/blue screen for 5 seconds due to HDCP handshaking just to make the eco-freaks happy.
44.1KHz might be the Nyquist minimum for 22.05KHz, but remember... the ONLY thing Nyquist actually *guarantees* is that a sampling rate less than twice the highest frequency will be inadequate & suck. If you want to avoid higher-order artifacts (think: wheels in film appearing to roll backwards), Nyquist minimum isn't good enough. Even with 44.1KHz sampling, frequencies above ~12KHz need light filtering. Increase the sample rate to 4x max frequency (88.2KHz+), and 90-99% of the 44.1KHz artifacts go away.
So, why 192KHz? For historical reasons, music is 44.1, but movies are 48. Double both to eliminate nearly all audible higher-order artifacts, and you get 88.2 and 96. But if you have to do realtime digital mixing of both, you need to at least double again to avoid the majority of bit-slip mixing errors (and preferabiy, quadruple). So even 192KHz is a technical compromise that effectively gives you 4x oversampling with 44.1 & 48, or 2x oversampling with 88.2 & 96.
Put another way, when digitally mixing source at two different sample rates, Nyquist kicks in all over again... but even worse, because you ALSO have bit-clock-synchronization to worry about. If your output is locked to 48KHz, playback of 44.1KHz source will always be compromised. If your output is locked to 96KHz, 44.1 will be slightly compromised relative to 48, but 99% of the second-order artifacts you'd get if locked to 48khz are mitigated.
TL/DR: Nyquist is a rock-bottom minimum, not a guarantee of adequacy. To eliminate more complex & subtle errors, especially when digitally-mixing (and even moreso when bit-clocks aren't synchronized or stable), you need much, MUCH higher sample rates than Nyquist appears to suggest based on source-audio frequency alone.
I don't remember the exact reason, but my dad (a major audiophile) told me that all of the various 1970s-era Quad encoding schemes had some major, fatal flaw that didn't really become obvious (to anyone outside the industry itself) until lots of people had quad setups & they realized it was endemic rather than just their own fault. From what I recall, the "sweet spot" was REALLY small (like, in a 10x12 foot room, something like a 1x2 foot zone), and the speaker placement wasn't compatible with normal stereo listening. It was probably something that COULD have been fixed after the fact with modern digital signal processing, but in the 70s, that kind of DSP power didn't even exist for STUDIOS, let alone home use.
What, you don't enjoy listening to music with lossy compression in glorious MONAURAL?
I really think the mid-90s were the high water mark for music reproduction... CDs had become the norm, everyone had AT LEAST a respectable pair of bookshelf-sized speakers paired with a subwoofer big enough to do 80-100hz properly, and an amp with 50W (RMS) per channel was the baseline norm. Then came mp3, iPods, and the Loudness War, and everything totally went to shit. We're literally back at the point where music doesn't sound much better than a 1960s large FM table radio did. And that really sucks.
Surround sound with 96khz 24-bit audio was supposed to be the NORM by now. And it probably would have been, if the music industry and consumer electronics industries hadn't fucked up SACD so completely and thoroughly with DRM.... then given in to the Loudness Wars to make CDs sound even worse than low-bitrate MP3s thanks to clipping (CLIPPING, for fuck's sake!)
Rules that blindly enforce arbitrary combinations of specific characters piss me off to no end.
A rule that passwords must have an uppercase letter adds, at best, 1 to {len-1} bits of entropy. Rules that mandate 1+ digits add (at best) another bit of entropy (1/4-1/2 bit x {len-2}). Ditto for "special characters" if the set of acceptable characters is limited to a subset of those in ASCII that can be directly typed, as opposed to "any unicode value".
If any rule has to be enforced, it should be based on some total number of bits, based on the fewest-possible bits that could plausibly represent the character... adjusted downward for more-guessable characters. Say, 100-128 bits minimum. For example:
* Password is all-lowercase or uppercase Latin alphabet: 5 bits/character, 20-26 chars min.
* Mixed-case Latin alphanumeric, possibly with symbols commonly found on US-layout keyboard: 6 bits/character, 17-20 chars min.
* Everything else: (total UTF-8 bytes) x 6 bits (ex: 10 Cyrillic letters, 5 Chinese characters, 8-9 Hangul jamo, etc)
* Modifiers: each recognized dictionary word or word found on list of hacked passwords (after normalizing digits/punctuations to L33t-speak) reduces entire sequence of matching characters to 16-20 bits (the size of the dictionary)
* Chinese & Kanji characters on the "must learn to graduate high school" list for their country are counted as 10-11 bits... 9 if they're among the 500 most common, 8 if they're among the 100 most common. Alternatively, for simplified Chinese, count 6 bits per Wubizixing keystroke & use smallest calculated value. So someone in China using only common characters might need 10-15 to meet a 120-bit minimum.
You're assuming European-produced content WOULD be "arty-farty", and not just another TV series based on a Marvel Comics franchise... but shot in Europe instead (using English-speaking European actors). European studios are as capable of churning out Hollywood-type content as American studios are. Look at the credits for most big-budget TV shows in the US. A *LOT* of their production already takes place in Europe (France is a big center for CGI, just to name one example).
The yellowing is due to flameproofing chemicals. Put the yellowed bricks in a Ziploc bag, add enough 40-volume cream-type peroxide developer for hair dye, seal the bag, and leave it in the sun for a few hours (shake the bag every 30-60 minutes to redistribute the peroxide).
If you're *really* careful, you can also apply it with a brush to whiten things like an Amiga mouse, Intellivision II gamepad, etc. Just don't let it get on the circuit boards or active components.
What the EU intends: TV shows that remain faithful to the vision of each country's own distinct culture.
What will really happen: Netflix films 20 new TV shows based on... what else... Marvel or DC Comics, but has them produced in the EU instead of the US or Canada. Except they all follow Hollywood norms, have casts fluent in English & are produced IN English(*) so they can be directly monetized as-is in the US and internationally, and end up practically extinguishing what's left of that country's "culturally distinct" film industry (because everyone involved with the country's film/tv industry ends up being too busy chasing after Netflix's money).
Oh... and lots of low-budget reality-TV and game shows, because they're just about the only kind of show you CAN profitably make if your total market and language community only has a few million potential viewers.
The thing lots of people overlook is that "Hollywood" isn't a place. It's not even necessarily AMERICAN anymore. It's a business model that has proven over time to be wildly profitable & has spread over the globe.
Case in point: how would you classify the nationality of a TV show like "Game of Thrones"? Most of its cast members are European. Practically every scene was filmed in Europe. The CGI and production are done in Europe.
---
(*) Or possibly, shoot scenes involving visibly-spoken dialogue twice, back to back... once in English, and once in the country's official language. It would cost more, but not THAT MUCH more since you'd be using the same cast (they're all bilingual, remember), the same CGI, and could do the editing workflow in parallel... and you'd end up with two versions, both of which were a first-quality original shot in their respective languages.
I can't cite any specific examples, but I'm pretty sure this is ALREADY happening with big-budget Hollywood films co-produced with Chinese studios... two directors & casts [possibly with a few actors shared by both], shooting back to back using the same sets, extras, and CGI.
I'm pretty sure that American electrical safety codes prior to sometime before 1970 allowed non-insulated chassis screws with ungrounded (but polarized) 2-blade plugs. One of my grandmothers had a popcorn popper (Magic Chef, I think) that would give you a nasty shock if you touched anything metal, including the screws fastening the bakelite handle & feet to the metal body. Ditto for my other grandmother's TV (color 26" console, bought sometime before I was born or sentient)... if you touched a screw on the back, you'd get shocked.
It's mind-blowing how many dangerous practices & designs were totally 100% legal in the US prior to approximately the 1980s. As long as few people literally *died* (and the few who *did* could be blamed for standing in water), getting shocked was seen as a totally normal occurrence, instead of evidence of a fundamentally-flawed & dangerous design.
Do British plugs or outlets ALSO contain GFCI or AFCI protections? Likewise, are British appliances allowed to take for granted that hot & neutral are correctly polarized, or do they have to assume the two *could* plausibly be reversed & design accordingly with double-chassis isolation?
If British applianes (like most American appliances made prior to ~1980) are allowed to assume that correct polarity is guaranteed & 'neutral' really IS 'neutral', connecting one to an American hot+hot+ground 220v outlet (using a hacked power cord) could be quite dangerous, especially if the outlet's 'ground' was less than ideal. In the US, at least, it was once common for appliances to take correct polarity for granted & expose things like chassis screws that *could* become energized if polarity were reversed by a miswired outlet & ground didn't work properly (or the consumer used d 3-to-2 adapter & didn't bother to connect the ground to anything... which was almost ALWAYS the case).
In continental Europe, they were *never* allowed to make assumptions about polarity, and always had to assume the worst & isolate it accordingly. But because British plugs *had* to be grounded & (afaik) were illegal for anyone besides a licensed electrician to work on, I can definitely see manufacturers in the UK being allowed to take a correctly-wired outlet for granted.
Moral: if you rig up a plug to connect a British device to an American 220v outlet, MAKE SURE the outlet's ground connection is FLAWLESS, and strongly consider putting a GFCI somewhere between the device & panel (so it will instantly break the circuit if ANY current is detected flowing to ground). Because to a British device that assumes 'neutral' REALLY IS 'neutral', an American 220v outlet is going to connect the wire that the appliance ASSUMES is 'neutral' to a 'hot' wire *regardless* of how the outlet is wired (because in the American 220v outlet, BOTH wires are 'hot')
There's NO NEED to make Lego bricks "recyclable", because there's no fucking need TO recycle them... they can be reused as-is. Seriously, I can take a box of Lego bricks from when I was a small child decades ago, and they interoperate perfectly well with a brand new box of Lego bricks purchased now.
It's like hand-wringing about an IBM Model M keyboard being "non-recyclable" -- it's an utterly moot point, because they're still useful today, practically indestructible, and even if damaged, you can almost always take 20 "broken" Model M keyboards and end up with 17-19 working ones after cannibalizing one or two of them for spare parts.
If anything, Lego is worried that TOO FEW Lego bricks end up in landfills, and TOO MANY end up getting passed on to the next generation. Eventually, thanks to exponential growth, we'll end up in a period where newborns end up inheriting a half-million Lego bricks that belonged to their parents, grandparents, and great-grandparents, and have NO NEED for more. Lego has to find some way to make them NOT last forever so that won't happen.
Slashdot Mirror
The loophole is, there's nothing in the constitution that says the federal government can't tax citizens directly, then use those funds to bribe/cajole state governments into delegating powers implicitly reserved for states TO federal agencies as a condition of receiving those funds. That's part of the reason why the constitution originally didn't allow the federal government to tax citizens directly. Previously, Congress determined how much each state owed & states had to pay it, but states viewed the funds they paid to the federal gov't. as "their" money to begin with & bitterly resented strings placed on funds "given" back to them (or spent elsewhere). Direct taxation flipped the equation & power balance in favor of the federal government, and more or less directly enabled the federal government's scope to grow to its present size.
That's not to say it's entirely a bad thing. Expanded federal scope is a major reason why an American can move to pretty much any state without having to worry about having his life thrown into relative chaos. If states imposed the equivalent of waiting periods on new residents for what are now federally-funded benefit programs, it would be economically impossible for poorer Americans to relocate -- even if in the long term, they'd be better off. Long-term improvement means little for people like a poor single parent or disabled adult if the short-term consequences would be homelessness, hunger, and/or lack of medical care. Even for more average Americans, the "paperwork cost" of moving to another state would be a significant barrier to moving... even something as trivial as moving 2 miles to get a new apartment that's on the "wrong" side of a state line.
Federal funding is also why we have roads like I-94 across North Dakota. ND probably doesn't get enough direct benefit from it to have spent its own money building a freeway to Montana, but the net long-term benefits to other states (like having a good route between Minneapolis & Seattle) make it worthwhile. For a vivid illustration of what things USED to be like, notice the routes of I-80 & I-76 at the Ohio-PA state line. They're the original Ohio & Pensylvania Turnpikes. Neither state could agree where they should meet, so they both just picked their own routes & dumped into old roads at the state line... approx 10 miles apart. That used to be the norm... good roads within some states, but poor long-distance continuity ACROSS them. Every state line was a detour & traffic jam... and most state governments were ok with that (because getting two states to cooperate on ANYTHING is hard unless you have the feds waving cash under their noses to MOTIVATE them to cooperate).
Chill. Nobody genuinely expects exponential growth to continue indefinitely. Most estimates are that the human race will hit 9-10 billion within the next century, with growth leveling off over time and eventually stabilizing at around a billion per century once the time the world's population hits ~15 billion.
Will humanity survive? Almost certainly, as long as nothing sets us back technologically for more than a year or two (since that level of population can only be sustained via technology-intensive farming & logistics).
Sirius was awesome ~15 years ago... good sound quality, channels that were like hypothetical big-city radio stations... but without ads... and worked even in "radio deserts" like northern Florida.
Emphasis on "was".
Now, even their music channels are bitrate-starved... piss-poor imaging & stereo separation, weird higher-order artifacts, and general "dead" sound. Content-wise, they've become more "XM"-like... good if you used to prefer XM over Sirius, awful if you didn't.
Would I pay $48/year for it? Yeah, I guess. Would I pay full price for it? Not even in HELL. I ditched it 3 years ago when I got tired of playing their silly pricing games every 6 months.
AFAIK, RSA key generation uses a Riemann-inspired algorithm to reduce the time it takes to generate a new key by making it faster to determine whether or not a particular large number is LIKELY to be prime (and thus, a candidate or non-candidate for use in the key).
As I understand it, early RSA keygens produced "weak" keys because their algorithm OVERLOOKED many primes & prematurely eliminated them as candidates. So, an attacker could considerably reduce the number of keys to try by identifying & skipping those same overlooked primes.
It's kind of like saying "I have an 8-character password" & assuming it's equal to 64 bits of entropy (8 single-byte chars x 8 bits/byte). In reality, an attacker knows that it's likely to use only a tiny subset of values (characters that can be directly typed with a normal US keyboard), and likely that they're used in a way that vaguely resembles English words, dates, etc. So it's REALLY more like 50-55 bits at best, and more like 30-40 bits in reality.
In the same way, a "weak" key whose generation ignored a deterministic subset of potential values might "have" 4096 bits if you blindly counted the size of the largest possible values for each prime & added them up, but there might only be 2^128 actual primes within that universe of values, and only 2^48 primes a weak keygen might have actually chosen from.
In other words, the historical problem RSA has had with Riemann isn't that it might be "wrong", but rather that it (or ESPECIALLY software implementations of it) might be TOO conservatively "right" (never mistaking a non-prime for a prime, but occasionally determining that an ACTUAL prime is non-prime).
At worst, if Riemann were "proven" wrong (by identifying non-primes it identifies as prime), it might mean there are a few RSA keys that are fundamentally-flawed & using non-prime numbers, but in real life now, it's more likely for an implementation of it to be flawed... the underlying theory itself has generally worked as expected. The thing is, in advanced math, "always works for me" isn't good enough... formal proof is much more rigorous & difficult.
Traffic at a given intensity might be safer now than it was 20-40 years ago, but traffic intensity HAS generally increased. The population of the US has increased by ~40% over the past 40 years... partly due to immigration, mostly due to Baby Boomers having kids of their own.
Another difference is that young suburban kids are now commuters, too. 50 years ago, an "average" American baby boomer lived in a suburban single-family home & walked less than a mile to an elementary school with a few hundred students. Now, their grandkids in suburbia live in walled townhouse developments (or single-family homes whose roofs practically touch) & attend elementary schools with more students than an average 1950s high school... and usually NOT the geographically-nearest one (thanks to desegregation, magnet schools, and shifting population patterns that mean urban neighborhoods have too many old schools, while new suburban neighborhoods don't have nearly enough).
So, yeah. Net daily travel by school kids HAS increased overall, and most of them do encounter significantly more-intense traffic conditions than their parents & grandparents did.
Java's performance has mostly been a complete non-issue for at least a decade, now.
In language a 1980s programmer would understand, a modern Java app is basically precompiled from source to intermediate object code, then gets its final round of compilation & linking when it runs for the first time on the computer where it's "installed". The "JVM" is now little more than library code that manages the heaps and runtime bindings.
When you consider how much work Windows & Linux now do behind the scenes to keep legacy C++ programs from being a security exploit waiting to happen, an average legacy C++ program NOW runs while wrapped in more of a de-facto "VM" than oldschool Java EVER did.
> but don't know how to write things from scratch.
The problem is, when developers write things like code to do asynchronous http requests "from scratch", they ALMOST NEVER do it "well", let alone "in a way that isn't brittle or completely dysfunctional". Libraries like Volley are like a gift from god to developers AND end users, compared to the clusterfuck mess that we USED to have before Volley'. Async HTTP involves SO MUCH tedious boilerplate code for EVERYTHING, there's ALWAYS going to be the temptation for someone trying to do it all themselves to cut lots of corners... and the only way they WON'T cut those corners is if they end up writing a Volley-like library of their own, which will end up being every bit as huge (but have a lot more bugs, since it won't have the benefit of a few years worth of peer review to stamp out most of the blatant bugs).
Crypto is the golden example of something nobody should EVER attempt to implement on their own, because you WILL inevitably fuck it up and get it wrong. The world is filled with broken, insecure code written by people who treated Bruce Schneier's "Applied Cryptography" book like a howto-cookbook instead of a very, very old & out of date high-level overview. There's even a name for the category of attacks against software whose RSA encryption is based on example code found in old textbooks -- "Textbook RSA".
Location services are another. Before Google created a library wrapper around all of Android's various location sources (tower-based coarse location, GPS-based fine location, third-party services that sniffed wifi SSIDs to guess location based on crowdsourced database lookups, etc), Android location was almost a textbook example of how something so seemingly straightforward could become a tangled mess. The way Play Services does it now isn't perfect, but at least any software that USES Play Services for location will automatically benefit from future improvements to it, instead of stagnating into a timewarp (that was probably still dysfunctional to begin with) the moment the developer ceases active daily development on the program.
There's a good reason why Android apps are now so huge... each app basically carries around its own personal copy of Android's libraries by necessity. By now, everyone has learned that shared libraries are a Really Bad Idea (they seemed like a reasonable compromise back when storage space was scarce and valuable, but over the long term they cause a thousand times as much misery as any short-term benefits they might provide). As a practical matter, most Android devices are AT LEAST an entire version behind Google's "current" release of Android, and few devices EVER get more than a patch or two, let alone a complete version update. If it WEREN'T for things like Google's AppCompat library, we'd have basically been stuck in Android 4.0 forever... developers wouldn't have been able to use newer features of the OS since 90% of devices would have used an older version, and manufacturers wouldn't have bothered to update to newer versions because 99% of commercial software would only require that old version ANYWAY. Chicken, meet egg.
The practical logic that recognizes that ~94% of people have close to zero autonomy over their working hours, but employers blindly follow the clock. It's politically easier to change the clock than it is to convince individual HR departments to deviate from their blindly-followed norms.
From what I've heard, the problem in Britain is that almost everyone prefers BST to GMT, but there's an equally-strong nostalgic draw to being on GMT for at least a few months per year... an enduring reminder that Britain was once the literal center and reference point of the civilized world, and everyone *else* defined their local time relative to London's time.
I suspect France will have a similar national dilemma. It didn't get to name GMT, but it DID get to name UTC (or at least, SI did). Europe's geopolitical center might have shifted eastward after Germany reunified and the EU grew... but as long as France gets to have UTC for a few months per year, it can still feel smugly superior and regard itself as the world's timekeeping reference point. Moving to CET year-round would be yet another psychological concession that continental Europe no longer revolves around Paris.
Predictions:
1. France will stick with UTC for the sake of national pride initially, decide it hates early sunsets, and join the rest of Europe in UTC+1 within a couple of years.
2. Britain will come up with a solution worthy of a Terry Pratchett novel... UTC+1 year-round, except on Boxing Day. On Boxing Day, clocks will be turned back an hour sometime early in the morning, solar noon will occur at 12:00 GMT somewhere in Britain (often in London, occasionally near the site of the Greenwich Observatory itself (or at least, somewhere above its parking lot, since the actual meridian is a few hundred feet away from the "ceremonial" meridian's painted line), then clocks will skip from 22:59:59 GMT to 00:00:00 UTC+1, ensuring that the madness & confusion persist for only a single calendar day.
The first year, everyone will think it's cute in the days leading up to it, the day itself will end with thousands of people missing flights and trains due to mass confusion about whether or not the time change is a joke, and a few weeks later Parliament will quietly pass a law making Britain UTC+1 year-round, except for the literal sites of the Greenwich Observatory and Stonehenge (which will be GMT year-round... preserving the symbolism, while sparing 99.999% of Britain's population from having to deal with its consequences).
Personally, I'd be cool with just splitting the difference, and making "Eastern" time UTC-4.5 year-round (and presumably, making "Central" time UTC-5.5, "Mountain" time UTC-6.5, and "Pacific" time UTC-7.5). There's no international law that says timezones HAVE to be limited to whole-hour offsets from UTC.
But yeah, where all the "abolish clock-changing" proposals (besides Florida's) have historically dropped the ball was in their attempt to drop "summer" time, rather than stay on it all year. People hate changing the clock, but they hate driving home from work in the dark(*) even more.
(*) Other parts of the US might be different, but in Miami, evening gridlock gets PROFOUNDLY worse the day after DST ends. Why? Morning traffic is naturally spread out over the span of a few hours. During the summer, so is peak evening traffic... some people leave at 5,a few people with kids might leave earlier, but lots of people don't bother heading home and hitting the road until 6 or 6:30 (figuring traffic will start to let up & they'll get home around the same time anyway). The moment DST ends, though, literally EVERYONE in the office goes running for the door at 5pm & hits the road at once, causing instant gridlock that persists beyond 7pm. A drive that might have taken 45-60 minutes during the summer INSTANTLY turns into a daily 60-100 minute marathon.
It might be a first-world problem, but it's a BULLSHIT problem that doesn't HAVE to exist, and one example of a way we've literally gone backwards in TV design over the past 50 years.
1960s: TV had sound within a few seconds, stable picture within 20-30 seconds, correct picture within 50-60 seconds.
1970s: TV had sound instantly, stable picture within a few seconds.
1980s: hit the power button, TV has picture and sound before you have time to lift your finger from the button.
1990s: same, but if you REALLY objected to the TV drawing 5-10 watts when "turned off", you could go into the setup menu and make it act like a 1970s TV again.
2000s: early CRT HDTVs were like a 1990s CRT TV, but DLP TVs took us back to the 1970s. Nobody noticed HDCP handshaking delay, because the TV itself took even longer for the color wheels to spin up.
2010s: LCD TVs that now require booting (several seconds) when first plugged in (sometimes, even when "warm-started"), and take several more seconds on top of that to make the HDCP copy protection happy. Time-wise, we're back to the goddamn 1970s.
I don't object to progress... I just object to having nice things taken away from me. Compromising usability to save 10-20w 24/7 with a CRT (especially one somewhere like a guest bedroom) was one thing... compromising usability to save some tiny fraction of a watt is silly. My central AC draws around 5,000 watts when it's running, and runs about 60-80% of every hour. Compared to that, the 10-50mW a TV might draw to keep its HDMI link 'hot' isn't even on the radar. I probably use a hundred times that much energy keeping all my goddamn devices with embedded lithium batteries eternally recharged so they won't get ruined by battery failure after 6 months of self-draining nonuse.
Or at least, if they HAVE to put "smart" functions into the TV for the sake of marketing another feature, at LEAST have the decency to do it in a way that doesn't get in the way of using it as a raw computer monitor with a half-dozen HDMI inputs.
Also... don't do stupid things like put a 3840x2160 LCD behind a slightly-oversized bezel so the outer 50 pixels are hidden. On my hierarchy of "shitty, stupid things TV manufacturers do", this goes near the top of the list. It makes life absolute HELL for anyone trying to use the TV as a monitor with Windows. If it's a non-negotiable requirement for some reason, at least give us a menu option to have the TV report its REAL, VISIBLE resolution to Windows, so we won't end up having just about every location Windows uses for "important" things end up hidden behind the bezel.
And please... make sure every meaningful function that's on a menu can be deterministically triggered via the remote control (and HDMI CEC). It's fine to put a single button on the remote that toggles the power state, as long as you include discrete codes that unambiguously mean "turn on" and "turn off" (or, if they listen to my idea about having an intermediate power state that maintains an active HDCP handshake despite the display itself being mostly shut down, discrete codes for "on", "doze", and "off"). Likewise, it's shitty-but-semi-tolerable to have one button on the remote for "input select", as long as there are discrete codes that unambiguously mean, "switch to hdmi{n}, regardless of the display's current state or whether there's even an active signal ON hdmi{n} right now".
Some features that would cost little to nothing to add, but would get some people to actively seek them out:
* Explicit, native support for BOTH 1080p50 and 1080p59.94 (AFAIK, *all* 60fps is REALLY 59.94fps for the sake of backwards-compatibility with NTSC). Seriously, it's 2018. Why the FUCK do we still have TVs sold in America that reject 720p50 and 1080p50 over HDMI, EVEN THOUGH the EXACT SAME GODDAMN HARDWARE (with slightly-tweaked firmware) can do both framerates on TVs sold elsewhere?
* By extension, explicit native support for both 25fps & 30fps "4k" modes (and ideally, 48, 50, 60, 72, 96, 100, 120, and/or 144, bandwidth permitting). Even if it requires sacrificing color depth (due to HDMI-imposed constraints, and/or PWM-imposed constraints).
* Ability to natively be driven at 1080p100 and 1080p120 via HDMI2.x. Or better yet, support for AMD FreeSync or NVidia G-sync. I mean, hell... if a TV is "internally" 100/120hz ANYWAY, why the FUCK arbitrarily limit it to 50/60fps HDMI framerate? Expose it directly as supported display modes, and advertise it as a competitive feature nobody else offers. Call competitors' "100/120hz" modes "fake" in your adds, and promote yours as the only REAL "100/120hz"
* Give us an "instant on" option. Making us wait 5+ seconds for picture & sound after pressing the power button is BULLSHIT. To make HDCP-handshaking happy, keep the link "hot" even when the display is "off" (ie, turn off the LED backlight & LCD itself, but keep the interface powered up & making the HDMI source THINK the TV is "on").
In other words, the display has four power states:
1. HDMI on, Display lit up & active
2. HDMI on, display dark (but HDMI source doesn't know that)
3. HDMI off, display dark. What most LCD TVs now call "off"
4. No power. Physically switched off or unplugged.
I'll pay for the extra quarter-watt of power, dammit. Just don't make me stare at a blank/blue screen for 5 seconds due to HDCP handshaking just to make the eco-freaks happy.
44.1KHz might be the Nyquist minimum for 22.05KHz, but remember... the ONLY thing Nyquist actually *guarantees* is that a sampling rate less than twice the highest frequency will be inadequate & suck. If you want to avoid higher-order artifacts (think: wheels in film appearing to roll backwards), Nyquist minimum isn't good enough. Even with 44.1KHz sampling, frequencies above ~12KHz need light filtering. Increase the sample rate to 4x max frequency (88.2KHz+), and 90-99% of the 44.1KHz artifacts go away.
So, why 192KHz? For historical reasons, music is 44.1, but movies are 48. Double both to eliminate nearly all audible higher-order artifacts, and you get 88.2 and 96. But if you have to do realtime digital mixing of both, you need to at least double again to avoid the majority of bit-slip mixing errors (and preferabiy, quadruple). So even 192KHz is a technical compromise that effectively gives you 4x oversampling with 44.1 & 48, or 2x oversampling with 88.2 & 96.
Put another way, when digitally mixing source at two different sample rates, Nyquist kicks in all over again... but even worse, because you ALSO have bit-clock-synchronization to worry about. If your output is locked to 48KHz, playback of 44.1KHz source will always be compromised. If your output is locked to 96KHz, 44.1 will be slightly compromised relative to 48, but 99% of the second-order artifacts you'd get if locked to 48khz are mitigated.
TL/DR: Nyquist is a rock-bottom minimum, not a guarantee of adequacy. To eliminate more complex & subtle errors, especially when digitally-mixing (and even moreso when bit-clocks aren't synchronized or stable), you need much, MUCH higher sample rates than Nyquist appears to suggest based on source-audio frequency alone.
I don't remember the exact reason, but my dad (a major audiophile) told me that all of the various 1970s-era Quad encoding schemes had some major, fatal flaw that didn't really become obvious (to anyone outside the industry itself) until lots of people had quad setups & they realized it was endemic rather than just their own fault. From what I recall, the "sweet spot" was REALLY small (like, in a 10x12 foot room, something like a 1x2 foot zone), and the speaker placement wasn't compatible with normal stereo listening. It was probably something that COULD have been fixed after the fact with modern digital signal processing, but in the 70s, that kind of DSP power didn't even exist for STUDIOS, let alone home use.
What, you don't enjoy listening to music with lossy compression in glorious MONAURAL?
I really think the mid-90s were the high water mark for music reproduction... CDs had become the norm, everyone had AT LEAST a respectable pair of bookshelf-sized speakers paired with a subwoofer big enough to do 80-100hz properly, and an amp with 50W (RMS) per channel was the baseline norm. Then came mp3, iPods, and the Loudness War, and everything totally went to shit. We're literally back at the point where music doesn't sound much better than a 1960s large FM table radio did. And that really sucks.
Surround sound with 96khz 24-bit audio was supposed to be the NORM by now. And it probably would have been, if the music industry and consumer electronics industries hadn't fucked up SACD so completely and thoroughly with DRM.... then given in to the Loudness Wars to make CDs sound even worse than low-bitrate MP3s thanks to clipping (CLIPPING, for fuck's sake!)
Rules that blindly enforce arbitrary combinations of specific characters piss me off to no end.
A rule that passwords must have an uppercase letter adds, at best, 1 to {len-1} bits of entropy. Rules that mandate 1+ digits add (at best) another bit of entropy (1/4-1/2 bit x {len-2}). Ditto for "special characters" if the set of acceptable characters is limited to a subset of those in ASCII that can be directly typed, as opposed to "any unicode value".
If any rule has to be enforced, it should be based on some total number of bits, based on the fewest-possible bits that could plausibly represent the character... adjusted downward for more-guessable characters. Say, 100-128 bits minimum. For example:
* Password is all-lowercase or uppercase Latin alphabet: 5 bits/character, 20-26 chars min.
* Mixed-case Latin alphanumeric, possibly with symbols commonly found on US-layout keyboard: 6 bits/character, 17-20 chars min.
* Everything else: (total UTF-8 bytes) x 6 bits (ex: 10 Cyrillic letters, 5 Chinese characters, 8-9 Hangul jamo, etc)
* Modifiers: each recognized dictionary word or word found on list of hacked passwords (after normalizing digits/punctuations to L33t-speak) reduces entire sequence of matching characters to 16-20 bits (the size of the dictionary)
* Chinese & Kanji characters on the "must learn to graduate high school" list for their country are counted as 10-11 bits... 9 if they're among the 500 most common, 8 if they're among the 100 most common. Alternatively, for simplified Chinese, count 6 bits per Wubizixing keystroke & use smallest calculated value. So someone in China using only common characters might need 10-15 to meet a 120-bit minimum.
You're assuming European-produced content WOULD be "arty-farty", and not just another TV series based on a Marvel Comics franchise... but shot in Europe instead (using English-speaking European actors). European studios are as capable of churning out Hollywood-type content as American studios are. Look at the credits for most big-budget TV shows in the US. A *LOT* of their production already takes place in Europe (France is a big center for CGI, just to name one example).
The yellowing is due to flameproofing chemicals. Put the yellowed bricks in a Ziploc bag, add enough 40-volume cream-type peroxide developer for hair dye, seal the bag, and leave it in the sun for a few hours (shake the bag every 30-60 minutes to redistribute the peroxide).
If you're *really* careful, you can also apply it with a brush to whiten things like an Amiga mouse, Intellivision II gamepad, etc. Just don't let it get on the circuit boards or active components.
Google: "retro-brite"
What the EU intends: TV shows that remain faithful to the vision of each country's own distinct culture.
What will really happen: Netflix films 20 new TV shows based on... what else... Marvel or DC Comics, but has them produced in the EU instead of the US or Canada. Except they all follow Hollywood norms, have casts fluent in English & are produced IN English(*) so they can be directly monetized as-is in the US and internationally, and end up practically extinguishing what's left of that country's "culturally distinct" film industry (because everyone involved with the country's film/tv industry ends up being too busy chasing after Netflix's money).
Oh... and lots of low-budget reality-TV and game shows, because they're just about the only kind of show you CAN profitably make if your total market and language community only has a few million potential viewers.
The thing lots of people overlook is that "Hollywood" isn't a place. It's not even necessarily AMERICAN anymore. It's a business model that has proven over time to be wildly profitable & has spread over the globe.
Case in point: how would you classify the nationality of a TV show like "Game of Thrones"? Most of its cast members are European. Practically every scene was filmed in Europe. The CGI and production are done in Europe.
---
(*) Or possibly, shoot scenes involving visibly-spoken dialogue twice, back to back... once in English, and once in the country's official language. It would cost more, but not THAT MUCH more since you'd be using the same cast (they're all bilingual, remember), the same CGI, and could do the editing workflow in parallel... and you'd end up with two versions, both of which were a first-quality original shot in their respective languages.
I can't cite any specific examples, but I'm pretty sure this is ALREADY happening with big-budget Hollywood films co-produced with Chinese studios... two directors & casts [possibly with a few actors shared by both], shooting back to back using the same sets, extras, and CGI.
I'm pretty sure that American electrical safety codes prior to sometime before 1970 allowed non-insulated chassis screws with ungrounded (but polarized) 2-blade plugs. One of my grandmothers had a popcorn popper (Magic Chef, I think) that would give you a nasty shock if you touched anything metal, including the screws fastening the bakelite handle & feet to the metal body. Ditto for my other grandmother's TV (color 26" console, bought sometime before I was born or sentient)... if you touched a screw on the back, you'd get shocked.
It's mind-blowing how many dangerous practices & designs were totally 100% legal in the US prior to approximately the 1980s. As long as few people literally *died* (and the few who *did* could be blamed for standing in water), getting shocked was seen as a totally normal occurrence, instead of evidence of a fundamentally-flawed & dangerous design.
Do British plugs or outlets ALSO contain GFCI or AFCI protections? Likewise, are British appliances allowed to take for granted that hot & neutral are correctly polarized, or do they have to assume the two *could* plausibly be reversed & design accordingly with double-chassis isolation?
If British applianes (like most American appliances made prior to ~1980) are allowed to assume that correct polarity is guaranteed & 'neutral' really IS 'neutral', connecting one to an American hot+hot+ground 220v outlet (using a hacked power cord) could be quite dangerous, especially if the outlet's 'ground' was less than ideal. In the US, at least, it was once common for appliances to take correct polarity for granted & expose things like chassis screws that *could* become energized if polarity were reversed by a miswired outlet & ground didn't work properly (or the consumer used d 3-to-2 adapter & didn't bother to connect the ground to anything... which was almost ALWAYS the case).
In continental Europe, they were *never* allowed to make assumptions about polarity, and always had to assume the worst & isolate it accordingly. But because British plugs *had* to be grounded & (afaik) were illegal for anyone besides a licensed electrician to work on, I can definitely see manufacturers in the UK being allowed to take a correctly-wired outlet for granted.
Moral: if you rig up a plug to connect a British device to an American 220v outlet, MAKE SURE the outlet's ground connection is FLAWLESS, and strongly consider putting a GFCI somewhere between the device & panel (so it will instantly break the circuit if ANY current is detected flowing to ground). Because to a British device that assumes 'neutral' REALLY IS 'neutral', an American 220v outlet is going to connect the wire that the appliance ASSUMES is 'neutral' to a 'hot' wire *regardless* of how the outlet is wired (because in the American 220v outlet, BOTH wires are 'hot')
There's NO NEED to make Lego bricks "recyclable", because there's no fucking need TO recycle them... they can be reused as-is. Seriously, I can take a box of Lego bricks from when I was a small child decades ago, and they interoperate perfectly well with a brand new box of Lego bricks purchased now.
It's like hand-wringing about an IBM Model M keyboard being "non-recyclable" -- it's an utterly moot point, because they're still useful today, practically indestructible, and even if damaged, you can almost always take 20 "broken" Model M keyboards and end up with 17-19 working ones after cannibalizing one or two of them for spare parts.
If anything, Lego is worried that TOO FEW Lego bricks end up in landfills, and TOO MANY end up getting passed on to the next generation. Eventually, thanks to exponential growth, we'll end up in a period where newborns end up inheriting a half-million Lego bricks that belonged to their parents, grandparents, and great-grandparents, and have NO NEED for more. Lego has to find some way to make them NOT last forever so that won't happen.
Outgassing might be a concern. Even if not directly harmful, it could stink up the place for a REALLY long time.
Proof that most of life's problems can be solved with duct tape or WD-40.
https://thursdayagain.wordpres...