I think Nemesis was hypothesized to be a brown dwarf... dim (compared to Sol, at least) like red-hot lava, and so far away it's not even visible (at least, not enough to stand out against background radiation when Hubble does its large-area surveys). Right now, we haven't seen visible proof that it exists, but nobody wants to put their reputation on the line to say there's *definitely* no such star until we've at least had a few years to search for it using JWT (which I think will have sensors more suitable for finding it than Hubble, if it actually does exist).
If Nemeis DOES exist, it'll pretty much rewrite the book about almost everything we thought we knew about the Solar System out beyond Neptune and Uranus, the same way Hubble & computer analysis of old photographic plates made us realize that Pluto isn't just non-unique... it's merely just ONE of SO MANY dwarf planets, in ~20 years we've gotten to the point where their informal names barely matter anymore because there are too many to memorize anyway besides the dozen or so that are the most noteworthy due to size or history.
Maybe, but tiny vacuum tubes smaller than a thimble existed by the early 1950s. Transistors enabled radios to be "pocket-sized", but the best portable radios of the tube era were ALREADY as small as a typical 1970s-era cassette tape recorder.
Why did most CONSUMER items keep using big tubes? Tubes went bad. Large tubes were commodity items that you could easily buy at local stores, even in small towns. Subminiature tubes were expensive, proprietary, and fixing a device that used them was comparable in difficulty to replacing the broken USB port on a Nexus 7 (ie, not literally impossible... but pretty damn hard, even if you know what you're doing and have the right tools available). On the flip side, subminiature tubes also lasted a lot longer... but in the 50s, consumers EXPECTED tubes to go bad after a few years, and large tubes (based on 30+ year old technology) continued to reinforce that perception.
Put another way... if your table radio seemed to have a tube go(ing) bad, you'd open it up, pull out the tubes, take them to the store in a box, an employee would test them, and you'd go home with a new tube or two to replace the bad one(s). If your "ultraportable" radio seemed to have a tube go(ing) bad... you kept using it until it either became intolerably flaky or died outright... and then you threw it in a closet, basement, attic, or garage, where it sat gathering dust for years until you died & someone finally threw it out (kind of like older Android & Apple devices with cracked screens... not valuable enough to fix, but too expensive to throw away).
> How the hell are devs expected to do work when they have to deal with kangaroo court type of crap on > a daily basis with so much time spent finger pointing?
That's mainly a failure of management. An ideal Scrum meeting is kind of like a group therapy session. The moment management allows Scrum to devolve into blame-hurling and judging, you've eliminated the major point OF those stand-up meetings.
Programmers in general have a serious tendency to get caught up in "X-Y problems" (they need to solve problem X, but don't know how... then somehow get the idea that solving problem Y will at least put them on the path towards solving X, ultimately get so wrapped up in Y that they completely forget about X, and ultimately come up with a brilliant, creative solution to the wrong problem). Well-managed Scrum acts like a circuit breaker that helps to tame those X-Y problems, because most X-Y problems are quickly discovered the moment one programmer tries explaining his rationale to the others (things that seem totally sensible to one person caught in a loop usually look absurd to others).
The point is, Scrum meetings SHOULD be one of the intellectually-stimulating high points of the day, when team members show up feeling hopeful about finding solutions & excited about sharing their knowledge, and go away feeling satisfied and encouraged. Unfortunately, in the real world, they often DO devolve into blame sessions and kangaroo courts.
That's the big problem with SMS government-issued warnings -- the inevitable growth of StupidWarnings, like "flash flood" alerts in South Florida (asteroid-strike tsunami notwithstanding, a genuinely life-threatening rapid surge of raging floodwater is basically impossible in South Florida... but that doesn't stop them from sending the warnings just because a major road a few miles away got flooded due to a clogged storm drain). Or "hurricane warnings" sent at 6:30am two days before predicted landfall (hint: unless you're a literal shut-in without windows and no TV, you'll know a tropical storm system is approaching DAYS beforehand. The visibly-rotating clouds across hundreds of miles are *unmistakable*). Oh, and "forest fire" warnings due to Everglades brush fires 15 miles away.
These aren't hypothetical... I've gotten "urgent" warnings for all three. I mean, fuck, of COURSE I want to know about active tornadoes confirmed to be nearby (or *overwhelmingly* likely to touch down fewer than 3 miles away within the next 8 minutes), but quit wasting my time with stupid warnings for things that aren't literal life-and-death emergencies. And that includes warnings for tornadoes more that 15 miles away. NWS also seems to treat a tornado ANYWHERE in the same county as a county-wide emergency, even though they can supposedly send SMS warnings with cell-tower granularity.
64-bit Windows requires signed drivers, but (contrary to popular misconception), they don't *have* to be Microsoft-signed WHQL-approved drivers. You can actually generate your own signing key & repackage older drivers for win64... the only catch is that win64 treats drivers signed by an untrusted key the same way win32 treats drivers that aren't signed at all.
In other words, all win64 drivers have to be signed, but some signatures are more equal than others.
Those $6 USB soundcards are mass-produced items built around a single chip. If you tried building an equivalent one using discrete components purchased from DigiKey, you'd be *lucky* if the parts cost were less than $100.
Btw... cheap USB soundcards are *really* temperamental unless you have a multi-TT USB hub. And even then, they tend to cause wacky problems (let's just say they don't usually play nicely with other USB devices sharing the same hub).
It's probably using FTDI FIFO-bridge chips in 'bitbang' mode to emulate a legacy parallel port. The (e)eprom programmer itself is probably a parallel-port design hardwired to a USB FIFO bridge(*). Bitbang-mode is hard to pull off with USB (especially at higher speeds) because it needs deterministic servicing by the OS (ie, it needs the host OS to read or write small chunks of data with lockstep regularity).
(*) believe it or not, most "USB" scanners are REALLY SCSI-1 scanners, internally chained through a SCSI-to-Parallel bridge, chained through a Parallel-to-USB bridge. It wasn't until the VERY recent past (~4 years, give or take) that companies like FTDI added native-SCSI, native-ATA, and native-JTAG to the capabilities of their USB bridge chips (allowing operation with more relaxed timing than trying to use USB to bitbang a parallel port in realtime).
Parallel port designs are hard to update for USB, because they often require a level of precise timing that Windows doesn't want to allow, and USB is fundamentally INCAPABLE of deterministically guaranteeing. To do it "right", you have to move a big chunk of your control logic to the peripheral itself (including some degree of local buffering).
For a concrete example: you can build a parallel-port based 8-bit logic analyzer capable of sampling at around 100,000 samples/second, using only a db25 connector and wires. Doing it with USB requires moving all the sampling logic to the other end of the USB cable, and usually storing the data in a large SRAM buffer for subsequent "chunky" transfer to the host PC. That's why cheap USB-based logic analyzers are so limited in terms of sample rate, while older parallel-port analyzers could chug along nonstop until you ran out of ram or disk space (depending upon how fast your disk i/o was).
I can think of a far more efficient way to exfiltrate data from a network: write a program to generate 2D color bitmaps and display them onscreen to photograph them.
If you're using remote desktop and can do screen captures, you can literally pack up to 24 bits into every single pixel on the screen.
Worst-case, with a high-end Android phone's ~12 megapixel camera photographing the screen, you could pack at least 8 bits into every 4x4 pixel square (2x2 of color, separated from adjacent data blocks by 2 pixels of black... 4 bits of green, 2 bits of red and blue) and export about 128k bytes per 1920x1080 screen (giving you 470 * 270 4x4 blocks). If you could hold the camera steady enough and capture 2160p30 (for a bit of oversampling headroom), that would allow you to capture a little under 4 megabytes per second.
Or if they can make voice calls, I think even JAVASCRIPT is now fast enough to bitbang Bell103 FSK (a/k/a "300 baud acoustically-coupled modem"). And if they want to be really clever & can install something better, they could use phase modulation to hide it in an innocent-sounding song playing during their phone conversation.
Moral of the story: the most robust network airgap is still potentially useless against a trusted individual with physical access. A single layer of technical security will get you only *so* far... at some point, the biggest single factor in keeping sensitive data secure is making sure that anyone with physical access to it is, in fact, trustworthy... and treat them well, so they won't have any reason to stop being trustworthy.
What archivists REALLY need is a playback device with enough tiny heads to read the tape in linear fashion, with enough oversampling to allow complete capture with a single pass, then post-capture analysis to find the original diagonal tracks and do "digital tracking". This is a huge problem with current archiving methods that depend on semi-manual tracking control... it makes capture *hugely* time and labor intensive. If we could confidently do "one pass now to preserve its current state onto some longterm-stable medium and stop the degeneration clock", with enough redundancy to let future generations restore the recordings they themselves care about, it would be much easier.
Tip: when archiving your own recordings, MAKE SURE the VERTICAL resolution is 480/525 or 540/625(?) -- VHS has shit horizontal resolution, but fairly good vertical resolution. Also, don't skimp on the bitrate or horizontal resolution if you ever want to do restoration on it... noise and blur requires WAY more bits to accurately encode than clean, crisp video. If you have enough room to store more than an hour of captured VHS on a DVD, you're "doing it wrong". Also, NEVER use dual-layer DVD+R/DL... the lower layer will decay & become unreadable LONG before the upper layer. And don't archive to hard drives for long-term cold storage... most of them won't work 20 years from now, and at least half won't work 10 years from now.
Later VCRs were lighter because they substituted plastic for metal, and substituted better DSPs more capable of tolerating slop than older models, which required fairly tight tolerances. The problem is, due to the way VHS geometry works, it's entirely possible to have two VCRs with sloppy alignment & operation that can play THEIR OWN sloppy recordings just fine, but choke on sloppy recordings made by OTHER VCRs. Even back around 1999-2001, people were noticing (and commenting in posts online) that tapes recorded on one VCR tended to play poorly on other people's VCRs, even though older tapes (and most pristine prerecorded tapes) played fine on both.
Somewhat counter-intuitively, I've noticed that my OLDEST (mid/late-80s) VHS tapes are in MUCH better shape than the tapes I made between 1995 and 2004. My theory: in the 80s, a VCR & its tapes were expensive, well-made precision hardware. By the late 90s, they were just cheap shit -- recorders AND tapes. I think my early-80s tapes weigh as much as 3 or 4 late-90s tapes.
Yeah, just *try* running a CPU that's in the same class as a quadcore+ i7 @3.0+ Ghz... with a high-spec gaming-quality GPU... in a device with the form factor of a Nexus 4... and run it at full speed. If it DOESN'T melt itself, it'll be hot enough to give your hands & fingers second-degree burns.
I remember seeing a lengthy discussion about this on an Android forum... someone made a custom ROM that could be configured to wipe the phone if you touched the fingerprint sensor with one or two specific "kill" fingers (say, your ring finger, or your ring finger followed by your middle finger to silently confirm).
The general consensus: you'd have to be *insane* to use it to do something as brazen as a factory reset. Especially if you're doing it just to make a legal statement... the US legal system doesn't take kindly to being trolled, and most people who go against a court to assert their constitutional rights end up paying a terrible price and suffering badly for it, EVEN IF they ultimately prevail and get vindicated years later.
The subsequent consensus: if you're going to do it, make sure it runs discreetly, and ALSO make sure it leaves the phone in a state that looks sufficiently plausible to ward off more intensive forensic analysis (and know that if you *do* get caught doing it, you're totally fucked).
> 300 Baud is plenty, stop thinking in your silly webpage
That might have been true for credit card terminals prior to chip verification (that basically just had to dial in, confirm that the card number, expiration date, and (maybe) CVV was legit, and get confirmation that the transaction was likely to be approved... but with NEW cards that have a chip for authentication, a 300-baud CC terminal will take upwards of TWENTY SECONDS to complete a single transaction due to all the handshaking and (relatively) large blocksize required for robust encryption. Twenty seconds doesn't sound like a lot, but for a business that has multiple customers in line at any moment in time (say, McDonalds or a grocery store), adding that much time to every transaction would be crippling. McDonalds (just to name one company) has spent literally MILLIONS to make sure that the total time from "swipe" to "thank you, here's your receipt" is never longer than 5 seconds.
Approximately 10-20% of women actually have two variants of red and/or green cones... one inherited from each parent.
Somewhere between.1% and 1% of women are believed to be "perceptibly" tetrachromatic... half of their "red" cones are 'normal', while the other half are shifted far enough towards green to act like 'yellow-orange' cones (the same red variant that deuteranomalous men have as their ONLY red cones). The HARD part is testing for it, because nearly everything in modern life (including LED light & pigments) is optimized for RGB or CMYK color. The colors that a tetrachromatic woman can distinguish are LITERALLY outside the gamut of colors you can print or view on film or a monitor via conventional means. Trying to display them as RGB, or print them as CMYK, is like trying to find a combination of blue and red that makes orange... it can't be done.
Ummm... I have a friend with a second-generation Oculus Rift. It feels like you're sloshing around inside a lava lamp.
60fps isn't the fastest you can see... it's just near the point of "sort of good enough". You can ABSOLUTELY tell the difference between 60fps and 300fps... and can easily see the difference between 50-60fps and 100-120fps viewed side-by-side. Adding motion blur to 50-60fps reduces the difference for prerecorded content, but for realtime low-latency immersive content, the difference is HUGE.
The thing is, framerate is kind of like CPU speed. To really see an, "Ahhh! That's WAY better!" improvement over a given framerate, you basically have to double it. And it depends upon what part of your vision it's in, and the contrast. Pure white on pure black in peripheral vision? You can still see a difference between 600fps and 1200fps. Blurred brown & dark red on black viewed head-on with foveal cones? Even 60-vs-120 will be pretty subtle... unless you're a (rare) individual with abnormally-high density of foveal rod cells and viewing it in a room with dim ambient lighting(*).
---
(*) In which case the foveal rod cells can act like "blue-green" pseudo-cone cells (in fact, there are documented individuals who seem to have an odd form of protanomalous trichromacy without red-dimming, but are REALLY outright deuteranopes whose rod cells act like pseudo-green cones in dim light.
Rod cells also why some guys with protanopia can reliably distinguish between UNLIT red & green LEDs in dim light using peripheral vision, but not between ILLUMINATED red & green LEDs whose brightness has been adjusted to appear equal. When the LEDs are illuminated, their rods shut down. In dim ambient light, green triggers their rod cells more than red does, allowing them to look "different", even if they can't quite put their finger on WHY they look different.
They didn't have infinite resolution... they were STILL limited by dot pitch & shadow mask. An antialiased 720p 19" display would probably look *better* than a typical "Tempest" game's display did... and a 2160x2880 display could probably accurately emulate misconvergence.
Vector was impressive in the early 80s because RAM was expensive & bitmaps were blocky. Modern displays are higher-res than vector displays were even *theoretically* capable of displaying. You can get nearly-flawless "Vectrex" emulation with a "Retina" iPad Mini.
Not really. From Miami (depending on traffic along the way), it can take 10+ hours just to reach the state line (Palm Beach County *alone* can take an hour and a half to traverse due to general gridlock from Boca Raton to Lake Worth). My all-time "3am, no-traffic" record from Miami to Orlando was ~3 hours... normally, it's more like 4-6 if you aren't north of Broward County by 3:30pm (traffic goes downhill *really* fast the moment kids start getting out of school, then 5pm hits while the roads are *still* saturated & the Turnpike & 95 grind to a dead stop in southern PBC)
Besides.1uF caps used between Vcc and ground, and low-ESR caps used by power supplies, capacitor values don't really seem to matter much anymore. At least, not as much as they used to.
Online might be cheaper and have more, but it's going to really, really suck when you need something they used to sell at 2pm on some Saturday to proceed with some project you're working on. Even with overnight shipping, your project is dead until at least Tuesday (maybe even Wednesday, since Amazon Prime seems to have weird, unpredictable times when seemingly NOTHING can be purchased on Monday for overnight delivery on Tuesday... literally EVERYTHING says "order within the next 92 hours and get it on Wednesday". It's like they just randomly shut down nationwide on random Mondays.
Technically, the "Medieval Warm Period" (and the "Little Ice Age" that followed) occurred over the span of just a few hundred years, and made a sufficiently-big difference to flip Greenland from "cold, but still-farmable" to "mostly abandoned, because farming became almost a lost cause there".
Politicians on both sides are guilty of using climate change as a proxy war. The sensible middle ground is to engineer new construction (and future reconstruction/upgrades) to just assume 10 feet of sea-level rise over the next 100 years & assume it's going to happen regardless of carbon or methane arising from human activity.
Florida will not be abandoned to rising seas. If anything, rising seas will cause saltwater intrusion into wellfields, making agriculture in Florida unprofitable (reverse osmosis is expensive, but the economic impact is MUCH bigger on farmers). With farms gone, their now-cheap land (mostly inland) will become attractive to developers. The "coastal poor" sell out & move inland, and their increasingly-soggy old neighborhoods will get bought up, bulldozed, raised by 10 feet, and rebuilt into expensive new homes purchased by the wealthy.
Ironically, climate change will probably cause Florida to grow & become MORE urban. Florida's natural ecosystem will be mostly destroyed... NOBODY is going to pay trillions of dollars to protect abstract swampland... but developers WILL spend billions of dollars teraforming a chunk of that soggy swampland into land suitable for tens of billions of dollars worth of NEW condos, office towers, and malls.
A hundred years from now, Lake Okeechobee will be double its current size, occupy most of western Palm Beach & Broward counties, and be a gigantic freshwater reservoir. The area adjacent to the lake (now farmland) will be home to 25 million new residents, and both coastlines (east & west) will be Manhattan-like expanses of skyscrapers & landscaping, with every hint of Florida's original terrain erased & built-over. In Miami, people will think "Overtown" has ALWAYS been a wealthy residential downtown neighborhood, and "Liberty City" will exist only as the vestigial label on USGS maps next to streets named after French wines, Mediterranean cities & plants, and jewels.
Encryption isn't an insurmountable barrier... it's just a speed bump. Hopefully, a really big one that can't easily be driven around... but a speed bump nonetheless.
Realistically, if you encrypt a 128-bit AES key using a 2048-bit RSA key and follow all current best practices for padding & implementation, you can feel 99.9% confident that an attacker with the resources of a state espionage agency won't be able to defeat it within 5 years... 99% confident they won't be able to defeat it within 10 years, about 95% confident they wouldn't be able to defeat it within 20... and about 10% confident they wouldn't be able to do it within 100 years.
For a good example of how you can end up with an implementation that "works", but has compromised strength, Google "textbook RSA" (RSA is *notoriously* hard to "get right" if you try treating its basic algorithm as a cookbook without paying attention to OTHER details like padding & format of the plaintext).
Lately, Elliptic Curve has gotten more attention, because more than a few people have been getting nervous about our current de-facto RSA monoculture (for asymmetric-key encryption). RSA itself has no immediate threats, but we need to have a credible "Plan B" in case some horrific exploit that can't be mitigated by longer keys gets discovered. At this point, using ElGamal or some other alternative would be a bad idea (RSA is better-understood & not demonstrably worse than alternatives), but that could literally change almost overnight.
> which they'll happily share with whomever pays the most... or any court that orders them to.
That said, Microsoft has UNQUESTIONABLY taken steps to limit the scope of any one court's or government's ability to compromise that master key by using it to encrypt sub-keys used to encrypt sub-sub-keys used to encrypt the *actual* key they'd have to reveal.
Example: a new installation of Windows generates a 256-bit salt (probably derived from the license key or GUID) & stores it locally, then communicates it to Microsoft (who also discerns the country). Microsoft computes the sha256 hash of that salt plus their own sub-sub-key, then repeats it a million times with the output of the previous hash in place of their sub-sub-key. They then communicate the final hash back to the newly-installed Windows, which securely stores a copy & uses IT as its master key going forward. If a future court demands the key, MS obtains the salt from the computer in question, re-derives the key, and shares THAT with the court. Salt unobtainable? Mathematically-impossible to re-derive the key in any sane amount of time. Key revealed? The court can now decrypt THAT computer, but no other. If push came to shove, Microsoft shares the sub-sub-key(s) for that jurisdiction plus the algorithm, and tells them to have fun.
The important point: the master key ITSELF is stored in pieces distributed across multiple jurisdictions, INCLUDING Russia and China... the likelihood that they'd ever act in union is approximately zero. So the US might be able to compel Microsoft to disclose their "US" sub-key(s), and the pieces of the master key that US courts can order the disclosure of, but it would NEVER be able to obtain the complete global master key.
It sounds like in this case, Microsoft has basically generated a new master key for the China-Government edition, delegated responsibility for its safeguarding to China, and washed its hands. It has no implications for non-Chinese users, unless you're using a pirated Chinese-Government copy (which, in all likelihood, will have so much malware added by whomever made the pirated copy available, the theoretical ability of China's government to decrypt it would be the LEAST of your real-world problems).
The places that would REALLY throw fits if other states tried to claim 100% of tax revenues based upon registration address are states like Ohio that have lots of truck traffic passing THROUGH, and cities straddling the Mississippi or Ohio rivers (ex: Cincinnati. Many of its nicest & most desirable suburbs are on the Kentucky side, but nearly everyone WORKS on the Ohio side).
As a compromise, they might tolerate having non-commercial vehicles taxed by registration address & annual miles driven, but require GPS-tracked accounting for commercial vehicles (including taxis, fleets, and rental cars). This would put most of the annual revenue in the "right" place, but avoid the Orwellian implications of doing it to VOTERS. They wouldn't even have to mandate GPS... if large corporations were required to accurately document miles-driven-per-tax-district, their Compliance dep't. would demand GPS as a cost-saving automation.
US state borders are largely transparent to individuals, but quite real to businesses. There's nothing to stop someone from suburban L.A. from buying a non-CARB-compliant lawnmower at a Home Depot in Las Vegas & using it at home, but Home Depot *itself* wouldn't *dare* to sell non-CARB-compliant lawnmowers in California stores.
Slashdot Mirror
> You do realize that "stars" are bright?
I think Nemesis was hypothesized to be a brown dwarf... dim (compared to Sol, at least) like red-hot lava, and so far away it's not even visible (at least, not enough to stand out against background radiation when Hubble does its large-area surveys). Right now, we haven't seen visible proof that it exists, but nobody wants to put their reputation on the line to say there's *definitely* no such star until we've at least had a few years to search for it using JWT (which I think will have sensors more suitable for finding it than Hubble, if it actually does exist).
If Nemeis DOES exist, it'll pretty much rewrite the book about almost everything we thought we knew about the Solar System out beyond Neptune and Uranus, the same way Hubble & computer analysis of old photographic plates made us realize that Pluto isn't just non-unique... it's merely just ONE of SO MANY dwarf planets, in ~20 years we've gotten to the point where their informal names barely matter anymore because there are too many to memorize anyway besides the dozen or so that are the most noteworthy due to size or history.
Maybe, but tiny vacuum tubes smaller than a thimble existed by the early 1950s. Transistors enabled radios to be "pocket-sized", but the best portable radios of the tube era were ALREADY as small as a typical 1970s-era cassette tape recorder.
Why did most CONSUMER items keep using big tubes? Tubes went bad. Large tubes were commodity items that you could easily buy at local stores, even in small towns. Subminiature tubes were expensive, proprietary, and fixing a device that used them was comparable in difficulty to replacing the broken USB port on a Nexus 7 (ie, not literally impossible... but pretty damn hard, even if you know what you're doing and have the right tools available). On the flip side, subminiature tubes also lasted a lot longer... but in the 50s, consumers EXPECTED tubes to go bad after a few years, and large tubes (based on 30+ year old technology) continued to reinforce that perception.
Put another way... if your table radio seemed to have a tube go(ing) bad, you'd open it up, pull out the tubes, take them to the store in a box, an employee would test them, and you'd go home with a new tube or two to replace the bad one(s). If your "ultraportable" radio seemed to have a tube go(ing) bad... you kept using it until it either became intolerably flaky or died outright... and then you threw it in a closet, basement, attic, or garage, where it sat gathering dust for years until you died & someone finally threw it out (kind of like older Android & Apple devices with cracked screens... not valuable enough to fix, but too expensive to throw away).
> How the hell are devs expected to do work when they have to deal with kangaroo court type of crap on
> a daily basis with so much time spent finger pointing?
That's mainly a failure of management. An ideal Scrum meeting is kind of like a group therapy session. The moment management allows Scrum to devolve into blame-hurling and judging, you've eliminated the major point OF those stand-up meetings.
Programmers in general have a serious tendency to get caught up in "X-Y problems" (they need to solve problem X, but don't know how... then somehow get the idea that solving problem Y will at least put them on the path towards solving X, ultimately get so wrapped up in Y that they completely forget about X, and ultimately come up with a brilliant, creative solution to the wrong problem). Well-managed Scrum acts like a circuit breaker that helps to tame those X-Y problems, because most X-Y problems are quickly discovered the moment one programmer tries explaining his rationale to the others (things that seem totally sensible to one person caught in a loop usually look absurd to others).
The point is, Scrum meetings SHOULD be one of the intellectually-stimulating high points of the day, when team members show up feeling hopeful about finding solutions & excited about sharing their knowledge, and go away feeling satisfied and encouraged. Unfortunately, in the real world, they often DO devolve into blame sessions and kangaroo courts.
That's the big problem with SMS government-issued warnings -- the inevitable growth of StupidWarnings, like "flash flood" alerts in South Florida (asteroid-strike tsunami notwithstanding, a genuinely life-threatening rapid surge of raging floodwater is basically impossible in South Florida... but that doesn't stop them from sending the warnings just because a major road a few miles away got flooded due to a clogged storm drain). Or "hurricane warnings" sent at 6:30am two days before predicted landfall (hint: unless you're a literal shut-in without windows and no TV, you'll know a tropical storm system is approaching DAYS beforehand. The visibly-rotating clouds
across hundreds of miles are *unmistakable*). Oh, and "forest fire" warnings due to Everglades brush fires 15 miles away.
These aren't hypothetical... I've gotten "urgent" warnings for all three. I mean, fuck, of COURSE I want to know about active tornadoes confirmed to be nearby (or *overwhelmingly* likely to touch down fewer than 3 miles away within the next 8 minutes), but quit wasting my time with stupid warnings for things that aren't literal life-and-death emergencies. And that includes warnings for tornadoes more that 15 miles away. NWS also seems to treat a tornado ANYWHERE in the same county as a county-wide emergency, even though they can supposedly send SMS warnings with cell-tower granularity.
64-bit Windows requires signed drivers, but (contrary to popular misconception), they don't *have* to be Microsoft-signed WHQL-approved drivers. You can actually generate your own signing key & repackage older drivers for win64... the only catch is that win64 treats drivers signed by an untrusted key the same way win32 treats drivers that aren't signed at all.
In other words, all win64 drivers have to be signed, but some signatures are more equal than others.
Those $6 USB soundcards are mass-produced items built around a single chip. If you tried building an equivalent one using discrete components purchased from DigiKey, you'd be *lucky* if the parts cost were less than $100.
Btw... cheap USB soundcards are *really* temperamental unless you have a multi-TT USB hub. And even then, they tend to cause wacky problems (let's just say they don't usually play nicely with other USB devices sharing the same hub).
It's probably using FTDI FIFO-bridge chips in 'bitbang' mode to emulate a legacy parallel port. The (e)eprom programmer itself is probably a parallel-port design hardwired to a USB FIFO bridge(*). Bitbang-mode is hard to pull off with USB (especially at higher speeds) because it needs deterministic servicing by the OS (ie, it needs the host OS to read or write small chunks of data with lockstep regularity).
(*) believe it or not, most "USB" scanners are REALLY SCSI-1 scanners, internally chained through a SCSI-to-Parallel bridge, chained through a Parallel-to-USB bridge. It wasn't until the VERY recent past (~4 years, give or take) that companies like FTDI added native-SCSI, native-ATA, and native-JTAG to the capabilities of their USB bridge chips (allowing operation with more relaxed timing than trying to use USB to bitbang a parallel port in realtime).
Parallel port designs are hard to update for USB, because they often require a level of precise timing that Windows doesn't want to allow, and USB is fundamentally INCAPABLE of deterministically guaranteeing. To do it "right", you have to move a big chunk of your control logic to the peripheral itself (including some degree of local buffering).
For a concrete example: you can build a parallel-port based 8-bit logic analyzer capable of sampling at around 100,000 samples/second, using only a db25 connector and wires. Doing it with USB requires moving all the sampling logic to the other end of the USB cable, and usually storing the data in a large SRAM buffer for subsequent "chunky" transfer to the host PC. That's why cheap USB-based logic analyzers are so limited in terms of sample rate, while older parallel-port analyzers could chug along nonstop until you ran out of ram or disk space (depending upon how fast your disk i/o was).
I can think of a far more efficient way to exfiltrate data from a network: write a program to generate 2D color bitmaps and display them onscreen to photograph them.
If you're using remote desktop and can do screen captures, you can literally pack up to 24 bits into every single pixel on the screen.
Worst-case, with a high-end Android phone's ~12 megapixel camera photographing the screen, you could pack at least 8 bits into every 4x4 pixel square (2x2 of color, separated from adjacent data blocks by 2 pixels of black... 4 bits of green, 2 bits of red and blue) and export about 128k bytes per 1920x1080 screen (giving you 470 * 270 4x4 blocks). If you could hold the camera steady enough and capture 2160p30 (for a bit of oversampling headroom), that would allow you to capture a little under 4 megabytes per second.
Or if they can make voice calls, I think even JAVASCRIPT is now fast enough to bitbang Bell103 FSK (a/k/a "300 baud acoustically-coupled modem"). And if they want to be really clever & can install something better, they could use phase modulation to hide it in an innocent-sounding song playing during their phone conversation.
Moral of the story: the most robust network airgap is still potentially useless against a trusted individual with physical access. A single layer of technical security will get you only *so* far... at some point, the biggest single factor in keeping sensitive data secure is making sure that anyone with physical access to it is, in fact, trustworthy... and treat them well, so they won't have any reason to stop being trustworthy.
What archivists REALLY need is a playback device with enough tiny heads to read the tape in linear fashion, with enough oversampling to allow complete capture with a single pass, then post-capture analysis to find the original diagonal tracks and do "digital tracking". This is a huge problem with current archiving methods that depend on semi-manual tracking control... it makes capture *hugely* time and labor intensive. If we could confidently do "one pass now to preserve its current state onto some longterm-stable medium and stop the degeneration clock", with enough redundancy to let future generations restore the recordings they themselves care about, it would be much easier.
Tip: when archiving your own recordings, MAKE SURE the VERTICAL resolution is 480/525 or 540/625(?) -- VHS has shit horizontal resolution, but fairly good vertical resolution. Also, don't skimp on the bitrate or horizontal resolution if you ever want to do restoration on it... noise and blur requires WAY more bits to accurately encode than clean, crisp video. If you have enough room to store more than an hour of captured VHS on a DVD, you're "doing it wrong". Also, NEVER use dual-layer DVD+R/DL... the lower layer will decay & become unreadable LONG before the upper layer. And don't archive to hard drives for long-term cold storage... most of them won't work 20 years from now, and at least half won't work 10 years from now.
Later VCRs were lighter because they substituted plastic for metal, and substituted better DSPs more capable of tolerating slop than older models, which required fairly tight tolerances. The problem is, due to the way VHS geometry works, it's entirely possible to have two VCRs with sloppy alignment & operation that can play THEIR OWN sloppy recordings just fine, but choke on sloppy recordings made by OTHER VCRs. Even back around 1999-2001, people were noticing (and commenting in posts online) that tapes recorded on one VCR tended to play poorly on other people's VCRs, even though older tapes (and most pristine prerecorded tapes) played fine on both.
Somewhat counter-intuitively, I've noticed that my OLDEST (mid/late-80s) VHS tapes are in MUCH better shape than the tapes I made between 1995 and 2004. My theory: in the 80s, a VCR & its tapes were expensive, well-made precision hardware. By the late 90s, they were just cheap shit -- recorders AND tapes. I think my early-80s tapes weigh as much as 3 or 4 late-90s tapes.
Yeah, just *try* running a CPU that's in the same class as a quadcore+ i7 @3.0+ Ghz... with a high-spec gaming-quality GPU... in a device with the form factor of a Nexus 4... and run it at full speed. If it DOESN'T melt itself, it'll be hot enough to give your hands & fingers second-degree burns.
I remember seeing a lengthy discussion about this on an Android forum... someone made a custom ROM that could be configured to wipe the phone if you touched the fingerprint sensor with one or two specific "kill" fingers (say, your ring finger, or your ring finger followed by your middle finger to silently confirm).
The general consensus: you'd have to be *insane* to use it to do something as brazen as a factory reset. Especially if you're doing it just to make a legal statement... the US legal system doesn't take kindly to being trolled, and most people who go against a court to assert their constitutional rights end up paying a terrible price and suffering badly for it, EVEN IF they ultimately prevail and get vindicated years later.
The subsequent consensus: if you're going to do it, make sure it runs discreetly, and ALSO make sure it leaves the phone in a state that looks sufficiently plausible to ward off more intensive forensic analysis (and know that if you *do* get caught doing it, you're totally fucked).
> 300 Baud is plenty, stop thinking in your silly webpage
That might have been true for credit card terminals prior to chip verification (that basically just had to dial in, confirm that the card number, expiration date, and (maybe) CVV was legit, and get confirmation that the transaction was likely to be approved... but with NEW cards that have a chip for authentication, a 300-baud CC terminal will take upwards of TWENTY SECONDS to complete a single transaction due to all the handshaking and (relatively) large blocksize required for robust encryption. Twenty seconds doesn't sound like a lot, but for a business that has multiple customers in line at any moment in time (say, McDonalds or a grocery store), adding that much time to every transaction would be crippling. McDonalds (just to name one company) has spent literally MILLIONS to make sure that the total time from "swipe" to "thank you, here's your receipt" is never longer than 5 seconds.
Approximately 10-20% of women actually have two variants of red and/or green cones... one inherited from each parent.
Somewhere between .1% and 1% of women are believed to be "perceptibly" tetrachromatic... half of their "red" cones are 'normal', while the other half are shifted far enough towards green to act like 'yellow-orange' cones (the same red variant that deuteranomalous men have as their ONLY red cones). The HARD part is testing for it, because nearly everything in modern life (including LED light & pigments) is optimized for RGB or CMYK color. The colors that a tetrachromatic woman can distinguish are LITERALLY outside the gamut of colors you can print or view on film or a monitor via conventional means. Trying to display them as RGB, or print them as CMYK, is like trying to find a combination of blue and red that makes orange... it can't be done.
Ummm... I have a friend with a second-generation Oculus Rift. It feels like you're sloshing around inside a lava lamp.
60fps isn't the fastest you can see... it's just near the point of "sort of good enough". You can ABSOLUTELY tell the difference between 60fps and 300fps... and can easily see the difference between 50-60fps and 100-120fps viewed side-by-side. Adding motion blur to 50-60fps reduces the difference for prerecorded content, but for realtime low-latency immersive content, the difference is HUGE.
The thing is, framerate is kind of like CPU speed. To really see an, "Ahhh! That's WAY better!" improvement over a given framerate, you basically have to double it. And it depends upon what part of your vision it's in, and the contrast. Pure white on pure black in peripheral vision? You can still see a difference between 600fps and 1200fps. Blurred brown & dark red on black viewed head-on with foveal cones? Even 60-vs-120 will be pretty subtle... unless you're a (rare) individual with abnormally-high density of foveal rod cells and viewing it in a room with dim ambient lighting(*).
---
(*) In which case the foveal rod cells can act like "blue-green" pseudo-cone cells (in fact, there are documented individuals who seem to have an odd form of protanomalous trichromacy without red-dimming, but are REALLY outright deuteranopes whose rod cells act like pseudo-green cones in dim light.
Rod cells also why some guys with protanopia can reliably distinguish between UNLIT red & green LEDs in dim light using peripheral vision, but not between ILLUMINATED red & green LEDs whose brightness has been adjusted to appear equal. When the LEDs are illuminated, their rods shut down. In dim ambient light, green triggers their rod cells more than red does, allowing them to look "different", even if they can't quite put their finger on WHY they look different.
They didn't have infinite resolution... they were STILL limited by dot pitch & shadow mask. An antialiased 720p 19" display would probably look *better* than a typical "Tempest" game's display did... and a 2160x2880 display could probably accurately emulate misconvergence.
Vector was impressive in the early 80s because RAM was expensive & bitmaps were blocky. Modern displays are higher-res than vector displays were even *theoretically* capable of displaying. You can get nearly-flawless "Vectrex" emulation with a "Retina" iPad Mini.
Not really. From Miami (depending on traffic along the way), it can take 10+ hours just to reach the state line (Palm Beach County *alone* can take an hour and a half to traverse due to general gridlock from Boca Raton to Lake Worth). My all-time "3am, no-traffic" record from Miami to Orlando was ~3 hours... normally, it's more like 4-6 if you aren't north of Broward County by 3:30pm (traffic goes downhill *really* fast the moment kids start getting out of school, then 5pm hits while the roads are *still* saturated & the Turnpike & 95 grind to a dead stop in southern PBC)
Lucky you! Frys doesn't exist AT ALL in Florida. :-(
Besides .1uF caps used between Vcc and ground, and low-ESR caps used by power supplies, capacitor values don't really seem to matter much anymore. At least, not as much as they used to.
Online might be cheaper and have more, but it's going to really, really suck when you need something they used to sell at 2pm on some Saturday to proceed with some project you're working on. Even with overnight shipping, your project is dead until at least Tuesday (maybe even Wednesday, since Amazon Prime seems to have weird, unpredictable times when seemingly NOTHING can be purchased on Monday for overnight delivery on Tuesday... literally EVERYTHING says "order within the next 92 hours and get it on Wednesday". It's like they just randomly shut down nationwide on random Mondays.
Technically, the "Medieval Warm Period" (and the "Little Ice Age" that followed) occurred over the span of just a few hundred years, and made a sufficiently-big difference to flip Greenland from "cold, but still-farmable" to "mostly abandoned, because farming became almost a lost cause there".
Politicians on both sides are guilty of using climate change as a proxy war. The sensible middle ground is to engineer new construction (and future reconstruction/upgrades) to just assume 10 feet of sea-level rise over the next 100 years & assume it's going to happen regardless of carbon or methane arising from human activity.
Florida will not be abandoned to rising seas. If anything, rising seas will cause saltwater intrusion into wellfields, making agriculture in Florida unprofitable (reverse osmosis is expensive, but the economic impact is MUCH bigger on farmers). With farms gone, their now-cheap land (mostly inland) will become attractive to developers. The "coastal poor" sell out & move inland, and their increasingly-soggy old neighborhoods will get bought up, bulldozed, raised by 10 feet, and rebuilt into expensive new homes purchased by the wealthy.
Ironically, climate change will probably cause Florida to grow & become MORE urban. Florida's natural ecosystem will be mostly destroyed... NOBODY is going to pay trillions of dollars to protect abstract swampland... but developers WILL spend billions of dollars teraforming a chunk of that soggy swampland into land suitable for tens of billions of dollars worth of NEW condos, office towers, and malls.
A hundred years from now, Lake Okeechobee will be double its current size, occupy most of western Palm Beach & Broward counties, and be a gigantic freshwater reservoir. The area adjacent to the lake (now farmland) will be home to 25 million new residents, and both coastlines (east & west) will be Manhattan-like expanses of skyscrapers & landscaping, with every hint of Florida's original terrain erased & built-over. In Miami, people will think "Overtown" has ALWAYS been a wealthy residential downtown neighborhood, and "Liberty City" will exist only as the vestigial label on USGS maps next to streets named after French wines, Mediterranean cities & plants, and jewels.
Encryption isn't an insurmountable barrier... it's just a speed bump. Hopefully, a really big one that can't easily be driven around... but a speed bump nonetheless.
Realistically, if you encrypt a 128-bit AES key using a 2048-bit RSA key and follow all current best practices for padding & implementation, you can feel 99.9% confident that an attacker with the resources of a state espionage agency won't be able to defeat it within 5 years... 99% confident they won't be able to defeat it within 10 years, about 95% confident they wouldn't be able to defeat it within 20... and about 10% confident they wouldn't be able to do it within 100 years.
For a good example of how you can end up with an implementation that "works", but has compromised strength, Google "textbook RSA" (RSA is *notoriously* hard to "get right" if you try treating its basic algorithm as a cookbook without paying attention to OTHER details like padding & format of the plaintext).
Lately, Elliptic Curve has gotten more attention, because more than a few people have been getting nervous about our current de-facto RSA monoculture (for asymmetric-key encryption). RSA itself has no immediate threats, but we need to have a credible "Plan B" in case some horrific exploit that can't be mitigated by longer keys gets discovered. At this point, using ElGamal or some other alternative would be a bad idea (RSA is better-understood & not demonstrably worse than alternatives), but that could literally change almost overnight.
> It's funny that people don't realize that
> MS's holds the master encryption key,
> which they'll happily share with whomever pays the most ... or any court that orders them to.
That said, Microsoft has UNQUESTIONABLY taken steps to limit the scope of any one court's or government's ability to compromise that master key by using it to encrypt sub-keys used to encrypt sub-sub-keys used to encrypt the *actual* key they'd have to reveal.
Example: a new installation of Windows generates a 256-bit salt (probably derived from the license key or GUID) & stores it locally, then communicates it to Microsoft (who also discerns the country). Microsoft computes the sha256 hash of that salt plus their own sub-sub-key, then repeats it a million times with the output of the previous hash in place of their sub-sub-key. They then communicate the final hash back to the newly-installed Windows, which securely stores a copy & uses IT as its master key going forward. If a future court demands the key, MS obtains the salt from the computer in question, re-derives the key, and shares THAT with the court. Salt unobtainable? Mathematically-impossible to re-derive the key in any sane amount of time. Key revealed? The court can now decrypt THAT computer, but no other. If push came to shove, Microsoft shares the sub-sub-key(s) for that jurisdiction plus the algorithm, and tells them to have fun.
The important point: the master key ITSELF is stored in pieces distributed across multiple jurisdictions, INCLUDING Russia and China... the likelihood that they'd ever act in union is approximately zero. So the US might be able to compel Microsoft to disclose their "US" sub-key(s), and the pieces of the master key that US courts can order the disclosure of, but it would NEVER be able to obtain the complete global master key.
It sounds like in this case, Microsoft has basically generated a new master key for the China-Government edition, delegated responsibility for its safeguarding to China, and washed its hands. It has no implications for non-Chinese users, unless you're using a pirated Chinese-Government copy (which, in all likelihood, will have so much malware added by whomever made the pirated copy available, the theoretical ability of China's government to decrypt it would be the LEAST of your real-world problems).
The places that would REALLY throw fits if other states tried to claim 100% of tax revenues based upon registration address are states like Ohio that have lots of truck traffic passing THROUGH, and cities straddling the Mississippi or Ohio rivers (ex: Cincinnati. Many of its nicest & most desirable suburbs are on the Kentucky side, but nearly everyone WORKS on the Ohio side).
As a compromise, they might tolerate having non-commercial vehicles taxed by registration address & annual miles driven, but require GPS-tracked accounting for commercial vehicles (including taxis, fleets, and rental cars). This would put most of the annual revenue in the "right" place, but avoid the Orwellian implications of doing it to VOTERS. They wouldn't even have to mandate GPS... if large corporations were required to accurately document miles-driven-per-tax-district, their Compliance dep't. would demand GPS as a cost-saving automation.
US state borders are largely transparent to individuals, but quite real to businesses. There's nothing to stop someone from suburban L.A. from buying a non-CARB-compliant lawnmower at a Home Depot in Las Vegas & using it at home, but Home Depot *itself* wouldn't *dare* to sell non-CARB-compliant lawnmowers in California stores.