> I was personally surprised they didn't pick Reston
I'm going to guess "Acela" is the reason. Acela's current route (and the NEC) ends at Union Station... but AFAIK, Virginia is about to electrify the CSX tracks from Union Station south to Richmond (and effectively extend the NEC further south, eventually all the way from Richmond to Atlanta). Those tracks pass through Potomac Yards. Likewise, Long Island City is along the same tracks as Sunnyside Yards, and the route Acela follows to reach Boston.
Fast forward 10 years. Amazon buys a building within a block or two of the Acela station in Philadelphia, outfits it with conference rooms, and convinces Amtrak to extend the NY-DC Acela route (by paying to build the two new stations, and guaranteeing Amtrak some minimum amount of annual ticket purchases) so the NY-DC trains begin their run at a new station in Long Island City before stopping at Penn Station for ~15 minutes (not necessarily saving a lot of TIME for Amazon employees, but enormously more convenient), then continuing onward to DC. At the DC end, they stop long enough for DC passengers to disembark at Union Station, then continue south to a new station in Arlington (requires replacement of the Long Bridge to add capacity). Northbound, they do the same thing... start in Arlington & spend 15 minutes at Union Station (not saving time, but offering one-train convenience), then continue to New York and ending at LIC. When New York and DC Amazon employees need to have a face to face meeting, they book a conference room in Philadelphia, print their tickets, and now have a convenient central meeting spot halfway between their DC and NY offices.
As a practical matter, Acela trains terminating or starting at Penn Station sit at Sunnyside Yard ANYWAY until shortly before they're scheduled to arrive at Penn Station. I'm not sure how pressed Union Station is for idle-train storage space, but in any case, if the tracks were electrified all the way down to Potomac Yards, a final hop to Arlington from Union Station wouldn't be much of a problem for Amtrak... it wouldn't increase the total NY-DC travel time, and would almost certainly make it easier for Amtrak to sell more seats on its DC-NY Acela route.
The only real issue would be for Amtrak to decide whether it wanted to have Boston-NY-DC trains stop at LIC. As I understand it, Boston-NY Acela trains all continue onward to DC, but during most of the day, Amtrak runs additional NY-DC Acela trains in between the Boston-NY-DC trains (because more people travel between NY and DC than travel between Boston and NY, and Amtrak's capacity through Connecticut is constrained, so if ALL trains had to run end to end, it would just limit the total number of trains Amtrak could run between NY and DC).
I challenge you to cite 4 consecutive sentences from it (NOT from AOC's silly, stupid FAQ or sensationalist social-media headlines) that you specifically believe best exemplify its alleged call for maoism and the destruction of the American way of life.
Note that I'm not claiming GND is good, desirable, or has any chance of passage. I'm simply challenging you to provide proof that you actually *read* the source document, and aren't just regurgitating breathless hype and buzzwords you read somewhere.
It's AOC's coded language to get vegan support by making them think supporting GND will give them a legal excuse to restrict meat-eating in the name of climate change.
The actual legislation is relatively tame. AOC's interpretation of it (her FAQ) is a hot mess. Pelosi was 100% right to put AOC on a short leash when assigning committee memberships.
Back in 2009, Java's curators had the opportunity to partially mitigate its lack of proper unsigned byte values and eliminate one of its major pain points... the need to explicitly cast hex literals to (byte) for values between 0x80 and 0xff. It was a sensible proposal... instead of silliness like:
byte[] foo = {0x20, 0x40, (byte)0x80};... we'd have been allowed to use a different prefix, and specify it like this:
byte[] foo = {0h20, 0h40, 0h80};
(using a different prefix to avoid ambiguity and make it clear that we intended to assign hex literals as literal bit patterns)
Unfortunately, the committee rejected the proposal, out of concern that it would make it too easy to pretend that byte can be casually treated as an unsigned value & have programmers scratching their heads when the following code failed to work as naively expected:
byte foo = 0h80; int bar = 0h80; if (foo == bar) { }// evaluates to false, because Java upcasts foo with sign-extension to int as 0xFFFFFF80, and 0xFFFFFF80 != 0x80)
Their point wasn't entirely without merit, but IMHO, it was still a stupid decision. The fact is, someone who initializes a byte array with hex literals is probably going to get stung by that once or twice in his life ANYWAY, regardless of whether or not he's forced to explicitly cast values between 0x80 and 0xff to byte.
Having refused to fix Java's handling of hex-defined literals, they proceeded to fuck up Java even worse by adding support for binary literals... and making them behave EXACTLY THE SAME FUCKED UP WAY as hex literals.
The net result is that you are NOT allowed to do this:
byte foo = 0b11111111;
Because... 0b11111111 is treated like 255, and 255 > 127. Never mind the fact that someone going so far as to explicitly specify a literal AS a binary value almost certainly, without doubt, ambiguity, or exception, expects for that literal binary value to get assigned to the target variable.
The committee THEN proceeded to go completely off the rails, and require insanity like THIS:
byte foo = -0b00000001;// foo is now equal to -1
I seriously want to know... in what goddamn universe was that even REMOTELY sane or reasonable? I mean, I've bitched about Java's negative hexadecimal values (like "-0x7f") for years, but NEGATIVE BINARY LITERALS?!? WHAT THE GODDAMN FUCK were they thinking? Nobody, EVER, is going to say, "ooooh, that was such a bold, wise decision".
Note that I'm not complaining about the addition of binary literals... I'm complaining about pretending that a programmer attempting to assign 0b11111111 to a byte means ANYTHING besides literally, "set every goddamn bit in the byte to 1".
The way Java fucked up hex literals from day one can almost be excused as a bad decision made years ago... but perpetuating that bad decision with binary literals just for the sake of fucking it up in a consistent way was STUPID.
The worst thing is, by fucking up binary literals the same way as hex literals, they've slammed the door forever on fixing the problem with hex literals by changing the prefix, because now we have TWO prefixes with fucked up behavior... 0x AND 0b. Had binary literals been added to the language with sane behavior, they could have added the 0h prefix for implicitly-cast hex literals, and called it a day. There might have been some newbies wondering why Java had two different prefixes for hex literals, but eventually, 0x would have simply faded into obscurity, and everyone would have simply used 0h and 0b going forward.
That's the #1 thing I really like about C#... it tries to be consistent, but doesn't do stupid things just for the sake of blind one-size-fits-all consistency. C# made MOST integral types signed by default, but made bytes unsigned by default because 99.999% of the time, if you're dealing with byte values, signed math just gets in the way and causes headaches.
I think a fair compromise would have been to archive photos in excess of the free limit to cold storage, then allow people who later subscribe to have them restored within some reasonable period of time (say, one business day). For example...
1. All photos in excess of the limit as of the new policy date are archived to cold storage, and will be retained for a minimum of 18 months.
2. Customers with photos in cold storage have three different subscription choices:
* $9.95/month auto-renewing. Excess photos are archived to cold storage and retained for at least 1 year if the card gets declined at renewal time. Assumption: user intends to keep renewing, and a lapse is probably an oversight that might not be discovered for several months. Company makes a good-faith attempt to give customer plenty of time to discover the problem and re-subscribe, at which point all photos are renewed.
* $12.95 for 30 days, no automatic renewal. Excess photos are archived to cold storage, and discarded after 90 days unless the subscription is re-activated. Assumption: user is one-shot subscriber who intends to recover his lost pictures, and will never be seen again, so there's no need to retain them longer.
* $49.95/year, with retention policies that depend upon whether or not the customer agrees to auto-renewal. If the customer does NOT agree to auto-renew, excess photos are archived to cold storage and subject to deletion after 1 year of inactivity. If the customer DOES agree to auto-renew, excess photos are archived to cold storage and subject to deletion after 3 years of inactivity (though in reality, might be retained longer if the company later decides it makes economic sense)... if they renew within a year, restoration of archived photos is included with the subscription price. If they DON'T renew within a year, recovery of their archived photos will incur an additional long-term storage fee equal to the current annual subscription fee.
The additional long-term storage fee would be fair, because long-term cold storage -- while cheaper than online storage -- is nevertheless non-free, and the longer old photos sit in cold storage, the less likely anyone will ever care about them or pay to get them back. That said, once they're IN cold storage, the cost to store them for 3-5 years isn't much more than the cost to store them for 1 year, so a surcharge to get the REALLY old ones back would probably still be profitable.
The key here is to follow the principle of least surprise. Most people don't actively curate their possessions on a daily basis. If something like this goes away, it very well might take a couple of months for someone to even notice that it happened, and even longer to realize that they CAN do something about it and actually figure out what they have to do to make it happen.
In the case of legacy customers, they had no explicit reason to assume that their photos might disappear without warning. Anybody who's gotten burned by cloud providers in the past knows enough to never trust ANY cloud-based storage provider with their only copy of ANYTHING, but we'll show some empathy for less-technical people who genuinely had no idea where or how their photos were being stored and are genuinely caught by surprise. ESPECIALLY those who were automagically signed up for an account while setting up a new phone, and had no real understanding of what was really happening.
They could also offer a few additional services at higher cost for customers with annual subscriptions. For example, they could offer a $24.95 option where, if their card gets declined at auto-renewal time, the service would query the credit bureau to see whether the customer is dead (the customer would have obviously given consent for this at the time of ordering the service). If they're dead, one or more of several things could happen: a) one or more accounts held by other people could automatically gain access to the deceased user's photos; 2) At least one, and at most three, designated survivors would be notified
You're right IF you're viewing the code in the context of an IDE.
If you're viewing it as a fragment of printed source code limited to only the code in a single method, reading it offline, and you don't ALREADY intimately understand what the code is supposed to do and how it's doing it (or have a whiteboard full of UML diagrams to refer to simultaneously), Lambdas can be a BITCH to make sense of.
IMHO, a better & more readable syntax for Lambdas that preserved all the meta-information present in an anonymous class (but more concisely) would have been something like:
My favorite quote (made up by me, about 15 years ago) -- "Oracle isn't a database, it's a multi-level marketing scheme driven by an army of indentured vassals that somehow managed to make a really good database whose biggest disadvantage is Oracle itself."
Try doing anything that involves robotics. Or OpenGL ES. Or pretty much anything that involves I2C, reading sensors, or parsing binary data files (like NEXRAD radar sweeps).
After a few hours of having every. goddamn. math. operation. turn into shit like someValue = (byte)((someValue * 2)&0xff);, your brain just turns to jello & you start to forget things... do I have to do the 'and' THEN cast? Cast then 'and'? Do multiple 'ands' throughout the operation THEN cast? Eventually, it starts blurring, and you end up with stupid errors that the compiler won't catch, because the whole reason those stupid errors happened is because the compiler made you play stupid fucking games to try and outsmart it so it would ALLOW you to deal with 8-bit unsigned values.
Clarifying my lambda comment... When you're reading an anonymous class declaration, you know:
1. The name of the Interface the class is implementing
2. The name of the method being implemented.
3. The names of the arguments, in addition to their types.
With Java lambdas, #1 and #2 both end up getting stripped away.
Here's an example taken straight out of Ken Kousen's book, "Modern Java Recipes: Simple Solutions to Difficult Problems in Java 8 and 9"... chapter 1, pages 4-5:
Reading it, we can immediately see that we're calling directory.list with something called a FilenameFilter(), which has a single method named "accept" and takes a File object called 'dir' and a String called 'name', then returns a boolean. It doesn't take a genius to figure out what it does, EVEN IF you've never used a FilenameFilter in your life and have no idea what it does. Between the interface name, the method name, the argument names, and the code inside itself, it's BLATANTLY obvious what it does.
Yeah, this is a somewhat trivial example that most people could figure out, but now imagine that you're using Lambdas with a more obscure interface that the person reading the source ISN'T already intimately familiar with. Or, god forbid, calling a lambda with lambdas as arguments, then chaining it to another lambda (yes, I've seen those). God fucking HELP you if you have to try and untangle a mess like that by hand with nothing but printed sourcecode and Google to help you. It entails something like this:
1. Figure out what kind of object 'directory' is. Remember, in a real program, it won't necessarily be declared one line away. If you're lucky, it's either declared within a screen or two of where it's used... or near the first few screens of source near the top. Unless, of course, it's a static class that's defined within another class definition, in which case it might be somewhere around line 2400.
2. Figure out what kind of objects 'dir' and 'name' are. Once again, remember... real life won't always be as trivial as this example. Happy hunting!
3. Humor me, and pretend that File is a class in some thirdparty library you've never heard of, and you now have to find its javadocs & figure out what kind of arguments File.list expects. Remember, parametric polymorphism. And inheritance, since there might be additional variants declared in the superclass.
4. OK, so, eventually, you figure out that File.list has a variant that takes a FilenameFilter object. Go look up FilenameFilter, and pray to every deity you can think of that you'll find an interface that has a single method that takes a F
Emotionally, Java died for me the day I discovered that C# has real, honest to god unsigned bytes. You have to be masochistic beyond words and the world's ULTIMATE glutton for punishment to attempt programming OpenGL ES using Java, because GLES does EVERYTHING by juggling around byte arrays, and dealing with raw unsigned bytes in Java is pure misery.
It's no secret that 'unsigned bytes' are one of (if not THE) most-requested features in the history of Java. And the one that evokes the angriest ideological debates, often getting it called 'syntactic sugar' (as if providing a language construct to avoid having to do things known to create STAGGERING numbers of insidious code errors due to typos is a morally-decadent thing).
Personally, I love how some people get all righteous about calling unsigned bytes 'syntactic sugar', then proceed to defend dumping six pounds of 'syntactic salt' into Java in the form of the way Java now handles lambda expressions.
Lambda expressions per se aren't necessarily a bad thing. Pretty much every major language now has them. But the specific WAY they were implemented in Java is an abomination. Put bluntly, they're basically "human-compiled" object code PRETENDING TO BE actual source code.
For anyone who doesn't understand what I just said, here's an alternate explanation. Basically, when the Java compiler sees a Lambda expression, it recursively searches through the list of interfaces known to it until it finds an interface that defines a single method whose arguments match the types of those used by the lambda. It takes the compiler (or IDE) a fraction of a second to do a brute-force search through the API to find a match. Humans, unfortunately, aren't quite so agile at things like that, which is why we invented source code in the first place 50 years ago.
Behind the scenes, the compiler is just automatically assembling an anonymous class that implements the interface. And if you had the sourcecode TO that anonymous class in front of you, making sense of it would be easy. The problem is, Java's lambda syntax strips away most of the contextual information that the anonymous class would provide you with, so you're left trying to make sense of a cryptic glob of punctuation characters that makes obfuscated Perl look like Ada or Visual Basic by comparison.
The end result is that if I write a nontrivial program using Java lambda expressions, print out a method, and hand it to you, there's a VERY high likelihood that you'll scratch your head and be completely unable to make sense out of it without at least looking back at the includes near the top, and probably a few minutes with Google. In contrast, if those lambdas had been printed in the source AS anonymous classes implementing the same interface, you'd probably be able to effortlessly make sense of them without a second thought. And that's what's fundamentally wrong with Java Lambda Expressions, in a nutshell. They optimize the wrong problem, and result in sourcecode that's human-unreadable.
One thing to keep in mind when looking at the spectacular new "Geocolor" imagery from NOAA's latest satellites -- it's far less "real" than it appears to be at casual first glance.
The cloud imagery is real & better than anything we've ever had, but contrary to appearances, GOES-17 is NOT a full-color webcam in space. The beautiful blue oceans, lush green terrain, brown deserts, majestic white snow-capped mountains, and glowing city street lights are all computer-generated images with the cloud data overlaid on top. The daylight visible-light cloud imagery is the same 4-bit 1km-resolution greyscale we got from the previous satellites... they're just doing more post-processing now to make it a lot prettier.
Don't get me wrong... the new satellites are a HUGE improvement with respect to their science value and their OTHER sensors. I'm just pointing out that their daytime visible-light imagery isn't nearly the eye-popping improvement it appears to be at first glance.
The REAL absurdity is that today, in 2019, content produced in the US or Canada STILL ends up with different owners of the licensing rights in both countries.
I mean, seriously. I can understand the problem of legacy stuff that was created years ago, back when things like making moving prints, physically transporting them from theater to theater around the country, and promoting them locally was a big deal, but Jesus Fucking Christ on Rollerblades... pretty much ANY English-language TV show or movie that gets produced today and released in one country is practically guaranteed to end up in the other country within a year.
Technically, the media market between the US and Canada is about as frictionless as two media markets can possibly GET. We both use the same TV standard, have the same TV framerates, watch the same TV shows and movies, and listen to the same music.
Before someone brings up Quebec, I'd argue that French-speaking Canadians endure even WORSE grief due to the silliness of US-Canadian licensing complexity. Consider, for example, the tens or hundreds of thousands of French Canadians who live in Florida and New York & have to jump through silly hoops to watch French-Canadian TV shows that haven't yet been officially licensed yet for distribution in the US. Also, there's no need to "protect" French-language shows... French is a major worldwide language with a HUGE international export market, and Canada has become a worldwide film and TV powerhouse precisely BECAUSE most Canadian actors & actresses are now bilingual. In Canada, you can produce a film or movie that shoots close-up speaking scenes twice (once in English, once in French, same actors for both), use the same actors to dub THEMSELVES for the remainder of the scenes, and cost-effectively produce content with "native" production values in BOTH languages.
Incidentally, the "shoot twice... once in English, once in another language" strategy is something that was uncommon in the past, but has become popular in recent years thanks to both cheaper digital editing workflows and multilingual actors. The Norwegian+Netflix TV show "Norsemen" is a perfect example of it -- https://www.youtube.com/watch?... ).
And I'm NOT arguing that the licensing barriers between other countries make much more sense... I'm just pointing out the utter and complete absurdity of the present state of licensing affairs between two countries whose media markets have about as close to 100% overlap as you can get. Of all the things NAFTA has dropped the ball on over the years, this is probably the most galling example of something that SHOULD today be completely frictionless and transparent.
It wouldn't even take much beyond a treaty between the US and Canada & the necessary enabling legislation to declare that henceforth, after some future date, all newly-created (or newly-licensed within the US-Canada market) content licensed for distribution in one country is automatically licensed for distribution in both, and that no contractual language limiting the rights of a licensee to do that will be enforced.
At first, there would be too much legacy content with split rights ownership for much to change... but eventually, there would be enough content with unified licensing that some new service would launch that didn't bother to distinguish between US and Canadian customers, and as a result would only license content AVAILABLE under unified licensing. The aftermath would be a flurry of companies who owned country-specific rights bartering, trading, selling, and buying those country-specific rights to consolidate their ownership and increase the content's value by making IT eligible for licensing to that country-agnostic service.
Eventually, there would be enough licensing-consolidation, even of legacy content, for services like Netflix and Comcast to decide that it simply wasn't worth bothering anymore with content that demanded geographic restrictions, which would render content that COULDN'T be licensed under unified terms almost without commercial value until someone DID manage to buy up and aggregate the distribution rights.
Actually, there's a bigger problem... AFAIK, when an ad agency licenses the rights to use a copyrighted song in a commercial, they pay a lower rate if it's only going to be shown in a regional TV market instead of nationwide. If an advertiser knowingly ran the ad (after paying 'regional' rates) on an affiliate who was known to make it readily available to viewers nationwide, the advertiser itself could be sued by the music's copyright holder.
That's why local affiliates who rebroadcast to viewers out of area usually/always black out the local ads entirely on their uplink feed.
Another possible explanation: fluoride prevents tooth decay that, in the past, would have left someone mostly toothless by middle age. If you have no teeth, gingivitis probably isn't a major problem. If you have all of your teeth, but minimal dental care (beyond fluoridation during childhood), gingivitis is likely to be a major problem later in life. Fluoride didn't cause the gingivitis, it just fixed enough BIGGER problems for gingivitis itself to become a big problem.
Tthere are a few things JWST can do that Hubble can't, but there are a LOT of things Hubble can do that JWST can't. It's more of a step sideways than a step forward.
As an augment to Hubble, it has the potential to be a fantastic resources. As an outright replacement, it kind of sucks.
Making matters worse, JWST's expected service life is shockingly short, and unlike Hubble, NASA appears to really *mean* it when it says it plans to deorbit JWST on schedule (to avoid leaving spacejunk cluttering a Lagrange point). So it's ENTIRELY conceivable that if Hubble gets deorbited with JWST as an alleged "replacement", we'll end up with no comparable space telescopes AT ALL a couple of years later.
The best thing we can do with Hubble right now is to get maximum use from it, then do our best to keep it cheaply re-boosted until such time as we have the ability to do a proper servicing mission on it (replacing its electronics and mechanically-failing parts, but taking advantage of the huge spaceframe and lens that we realistically have no way to replace anytime within the next 15-25 years).
For somewhat of an analogy, imagine that your family runs a tour service on a remote island in the middle of the Pacific Ocean & has a big, London-style double-decker bus that's iconic and wildly popular with tourists. Your grandfather bought it 30 years ago when it was shiny & new, and had it transported to the island in a semi-custom airplane that no longer exists (assume that for some reason, boats can't reach the island... maybe it's surrounded by jagged reefs that would be suicidal to attempt navigating by boat). Today, that old bus is kind of a hot mess... it needs a new engine, the seats are tattered, and it needs a good paint job. A brand new bus would cost less than refurbishing the old one, except for one problem... there's nobody who's CAPABLE of transporting an entire new bus to your island because it's too big to fit into any of today's smaller, cheaper, safer, and more fuel-efficient (but sadly, smaller) cargo planes, so you have to make do with packing replacement parts onto multiple air cargo planes and flying them in if you want to continue having a working double-decker bus on that island.
It's not a perfect analogy, but it makes the point... Hubble has parts that simply CAN'T be replaced anytime soon. If we throw them away by deorbiting it, the capabilities they represent will be gone "forever" (at least, the foreseeable future, quite probably the remainder of our own lives). A limited robotic servicing mission by SpaceX that does nothing but boost Hubble into a higher orbit to buy us another 10-15 years to decide what to do with it would be an extremely prudent investment, because the alternative would be the destruction of a valuable asset that literally can't be replaced at any cost within the next few years.
With the CPU governor disabled (so the timing doesn't screw up the stroke-recognition), I can reliably sustain 30-35wpm via Graffiti (prediction disabled). Beat THAT with ANY soft keyboard without using predictive test^h^hxt. Or even WITH predictive text, as long as you use it to write grammatically-complete sentences with correct capitalization & punctuation.
I suppose most people aren't bothered by quaint antiquities like grammar, capitalization, and punctuation, but I personally find my text entry speed falls to 5-6wpm with prediction enabled, because it feels like I have to keep going back and fixing every 2-3 words because something was incorrect.
And how is that any different from once-proud Harlem brownstones getting subdivided into a half-dozen apartments by the mid 20th century, before the area finally (re-)gentrified and they started turning back into single family homes again (or at least, one family per floor or two, vs one family per former ROOM)?
Old small postwar homes still exist... but the NICE ones are now inhabited by one or two people, not extended families with 4 kids and a grandparent or two.
I'd personally say the nadir of South Florida construction quality was the pre-Andrew 1980s. Pretty much every 1980s-era bathroom in Florida is a biohazard under the wall tile (vapor barriers weren't required, Hardiebacker didn't exist, and it somehow wasn't illegal to use normal drywall (not even the inadequate green kind) around a tub & attach tile using mold-feeding mastic.
Dijkstra was ahead of his time, mostly because he was preaching about concerns that were mostly anal-retentive academic non-issues on the computers computer science majors in the 80s and 90s were familiar with.
On a computer like the Commodore 64, or even an Amiga 500, a program that hijacks the interrupts and takes control is lord and god of its environment. "Works for me" IS good enough, because there aren't many ways it MIGHT work differently on anybody else's identical hardware.
When you fast forward to computers where SMP is the norm, weak memory models are common, and concurrent programming is required... Dijkstra was downright visionary and totally right.
Simply put, you can get away with a lot of shit on a computer where your code is the only thing running and the hardware is mostly identical to everyone else's that you CAN NOT get away with in a multithreaded program that attempts to use a GPU to do realtime calculations in a preemptively-multitasking operating system on a platform with a weak memory model.
Put another way... stuff like this seemingly-innocent Java example generally works fine on a PC with a single-core CPU running Windows 9x (despite having always been officially taboo), but REALLY goes down in flames if you leave it as-is, but run it on a computer with a dual/quad-core CPU, because there's no guarantee that a second thread won't arrive, see that myFoo is no longer null & return and attempt to use it before the first thread finishes CREATING the new Foo object: (google: "double-checked locking")
public static Foo getFoo() {
if (myFoo == null) {
myFoo = new Foo();
}
return myFoo; }
Yes. Back when I was in college, I would have literally KILLED for the kind of computer, phone, and wireless 24/7/365 connectivity I now take for granted & have anxiety attacks without. And I say that as someone who HAD a 1200-baud modem in 1986, and spent the summer after 10th grade staying up all night using PC-Pursuit to connect to bulletin board systems around the world for free at a point in time when a long-distance call to a BBS a hundred miles away cost approximately $15-20/hour, and even fsck'ing QuantumLink cost around $2.50/hour.
The past 10-15 years have been kind of a disappointment in the PC realm, but even circa 2002 when I was playing with my shiny new PalmOS phone, I wouldn't have dared to fantasize about being able to use a service like Youtube as a free music streaming service (ignoring the videos) while driving across the Florida Everglades, let alone play 3D videogames and use it as a 2160x1440 display host for virtual reality software. On the other hand, if you'd told me in 2001 that circa 2010, the display market would be totally stagnated around 1920x1080 monitors and it would take literally YEARS to get back up above the kind of resolution available on a $4,000 2002-era Thinkpad (1920x1600), I would have thought you were kidding.
Ditto, for storage. If you'd told me in 1990 that someday, a MOUSE DRIVER would have approximately 200 megabytes worth of files... and that I wouldn't care, because my computer had a 2-terabyte hard drive, a 1-terabyte removable hard drive in the optical bay, and another 512gb that was like a persistent ramdisk performance-wise, I would have thought you were utterly and completely insane.
CPU-wise, I'd have to say yes and no. In 1988, a 1-GHz 2002 CPU would have seemed like science fiction. In 2002, a 4GHz CPU would have seemed like a sick joke, even when you account for cores, cache, and overall performance.
In terms of keyboards, computers have totally gone to shit. Even Thinkpad keyboards suck compared to the keyboards they USED to have 20 years ago, and suck even MORE compared to the literal low-profile clicky keyboards early-90s high-end laptops used to have. Modern mice are a billion times better than the mice we had in 1990, but I'd take a thumb trackball (with modern optical sensor instead of rollers) over a flat touchpad any day, unhesitatingly. I LIKED thumb trackballs like the one on the DEC HiNote Ultra, and didn't mind first-generation touchpads that emulated thumb trackballs. I absolutely DESPISE modern touchpads (which are designed for people who can't type, and who use them with their index fingers, as opposed to people who keep their hands over the keyboard and try using the touchpad with their thumb).
I miss resistive touchscreens. Capacitive touchscreens are handy for detecting blunt touches, but resistive touchscreens with real DSPs were a thousand times better for things like Graffiti. To this day, I have yet to use a non-rooted Android phone whose CPU governor isn't disabled that's capable of doing Graffiti as accurately as a 16MHz Palm Pilot III.
IMHO, the industry abandoned IrDA long before it had a good replacement... and waited WAY too long to replace 1.44mb floppies with just about anything that was better (Zip drives and LS-120 were too little, too late... but LS-120 would have totally rocked back in 1992, even if they'd only been 25-50mb/disk).
Space exploration? Meh... and yeah. Elementary-school me (late 70s, pre-shuttle) would have been thoroughly unimpressed by today's space program. The entire shuttle era just seemed lame and anticlimactic. My first sentient thoughts regarding space travel involved watching men walking on the moon... and thinking it was a totally normal daily occurrence (because for someone who was born after the first Apollo mission, but was old enough TO remember seeing the final ones live on TV, it WAS a totally normal daily occurrence)... and it seemed like everything NASA did after I finally got to kindergarten was just a step down.
As someone who generally sucks at keeping receipts, and who usually finishes up a home improvement project with several hundred dollars worth of stuff that was bought 15 minutes before closing time (just to make sure I'd have everything I needed to finish some project after the store closed, but before going to bed) or purchased for the sake of having enough extra to avoid having to make 3 trips per day to buy one more {whatever} after the last one was [fucked up | dropped into a hole | not quite enough to finish the job], I'd say being able to make returns without needing a receipt is a pretty HUGE benefit for consumers.
It's minuscule as a percentage of their operating cost, but it's a HUGE amount of money in absolute terms. And mega corporations have a completely different set of priorities than small businesses. A large corporation will replace 75,000 24 month old laptops because their warranties expired and not think twice. A small business might have 5 laptops, each and every one of which is a different make & model. A mega corporation manages its computers remotely, using scripts and expensive utilities and management servers. A small business gets the owner's 17 year old son or daughter to reinstall Windows when somebody's laptop gets malware on it.
There's a HUGE market for POS software for small businesses. And small businesses that DON'T use POS software (like my auto mechanic) use Square with an iPad or Android device.
Small businesses are usually on the bleeding edge of technology, precisely BECAUSE running a small business requires that the owner wear multiple hats, be at least vaguely computer-literate if they want to function in the modern economy, and because there's no CIO and board of directors to either say "No" or demand a detailed 537-page strategy plan with multiple appendices comprehensively documenting its compliance with corporate governance standards, regulatory requirements, and everything else that's expected by large companies.
The days of someone running a computer-free viable small business are rapidly coming to an end, mostly because the few who insist upon doing it are all approaching retirement age or death by now. Computers and small businesses aren't some new "Millennial" thing... small businesses have been using computers since the days of the Commodore 64 and Apple II (if not for POS, then for bookkeeping, scheduling, inventory-management, and supply ordering). Who do you think drove the MARKET for business software back in the 8-bit era? It sure as HELL wasn't large corporations like Sears... THEY had their expensive mainframes from IBM (which they didn't bother to start replacing until the 21st century, which is probably part of the reason why they're in the trouble they are now).
It was small businesses who jumped on 8-bit computers, precisely because they WERE affordable, useful, and didn't require a priesthood of snotty gatekeepers to administer and manage. Computers and small businesses didn't start to become universal until well into the PC-era, but if you went back in time to 1989 and walked around an average strip mall, you would have found at least one computer in at LEAST half the small businesses at that strip mall... starting with the beauty salons and video rental stores (just to name two categories of small-business retail that ENTHUSIASTICALLY embraced computers almost from day one of the microcomputer era).
Mom and Pop stores are the LEAST of the problem. In Miami, at least, "Mom and Pop" neighborhood stores were using computers with cash register software and digital signature capture for credit card purchases YEARS before big companies like Walmart, Publix, and Blockbuster were.
Why? A big company like Walmart, Publix, and Blockbuster has to make large-scale IT decisions that are nationwide in scope, require months of research and bureaucracy, and take lots of time to deploy. A small business owner says "fuck it", he's making one decision for himself, and if spending an extra $250 or so means he won't have to screw with paper receipts anymore when the credit card company does a chargeback on him, he'll spend it in an instant because it makes his life immeasurably easier. It's a lot easier for ten thousand small businesses to make ten thousand individually small decisions than it is for one very large company to make a very big decision that affects ten thousand locations.
This isn't rocket science... if you purchase with a credit card, Home Depot ALREADY DOES this.
If you want to return things:
* Give the items you want to return to the clerk.
* Clerk scans the items, and gives back all the stuff you bought at Lowes and forgot where it came from.
* You swipe all the credit cards you might have used to purchase the returned items.
* Home Depot uses the card data to look for receipts associating a purchase of one or more returned items using that card, and automatically credits the price back to the card.
* For everything else, you provide your ID, and they give you a store credit (the ID is needed to limit the ability to brazenly shoplift items and return them later... if you start returning TOO MANY big-ticket items without a receipt, they'll restrict your ability to get receipt-free refunds of cash purchases in the future.
> California can't even build a train across a flat valley for $25 billion.
The expensive part isn't the flat valley. The EXPENSIVE part is the bored tunnels to get the trains to and from the big cities on the OTHER SIDE of the mountains surrounding that flat valley, and the first and last hundred miles or so of track at both ends. Most of Phase I's cost is actually for the hundred miles or so of track between San Jose and the Modesto area that will be used by CalHSR, but ALSO used for high-speed commuter rail (so people who work in the Bay Area will be able to live in more affordable areas and still have a semi-sane commute).
The fundamental problem with AI in a HR context is that there are well-established laws protecting employees from certain forms of discrimination. No publicly-traded corporation's management would DARE to officially suggest, let alone demand, that its HR staff systematically discriminate against applicants based upon their sex, religion, national origin, etc. in ways that violate against laws, because it would be an open invitation to fines and lawsuits when the policy was inevitably disclosed by a disgruntled former employee.
The problem is, AI-logic (especially deep learning and pattern recognition) tends to be EXTREMELY opaque and impossible for humans to make sense of. That's WHY someone used deep learning in the first place... it's great at spotting patterns that look like random noise to humans. The catch is, if you can't explain the logic, you ALSO can't guarantee that it's not indirectly basing its logic on criteria that are ILLEGAL to consider in the first place.
If you're not at home when somebody rings the doorbell, will you get the notification and be able to launch the viewer app on your phone in time to see who rang the bell before they're in their car backing out of your driveway?
It's not entirely Ring's fault (Google kind of pulled the rug out from under them with regard to push notification timing post-Marshmallow), but the real-world massive time lag was probably the biggest disappointment when I got mine 2 years ago. From my own experience, if you aren't at home & connected to the same wifi network as the doorbell the moment someone presses the button, you'll be lucky if your phone plays the "doorbell" notification within 20-30 seconds. Add another 10-20 seconds to unlock your phone and launch Ring's viewer app, and your likelihood of getting a chance to even SAY anything to whomever rang the doorbell before they're already gone is pretty low.
Even if you're at home & connected to the same wifi network as the doorbell, you almost have to have the phone in your hands & already unlocked to have any chance of getting the "Ring" app launched before whomever rang the doorbell turns around and walks away.
Slashdot Mirror
> I was personally surprised they didn't pick Reston
I'm going to guess "Acela" is the reason. Acela's current route (and the NEC) ends at Union Station... but AFAIK, Virginia is about to electrify the CSX tracks from Union Station south to Richmond (and effectively extend the NEC further south, eventually all the way from Richmond to Atlanta). Those tracks pass through Potomac Yards. Likewise, Long Island City is along the same tracks as Sunnyside Yards, and the route Acela follows to reach Boston.
Fast forward 10 years. Amazon buys a building within a block or two of the Acela station in Philadelphia, outfits it with conference rooms, and convinces Amtrak to extend the NY-DC Acela route (by paying to build the two new stations, and guaranteeing Amtrak some minimum amount of annual ticket purchases) so the NY-DC trains begin their run at a new station in Long Island City before stopping at Penn Station for ~15 minutes (not necessarily saving a lot of TIME for Amazon employees, but enormously more convenient), then continuing onward to DC. At the DC end, they stop long enough for DC passengers to disembark at Union Station, then continue south to a new station in Arlington (requires replacement of the Long Bridge to add capacity). Northbound, they do the same thing... start in Arlington & spend 15 minutes at Union Station (not saving time, but offering one-train convenience), then continue to New York and ending at LIC. When New York and DC Amazon employees need to have a face to face meeting, they book a conference room in Philadelphia, print their tickets, and now have a convenient central meeting spot halfway between their DC and NY offices.
As a practical matter, Acela trains terminating or starting at Penn Station sit at Sunnyside Yard ANYWAY until shortly before they're scheduled to arrive at Penn Station. I'm not sure how pressed Union Station is for idle-train storage space, but in any case, if the tracks were electrified all the way down to Potomac Yards, a final hop to Arlington from Union Station wouldn't be much of a problem for Amtrak... it wouldn't increase the total NY-DC travel time, and would almost certainly make it easier for Amtrak to sell more seats on its DC-NY Acela route.
The only real issue would be for Amtrak to decide whether it wanted to have Boston-NY-DC trains stop at LIC. As I understand it, Boston-NY Acela trains all continue onward to DC, but during most of the day, Amtrak runs additional NY-DC Acela trains in between the Boston-NY-DC trains (because more people travel between NY and DC than travel between Boston and NY, and Amtrak's capacity through Connecticut is constrained, so if ALL trains had to run end to end, it would just limit the total number of trains Amtrak could run between NY and DC).
The official document can be viewed here: https://apps.npr.org/documents...
I challenge you to cite 4 consecutive sentences from it (NOT from AOC's silly, stupid FAQ or sensationalist social-media headlines) that you specifically believe best exemplify its alleged call for maoism and the destruction of the American way of life.
Note that I'm not claiming GND is good, desirable, or has any chance of passage. I'm simply challenging you to provide proof that you actually *read* the source document, and aren't just regurgitating breathless hype and buzzwords you read somewhere.
> stopping cows from expelling gas
It's AOC's coded language to get vegan support by making them think supporting GND will give them a legal excuse to restrict meat-eating in the name of climate change.
The actual legislation is relatively tame. AOC's interpretation of it (her FAQ) is a hot mess. Pelosi was 100% right to put AOC on a short leash when assigning committee memberships.
Back in 2009, Java's curators had the opportunity to partially mitigate its lack of proper unsigned byte values and eliminate one of its major pain points... the need to explicitly cast hex literals to (byte) for values between 0x80 and 0xff. It was a sensible proposal... instead of silliness like:
byte[] foo = {0x20, 0x40, (byte)0x80}; ... we'd have been allowed to use a different prefix, and specify it like this:
byte[] foo = {0h20, 0h40, 0h80};
(using a different prefix to avoid ambiguity and make it clear that we intended to assign hex literals as literal bit patterns)
Unfortunately, the committee rejected the proposal, out of concern that it would make it too easy to pretend that byte can be casually treated as an unsigned value & have programmers scratching their heads when the following code failed to work as naively expected:
byte foo = 0h80; // evaluates to false, because Java upcasts foo with sign-extension to int as 0xFFFFFF80, and 0xFFFFFF80 != 0x80)
int bar = 0h80;
if (foo == bar) { }
Their point wasn't entirely without merit, but IMHO, it was still a stupid decision. The fact is, someone who initializes a byte array with hex literals is probably going to get stung by that once or twice in his life ANYWAY, regardless of whether or not he's forced to explicitly cast values between 0x80 and 0xff to byte.
Having refused to fix Java's handling of hex-defined literals, they proceeded to fuck up Java even worse by adding support for binary literals... and making them behave EXACTLY THE SAME FUCKED UP WAY as hex literals.
The net result is that you are NOT allowed to do this:
byte foo = 0b11111111;
Because... 0b11111111 is treated like 255, and 255 > 127. Never mind the fact that someone going so far as to explicitly specify a literal AS a binary value almost certainly, without doubt, ambiguity, or exception, expects for that literal binary value to get assigned to the target variable.
The committee THEN proceeded to go completely off the rails, and require insanity like THIS:
byte foo = -0b00000001; // foo is now equal to -1
I seriously want to know... in what goddamn universe was that even REMOTELY sane or reasonable? I mean, I've bitched about Java's negative hexadecimal values (like "-0x7f") for years, but NEGATIVE BINARY LITERALS?!? WHAT THE GODDAMN FUCK were they thinking? Nobody, EVER, is going to say, "ooooh, that was such a bold, wise decision".
Note that I'm not complaining about the addition of binary literals... I'm complaining about pretending that a programmer attempting to assign 0b11111111 to a byte means ANYTHING besides literally, "set every goddamn bit in the byte to 1".
The way Java fucked up hex literals from day one can almost be excused as a bad decision made years ago... but perpetuating that bad decision with binary literals just for the sake of fucking it up in a consistent way was STUPID.
The worst thing is, by fucking up binary literals the same way as hex literals, they've slammed the door forever on fixing the problem with hex literals by changing the prefix, because now we have TWO prefixes with fucked up behavior... 0x AND 0b. Had binary literals been added to the language with sane behavior, they could have added the 0h prefix for implicitly-cast hex literals, and called it a day. There might have been some newbies wondering why Java had two different prefixes for hex literals, but eventually, 0x would have simply faded into obscurity, and everyone would have simply used 0h and 0b going forward.
That's the #1 thing I really like about C#... it tries to be consistent, but doesn't do stupid things just for the sake of blind one-size-fits-all consistency. C# made MOST integral types signed by default, but made bytes unsigned by default because 99.999% of the time, if you're dealing with byte values, signed math just gets in the way and causes headaches.
I think a fair compromise would have been to archive photos in excess of the free limit to cold storage, then allow people who later subscribe to have them restored within some reasonable period of time (say, one business day). For example...
1. All photos in excess of the limit as of the new policy date are archived to cold storage, and will be retained for a minimum of 18 months.
2. Customers with photos in cold storage have three different subscription choices:
* $9.95/month auto-renewing. Excess photos are archived to cold storage and retained for at least 1 year if the card gets declined at renewal time. Assumption: user intends to keep renewing, and a lapse is probably an oversight that might not be discovered for several months. Company makes a good-faith attempt to give customer plenty of time to discover the problem and re-subscribe, at which point all photos are renewed.
* $12.95 for 30 days, no automatic renewal. Excess photos are archived to cold storage, and discarded after 90 days unless the subscription is re-activated. Assumption: user is one-shot subscriber who intends to recover his lost pictures, and will never be seen again, so there's no need to retain them longer.
* $49.95/year, with retention policies that depend upon whether or not the customer agrees to auto-renewal. If the customer does NOT agree to auto-renew, excess photos are archived to cold storage and subject to deletion after 1 year of inactivity. If the customer DOES agree to auto-renew, excess photos are archived to cold storage and subject to deletion after 3 years of inactivity (though in reality, might be retained longer if the company later decides it makes economic sense)... if they renew within a year, restoration of archived photos is included with the subscription price. If they DON'T renew within a year, recovery of their archived photos will incur an additional long-term storage fee equal to the current annual subscription fee.
The additional long-term storage fee would be fair, because long-term cold storage -- while cheaper than online storage -- is nevertheless non-free, and the longer old photos sit in cold storage, the less likely anyone will ever care about them or pay to get them back. That said, once they're IN cold storage, the cost to store them for 3-5 years isn't much more than the cost to store them for 1 year, so a surcharge to get the REALLY old ones back would probably still be profitable.
The key here is to follow the principle of least surprise. Most people don't actively curate their possessions on a daily basis. If something like this goes away, it very well might take a couple of months for someone to even notice that it happened, and even longer to realize that they CAN do something about it and actually figure out what they have to do to make it happen.
In the case of legacy customers, they had no explicit reason to assume that their photos might disappear without warning. Anybody who's gotten burned by cloud providers in the past knows enough to never trust ANY cloud-based storage provider with their only copy of ANYTHING, but we'll show some empathy for less-technical people who genuinely had no idea where or how their photos were being stored and are genuinely caught by surprise. ESPECIALLY those who were automagically signed up for an account while setting up a new phone, and had no real understanding of what was really happening.
They could also offer a few additional services at higher cost for customers with annual subscriptions. For example, they could offer a $24.95 option where, if their card gets declined at auto-renewal time, the service would query the credit bureau to see whether the customer is dead (the customer would have obviously given consent for this at the time of ordering the service). If they're dead, one or more of several things could happen: a) one or more accounts held by other people could automatically gain access to the deceased user's photos; 2) At least one, and at most three, designated survivors would be notified
You're right IF you're viewing the code in the context of an IDE.
If you're viewing it as a fragment of printed source code limited to only the code in a single method, reading it offline, and you don't ALREADY intimately understand what the code is supposed to do and how it's doing it (or have a whiteboard full of UML diagrams to refer to simultaneously), Lambdas can be a BITCH to make sense of.
IMHO, a better & more readable syntax for Lambdas that preserved all the meta-information present in an anonymous class (but more concisely) would have been something like:
String[] names = directory.list(FilenameFilter->accept:boolean(File dir, String name) { name.endsWith("java") };
which would have concisely preserved the names of the interface and its method, as well as making its return type clear.
My favorite quote (made up by me, about 15 years ago) -- "Oracle isn't a database, it's a multi-level marketing scheme driven by an army of indentured vassals that somehow managed to make a really good database whose biggest disadvantage is Oracle itself."
Try doing anything that involves robotics. Or OpenGL ES. Or pretty much anything that involves I2C, reading sensors, or parsing binary data files (like NEXRAD radar sweeps).
After a few hours of having every. goddamn. math. operation. turn into shit like someValue = (byte)((someValue * 2)&0xff);, your brain just turns to jello & you start to forget things... do I have to do the 'and' THEN cast? Cast then 'and'? Do multiple 'ands' throughout the operation THEN cast? Eventually, it starts blurring, and you end up with stupid errors that the compiler won't catch, because the whole reason those stupid errors happened is because the compiler made you play stupid fucking games to try and outsmart it so it would ALLOW you to deal with 8-bit unsigned values.
Clarifying my lambda comment... When you're reading an anonymous class declaration, you know:
1. The name of the Interface the class is implementing
2. The name of the method being implemented.
3. The names of the arguments, in addition to their types.
With Java lambdas, #1 and #2 both end up getting stripped away.
Here's an example taken straight out of Ken Kousen's book, "Modern Java Recipes: Simple Solutions to Difficult Problems in Java 8 and 9"... chapter 1, pages 4-5:
The traditional, human-readable approach:
File directory = new File("./foo");
String[] names = directory.list(new FilenameFilter() {
@override
public boolean accept(File dir, String name) {
return name.endsWith(".java");
}
});
Reading it, we can immediately see that we're calling directory.list with something called a FilenameFilter(), which has a single method named "accept" and takes a File object called 'dir' and a String called 'name', then returns a boolean. It doesn't take a genius to figure out what it does, EVEN IF you've never used a FilenameFilter in your life and have no idea what it does. Between the interface name, the method name, the argument names, and the code inside itself, it's BLATANTLY obvious what it does.
Now, consider its Lambda equivalent:
File directory = new File("./foo");
String[] names = directory.list((dir,name) -> name.endsWith(".java"));
OK, we're calling directory.list and... er... um... WTF?!?
Yeah, this is a somewhat trivial example that most people could figure out, but now imagine that you're using Lambdas with a more obscure interface that the person reading the source ISN'T already intimately familiar with. Or, god forbid, calling a lambda with lambdas as arguments, then chaining it to another lambda (yes, I've seen those). God fucking HELP you if you have to try and untangle a mess like that by hand with nothing but printed sourcecode and Google to help you. It entails something like this:
1. Figure out what kind of object 'directory' is. Remember, in a real program, it won't necessarily be declared one line away. If you're lucky, it's either declared within a screen or two of where it's used... or near the first few screens of source near the top. Unless, of course, it's a static class that's defined within another class definition, in which case it might be somewhere around line 2400.
2. Figure out what kind of objects 'dir' and 'name' are. Once again, remember... real life won't always be as trivial as this example. Happy hunting!
3. Humor me, and pretend that File is a class in some thirdparty library you've never heard of, and you now have to find its javadocs & figure out what kind of arguments File.list expects. Remember, parametric polymorphism. And inheritance, since there might be additional variants declared in the superclass.
4. OK, so, eventually, you figure out that File.list has a variant that takes a FilenameFilter object. Go look up FilenameFilter, and pray to every deity you can think of that you'll find an interface that has a single method that takes a F
Emotionally, Java died for me the day I discovered that C# has real, honest to god unsigned bytes. You have to be masochistic beyond words and the world's ULTIMATE glutton for punishment to attempt programming OpenGL ES using Java, because GLES does EVERYTHING by juggling around byte arrays, and dealing with raw unsigned bytes in Java is pure misery.
It's no secret that 'unsigned bytes' are one of (if not THE) most-requested features in the history of Java. And the one that evokes the angriest ideological debates, often getting it called 'syntactic sugar' (as if providing a language construct to avoid having to do things known to create STAGGERING numbers of insidious code errors due to typos is a morally-decadent thing).
Personally, I love how some people get all righteous about calling unsigned bytes 'syntactic sugar', then proceed to defend dumping six pounds of 'syntactic salt' into Java in the form of the way Java now handles lambda expressions.
Lambda expressions per se aren't necessarily a bad thing. Pretty much every major language now has them. But the specific WAY they were implemented in Java is an abomination. Put bluntly, they're basically "human-compiled" object code PRETENDING TO BE actual source code.
For anyone who doesn't understand what I just said, here's an alternate explanation. Basically, when the Java compiler sees a Lambda expression, it recursively searches through the list of interfaces known to it until it finds an interface that defines a single method whose arguments match the types of those used by the lambda. It takes the compiler (or IDE) a fraction of a second to do a brute-force search through the API to find a match. Humans, unfortunately, aren't quite so agile at things like that, which is why we invented source code in the first place 50 years ago.
Behind the scenes, the compiler is just automatically assembling an anonymous class that implements the interface. And if you had the sourcecode TO that anonymous class in front of you, making sense of it would be easy. The problem is, Java's lambda syntax strips away most of the contextual information that the anonymous class would provide you with, so you're left trying to make sense of a cryptic glob of punctuation characters that makes obfuscated Perl look like Ada or Visual Basic by comparison.
The end result is that if I write a nontrivial program using Java lambda expressions, print out a method, and hand it to you, there's a VERY high likelihood that you'll scratch your head and be completely unable to make sense out of it without at least looking back at the includes near the top, and probably a few minutes with Google. In contrast, if those lambdas had been printed in the source AS anonymous classes implementing the same interface, you'd probably be able to effortlessly make sense of them without a second thought. And that's what's fundamentally wrong with Java Lambda Expressions, in a nutshell. They optimize the wrong problem, and result in sourcecode that's human-unreadable.
One thing to keep in mind when looking at the spectacular new "Geocolor" imagery from NOAA's latest satellites -- it's far less "real" than it appears to be at casual first glance.
The cloud imagery is real & better than anything we've ever had, but contrary to appearances, GOES-17 is NOT a full-color webcam in space. The beautiful blue oceans, lush green terrain, brown deserts, majestic white snow-capped mountains, and glowing city street lights are all computer-generated images with the cloud data overlaid on top. The daylight visible-light cloud imagery is the same 4-bit 1km-resolution greyscale we got from the previous satellites... they're just doing more post-processing now to make it a lot prettier.
Don't get me wrong... the new satellites are a HUGE improvement with respect to their science value and their OTHER sensors. I'm just pointing out that their daytime visible-light imagery isn't nearly the eye-popping improvement it appears to be at first glance.
The REAL absurdity is that today, in 2019, content produced in the US or Canada STILL ends up with different owners of the licensing rights in both countries.
I mean, seriously. I can understand the problem of legacy stuff that was created years ago, back when things like making moving prints, physically transporting them from theater to theater around the country, and promoting them locally was a big deal, but Jesus Fucking Christ on Rollerblades... pretty much ANY English-language TV show or movie that gets produced today and released in one country is practically guaranteed to end up in the other country within a year.
Technically, the media market between the US and Canada is about as frictionless as two media markets can possibly GET. We both use the same TV standard, have the same TV framerates, watch the same TV shows and movies, and listen to the same music.
Before someone brings up Quebec, I'd argue that French-speaking Canadians endure even WORSE grief due to the silliness of US-Canadian licensing complexity. Consider, for example, the tens or hundreds of thousands of French Canadians who live in Florida and New York & have to jump through silly hoops to watch French-Canadian TV shows that haven't yet been officially licensed yet for distribution in the US. Also, there's no need to "protect" French-language shows... French is a major worldwide language with a HUGE international export market, and Canada has become a worldwide film and TV powerhouse precisely BECAUSE most Canadian actors & actresses are now bilingual. In Canada, you can produce a film or movie that shoots close-up speaking scenes twice (once in English, once in French, same actors for both), use the same actors to dub THEMSELVES for the remainder of the scenes, and cost-effectively produce content with "native" production values in BOTH languages.
Incidentally, the "shoot twice... once in English, once in another language" strategy is something that was uncommon in the past, but has become popular in recent years thanks to both cheaper digital editing workflows and multilingual actors. The Norwegian+Netflix TV show "Norsemen" is a perfect example of it -- https://www.youtube.com/watch?... ).
And I'm NOT arguing that the licensing barriers between other countries make much more sense... I'm just pointing out the utter and complete absurdity of the present state of licensing affairs between two countries whose media markets have about as close to 100% overlap as you can get. Of all the things NAFTA has dropped the ball on over the years, this is probably the most galling example of something that SHOULD today be completely frictionless and transparent.
It wouldn't even take much beyond a treaty between the US and Canada & the necessary enabling legislation to declare that henceforth, after some future date, all newly-created (or newly-licensed within the US-Canada market) content licensed for distribution in one country is automatically licensed for distribution in both, and that no contractual language limiting the rights of a licensee to do that will be enforced.
At first, there would be too much legacy content with split rights ownership for much to change... but eventually, there would be enough content with unified licensing that some new service would launch that didn't bother to distinguish between US and Canadian customers, and as a result would only license content AVAILABLE under unified licensing. The aftermath would be a flurry of companies who owned country-specific rights bartering, trading, selling, and buying those country-specific rights to consolidate their ownership and increase the content's value by making IT eligible for licensing to that country-agnostic service.
Eventually, there would be enough licensing-consolidation, even of legacy content, for services like Netflix and Comcast to decide that it simply wasn't worth bothering anymore with content that demanded geographic restrictions, which would render content that COULDN'T be licensed under unified terms almost without commercial value until someone DID manage to buy up and aggregate the distribution rights.
Actually, there's a bigger problem... AFAIK, when an ad agency licenses the rights to use a copyrighted song in a commercial, they pay a lower rate if it's only going to be shown in a regional TV market instead of nationwide. If an advertiser knowingly ran the ad (after paying 'regional' rates) on an affiliate who was known to make it readily available to viewers nationwide, the advertiser itself could be sued by the music's copyright holder.
That's why local affiliates who rebroadcast to viewers out of area usually/always black out the local ads entirely on their uplink feed.
Another possible explanation: fluoride prevents tooth decay that, in the past, would have left someone mostly toothless by middle age. If you have no teeth, gingivitis probably isn't a major problem. If you have all of your teeth, but minimal dental care (beyond fluoridation during childhood), gingivitis is likely to be a major problem later in life. Fluoride didn't cause the gingivitis, it just fixed enough BIGGER problems for gingivitis itself to become a big problem.
JWST isn't a true "replacement" for Hubble.
Tthere are a few things JWST can do that Hubble can't, but there are a LOT of things Hubble can do that JWST can't. It's more of a step sideways than a step forward.
As an augment to Hubble, it has the potential to be a fantastic resources. As an outright replacement, it kind of sucks.
Making matters worse, JWST's expected service life is shockingly short, and unlike Hubble, NASA appears to really *mean* it when it says it plans to deorbit JWST on schedule (to avoid leaving spacejunk cluttering a Lagrange point). So it's ENTIRELY conceivable that if Hubble gets deorbited with JWST as an alleged "replacement", we'll end up with no comparable space telescopes AT ALL a couple of years later.
The best thing we can do with Hubble right now is to get maximum use from it, then do our best to keep it cheaply re-boosted until such time as we have the ability to do a proper servicing mission on it (replacing its electronics and mechanically-failing parts, but taking advantage of the huge spaceframe and lens that we realistically have no way to replace anytime within the next 15-25 years).
For somewhat of an analogy, imagine that your family runs a tour service on a remote island in the middle of the Pacific Ocean & has a big, London-style double-decker bus that's iconic and wildly popular with tourists. Your grandfather bought it 30 years ago when it was shiny & new, and had it transported to the island in a semi-custom airplane that no longer exists (assume that for some reason, boats can't reach the island... maybe it's surrounded by jagged reefs that would be suicidal to attempt navigating by boat). Today, that old bus is kind of a hot mess... it needs a new engine, the seats are tattered, and it needs a good paint job. A brand new bus would cost less than refurbishing the old one, except for one problem... there's nobody who's CAPABLE of transporting an entire new bus to your island because it's too big to fit into any of today's smaller, cheaper, safer, and more fuel-efficient (but sadly, smaller) cargo planes, so you have to make do with packing replacement parts onto multiple air cargo planes and flying them in if you want to continue having a working double-decker bus on that island.
It's not a perfect analogy, but it makes the point... Hubble has parts that simply CAN'T be replaced anytime soon. If we throw them away by deorbiting it, the capabilities they represent will be gone "forever" (at least, the foreseeable future, quite probably the remainder of our own lives). A limited robotic servicing mission by SpaceX that does nothing but boost Hubble into a higher orbit to buy us another 10-15 years to decide what to do with it would be an extremely prudent investment, because the alternative would be the destruction of a valuable asset that literally can't be replaced at any cost within the next few years.
With the CPU governor disabled (so the timing doesn't screw up the stroke-recognition), I can reliably sustain 30-35wpm via Graffiti (prediction disabled). Beat THAT with ANY soft keyboard without using predictive test^h^hxt. Or even WITH predictive text, as long as you use it to write grammatically-complete sentences with correct capitalization & punctuation.
I suppose most people aren't bothered by quaint antiquities like grammar, capitalization, and punctuation, but I personally find my text entry speed falls to 5-6wpm with prediction enabled, because it feels like I have to keep going back and fixing every 2-3 words because something was incorrect.
And how is that any different from once-proud Harlem brownstones getting subdivided into a half-dozen apartments by the mid 20th century, before the area finally (re-)gentrified and they started turning back into single family homes again (or at least, one family per floor or two, vs one family per former ROOM)?
Old small postwar homes still exist... but the NICE ones are now inhabited by one or two people, not extended families with 4 kids and a grandparent or two.
I'd personally say the nadir of South Florida construction quality was the pre-Andrew 1980s. Pretty much every 1980s-era bathroom in Florida is a biohazard under the wall tile (vapor barriers weren't required, Hardiebacker didn't exist, and it somehow wasn't illegal to use normal drywall (not even the inadequate green kind) around a tub & attach tile using mold-feeding mastic.
Dijkstra was ahead of his time, mostly because he was preaching about concerns that were mostly anal-retentive academic non-issues on the computers computer science majors in the 80s and 90s were familiar with.
On a computer like the Commodore 64, or even an Amiga 500, a program that hijacks the interrupts and takes control is lord and god of its environment. "Works for me" IS good enough, because there aren't many ways it MIGHT work differently on anybody else's identical hardware.
When you fast forward to computers where SMP is the norm, weak memory models are common, and concurrent programming is required... Dijkstra was downright visionary and totally right.
Simply put, you can get away with a lot of shit on a computer where your code is the only thing running and the hardware is mostly identical to everyone else's that you CAN NOT get away with in a multithreaded program that attempts to use a GPU to do realtime calculations in a preemptively-multitasking operating system on a platform with a weak memory model.
Put another way... stuff like this seemingly-innocent Java example generally works fine on a PC with a single-core CPU running Windows 9x (despite having always been officially taboo), but REALLY goes down in flames if you leave it as-is, but run it on a computer with a dual/quad-core CPU, because there's no guarantee that a second thread won't arrive, see that myFoo is no longer null & return and attempt to use it before the first thread finishes CREATING the new Foo object: (google: "double-checked locking")
public static Foo getFoo() {
if (myFoo == null) {
myFoo = new Foo();
}
return myFoo;
}
Yes. Back when I was in college, I would have literally KILLED for the kind of computer, phone, and wireless 24/7/365 connectivity I now take for granted & have anxiety attacks without. And I say that as someone who HAD a 1200-baud modem in 1986, and spent the summer after 10th grade staying up all night using PC-Pursuit to connect to bulletin board systems around the world for free at a point in time when a long-distance call to a BBS a hundred miles away cost approximately $15-20/hour, and even fsck'ing QuantumLink cost around $2.50/hour.
The past 10-15 years have been kind of a disappointment in the PC realm, but even circa 2002 when I was playing with my shiny new PalmOS phone, I wouldn't have dared to fantasize about being able to use a service like Youtube as a free music streaming service (ignoring the videos) while driving across the Florida Everglades, let alone play 3D videogames and use it as a 2160x1440 display host for virtual reality software. On the other hand, if you'd told me in 2001 that circa 2010, the display market would be totally stagnated around 1920x1080 monitors and it would take literally YEARS to get back up above the kind of resolution available on a $4,000 2002-era Thinkpad (1920x1600), I would have thought you were kidding.
Ditto, for storage. If you'd told me in 1990 that someday, a MOUSE DRIVER would have approximately 200 megabytes worth of files... and that I wouldn't care, because my computer had a 2-terabyte hard drive, a 1-terabyte removable hard drive in the optical bay, and another 512gb that was like a persistent ramdisk performance-wise, I would have thought you were utterly and completely insane.
CPU-wise, I'd have to say yes and no. In 1988, a 1-GHz 2002 CPU would have seemed like science fiction. In 2002, a 4GHz CPU would have seemed like a sick joke, even when you account for cores, cache, and overall performance.
In terms of keyboards, computers have totally gone to shit. Even Thinkpad keyboards suck compared to the keyboards they USED to have 20 years ago, and suck even MORE compared to the literal low-profile clicky keyboards early-90s high-end laptops used to have. Modern mice are a billion times better than the mice we had in 1990, but I'd take a thumb trackball (with modern optical sensor instead of rollers) over a flat touchpad any day, unhesitatingly. I LIKED thumb trackballs like the one on the DEC HiNote Ultra, and didn't mind first-generation touchpads that emulated thumb trackballs. I absolutely DESPISE modern touchpads (which are designed for people who can't type, and who use them with their index fingers, as opposed to people who keep their hands over the keyboard and try using the touchpad with their thumb).
I miss resistive touchscreens. Capacitive touchscreens are handy for detecting blunt touches, but resistive touchscreens with real DSPs were a thousand times better for things like Graffiti. To this day, I have yet to use a non-rooted Android phone whose CPU governor isn't disabled that's capable of doing Graffiti as accurately as a 16MHz Palm Pilot III.
IMHO, the industry abandoned IrDA long before it had a good replacement... and waited WAY too long to replace 1.44mb floppies with just about anything that was better (Zip drives and LS-120 were too little, too late... but LS-120 would have totally rocked back in 1992, even if they'd only been 25-50mb/disk).
Space exploration? Meh... and yeah. Elementary-school me (late 70s, pre-shuttle) would have been thoroughly unimpressed by today's space program. The entire shuttle era just seemed lame and anticlimactic. My first sentient thoughts regarding space travel involved watching men walking on the moon... and thinking it was a totally normal daily occurrence (because for someone who was born after the first Apollo mission, but was old enough TO remember seeing the final ones live on TV, it WAS a totally normal daily occurrence)... and it seemed like everything NASA did after I finally got to kindergarten was just a step down.
On the other hand, the past
As someone who generally sucks at keeping receipts, and who usually finishes up a home improvement project with several hundred dollars worth of stuff that was bought 15 minutes before closing time (just to make sure I'd have everything I needed to finish some project after the store closed, but before going to bed) or purchased for the sake of having enough extra to avoid having to make 3 trips per day to buy one more {whatever} after the last one was [fucked up | dropped into a hole | not quite enough to finish the job], I'd say being able to make returns without needing a receipt is a pretty HUGE benefit for consumers.
It's minuscule as a percentage of their operating cost, but it's a HUGE amount of money in absolute terms. And mega corporations have a completely different set of priorities than small businesses. A large corporation will replace 75,000 24 month old laptops because their warranties expired and not think twice. A small business might have 5 laptops, each and every one of which is a different make & model. A mega corporation manages its computers remotely, using scripts and expensive utilities and management servers. A small business gets the owner's 17 year old son or daughter to reinstall Windows when somebody's laptop gets malware on it.
There's a HUGE market for POS software for small businesses. And small businesses that DON'T use POS software (like my auto mechanic) use Square with an iPad or Android device.
Small businesses are usually on the bleeding edge of technology, precisely BECAUSE running a small business requires that the owner wear multiple hats, be at least vaguely computer-literate if they want to function in the modern economy, and because there's no CIO and board of directors to either say "No" or demand a detailed 537-page strategy plan with multiple appendices comprehensively documenting its compliance with corporate governance standards, regulatory requirements, and everything else that's expected by large companies.
The days of someone running a computer-free viable small business are rapidly coming to an end, mostly because the few who insist upon doing it are all approaching retirement age or death by now. Computers and small businesses aren't some new "Millennial" thing... small businesses have been using computers since the days of the Commodore 64 and Apple II (if not for POS, then for bookkeeping, scheduling, inventory-management, and supply ordering). Who do you think drove the MARKET for business software back in the 8-bit era? It sure as HELL wasn't large corporations like Sears... THEY had their expensive mainframes from IBM (which they didn't bother to start replacing until the 21st century, which is probably part of the reason why they're in the trouble they are now).
It was small businesses who jumped on 8-bit computers, precisely because they WERE affordable, useful, and didn't require a priesthood of snotty gatekeepers to administer and manage. Computers and small businesses didn't start to become universal until well into the PC-era, but if you went back in time to 1989 and walked around an average strip mall, you would have found at least one computer in at LEAST half the small businesses at that strip mall... starting with the beauty salons and video rental stores (just to name two categories of small-business retail that ENTHUSIASTICALLY embraced computers almost from day one of the microcomputer era).
Mom and Pop stores are the LEAST of the problem. In Miami, at least, "Mom and Pop" neighborhood stores were using computers with cash register software and digital signature capture for credit card purchases YEARS before big companies like Walmart, Publix, and Blockbuster were.
Why? A big company like Walmart, Publix, and Blockbuster has to make large-scale IT decisions that are nationwide in scope, require months of research and bureaucracy, and take lots of time to deploy. A small business owner says "fuck it", he's making one decision for himself, and if spending an extra $250 or so means he won't have to screw with paper receipts anymore when the credit card company does a chargeback on him, he'll spend it in an instant because it makes his life immeasurably easier. It's a lot easier for ten thousand small businesses to make ten thousand individually small decisions than it is for one very large company to make a very big decision that affects ten thousand locations.
This isn't rocket science... if you purchase with a credit card, Home Depot ALREADY DOES this.
If you want to return things:
* Give the items you want to return to the clerk.
* Clerk scans the items, and gives back all the stuff you bought at Lowes and forgot where it came from.
* You swipe all the credit cards you might have used to purchase the returned items.
* Home Depot uses the card data to look for receipts associating a purchase of one or more returned items using that card, and automatically credits the price back to the card.
* For everything else, you provide your ID, and they give you a store credit (the ID is needed to limit the ability to brazenly shoplift items and return them later... if you start returning TOO MANY big-ticket items without a receipt, they'll restrict your ability to get receipt-free refunds of cash purchases in the future.
> California can't even build a train across a flat valley for $25 billion.
The expensive part isn't the flat valley. The EXPENSIVE part is the bored tunnels to get the trains to and from the big cities on the OTHER SIDE of the mountains surrounding that flat valley, and the first and last hundred miles or so of track at both ends. Most of Phase I's cost is actually for the hundred miles or so of track between San Jose and the Modesto area that will be used by CalHSR, but ALSO used for high-speed commuter rail (so people who work in the Bay Area will be able to live in more affordable areas and still have a semi-sane commute).
The fundamental problem with AI in a HR context is that there are well-established laws protecting employees from certain forms of discrimination. No publicly-traded corporation's management would DARE to officially suggest, let alone demand, that its HR staff systematically discriminate against applicants based upon their sex, religion, national origin, etc. in ways that violate against laws, because it would be an open invitation to fines and lawsuits when the policy was inevitably disclosed by a disgruntled former employee.
The problem is, AI-logic (especially deep learning and pattern recognition) tends to be EXTREMELY opaque and impossible for humans to make sense of. That's WHY someone used deep learning in the first place... it's great at spotting patterns that look like random noise to humans. The catch is, if you can't explain the logic, you ALSO can't guarantee that it's not indirectly basing its logic on criteria that are ILLEGAL to consider in the first place.
If you're not at home when somebody rings the doorbell, will you get the notification and be able to launch the viewer app on your phone in time to see who rang the bell before they're in their car backing out of your driveway?
It's not entirely Ring's fault (Google kind of pulled the rug out from under them with regard to push notification timing post-Marshmallow), but the real-world massive time lag was probably the biggest disappointment when I got mine 2 years ago. From my own experience, if you aren't at home & connected to the same wifi network as the doorbell the moment someone presses the button, you'll be lucky if your phone plays the "doorbell" notification within 20-30 seconds. Add another 10-20 seconds to unlock your phone and launch Ring's viewer app, and your likelihood of getting a chance to even SAY anything to whomever rang the doorbell before they're already gone is pretty low.
Even if you're at home & connected to the same wifi network as the doorbell, you almost have to have the phone in your hands & already unlocked to have any chance of getting the "Ring" app launched before whomever rang the doorbell turns around and walks away.