Just to add another example of how 5G could offer improved location service...
GPS works by having a constellation of satellites with very accurate clocks onboard that periodically broadcast a timestamped beacon. At the receiving end, you note the (local) time the beacon was heard.
Then, you look up the coordinates, motion vector, and timestamp of the satellite's last ephemera update, then calculate where it OUGHT to be as of the instant specified in the timestamp... and repeat for all the satellites in view. Because satellite orbits drift over time, the ephemera data has to be updated periodically (ironically, I think the GPS satellites determine THEIR OWN locations by triangulation from similar beacons at precisely-known locations on earth).
Once you know where each satellite was located at the instant of their timestamp, you can derive your own location (by comparing your own clock's timestamps on each beacon datagram with those from the satellite, based on the speed of light & known signal-propagation characteristics).
You might see a catch-22... your phone's clock isn't as accurate as the clocks in the GPS satellites, and there's always going to be a degree of uncertainty if you have to set it BASED UPON a consensus of GPS satellites & local towers. HOWEVER, if a tower's physical location is precisely determined by surveyors, its clock-setting logic can use that information to derive a more precise time from GPS satellites (basically, adjusting its own clock until the locations derived from GPS match the location determined by the surveyor). And phones can precisely set their own clocks, because the speed of light over a mile or so is practically instantaneous compared to the distance to a GPS satellite.
The main limit with 5G is the stability of the antenna & support structure itself. I think one difference between 4g and 5g is that 5g ALSO reports its predicted margin of error & confidence, and might do additional tower-site logic to take things like tower-sway into account. Because otherwise, you might calculate a location that claims to be within 33mm, but could vary by 12 feet due to the antenna being mounted on a tower that's swaying by 12 feet at the tip. When you start trying to get THAT kind of precision, uncertainty about the location of the antenna ITSELF becomes a big deal.
Conceivably, a 5G tower that wanted to be extraordinarily accurate as a location source could use additional sensors to measure that moment-to-moment deviation. Not just accelerometer & gyro, but also cameras observing it from different angles, anemometers coupled with the tower's known flexure at a given temperature & wind speed, etc... and providing a way to obtain (via side-channel) the additional raw sensor data, so clients won't have to be limited by the software running at the tower site itself. Someone (like a researcher) COULD actually grab the "raw" data, and do his own calculations with it. Basically, the goal with 5G was to avoid imposing arbitrary limits. You can get precise location data now, but you could potentially get MORE precise data in the future as the sensors & certifications of the site improve, better algorithms are discovered, etc.
Remember... EVERY measurement ALWAYS has some degree of uncertainty... and some sensors are a lot more "uncertain" than others. You can take advantage of known parameters (like location surveyed with high precision), but ultimately EVERYTHING is at least slightly wrong. For a perfect example, think back to analog paddle controllers back in the "Atari" era. Even with low-res displays, you had at least a few pixels of frame-to-frame jitter. No sensor EVER gives you a 100% accurate instantaneous reading. It's just how sensors ARE. You can improve accuracy by oversampling & integrating readings from multiple sensors, but ultimately... every reading is STILL an educated guess.
2G specifically would have severe scalability problems. AFAIK, each 2G data link is basically a circuit-switched voice call that skips the modem part and goes straight to the bitstream. In landline terms... kind of like ISDN. The point is, if a given tower is provisioned to handle ~24 simultaneous voice calls, each 2G data connection eats up one of those slots for its duration.
So... 2G might work if the collars connected only infrequently, for a few seconds, and had the ability to wait random delays before attempting the next connection... but even a single herd with a few thousand cattle attempting to "phone home" daily would probably have a noticeable impact on at least a single tower's capacity.
3G could handle daily uploads without breaking a sweat, but would run into problems if collars tried to treat it like an "always on" connection. AFAIK, no single tower in a 3g network can handle more than a single subnet, and IP leases are (usually) for an hour, so after the first {n} radios connect and establish a session, nothing else can connect until users from the first {n} go away and stay away for the remaining duration of their lease.
I'm not sure how much of 3G's limit is hard-baked in to the standard itself, vs the de-facto limits imposed by off the shelf hardware, software, and configurations used by carriers out of habit, but I know 3G doesn't deal well with situations that involve HUGE numbers of transient users over a short window of time... the crowd blows through the tower site's DHCP pool, and for a while nobody else can connect at all.
I think 3G's max tower-users-per-time-interval can be tweaked upwards (by allocating more IP addresses per tower, reducing DHCP lease times, etc), but the point is that an "average" 3g tower with typical urban-suburban configuration would probably have issues if a farmer suddenly lit up tens of thousands of 3G radio collars over the span of a few days without at least coordinating it with the cellular network (to give it a few months to re-provision the affected tower site with a more appropriate configuration).
The point is, it goes beyond merely "total bits per second". There are also limits on the total number of user sessions per time-interval, and those limits can become significant if an area suddenly experiences an unanticipated surge in total connections, even if they aren't transmitting more than a few bytes of payload data apiece.
4G mainly gives enough headroom to make "lots of ephemeral connections from lots of users within a short interval of time" less of a problem. It HAD to, because the rapid emergence of Android & Iphone (all continuously making network requests in the background) pushed existing 3G networks to the breaking point. A 3G tower next to a 14-lane freeway that might have once served a few thousand users who "went online" deliberately suddenly had tens of thousands of users per hour driving by & establishing data sessions so they could ping Facebook or Twitter in the background. 4G had other benefits, but the increase in the default connection limit per tower site between middle-stage 3G and early 4G was a big one. It's also why it's legit to call HSPA "4G"... a tower configured for HSPA can basically handle as many connections per hour as a LTE tower of the same era, and WAY more than the same tower could back when it first went online in early-3G UMTS form. It's not as efficient as LTE, but most of the hard limits users associate with "3G" are gone.
Ditto, for 4G vs 5G. If you only care about ping times & speedtest benchmarks, a pimped-out LTE tower with lots of low AND high-frequency spectrum doesn't look all that different to end users than a "5G" tower with the same spectrum and users. 5G's benefits are mostly in the "efficiency" realm, plus features like enhanced location-positioning (basically, every 5G tower broadcasts a periodic beacon with GPS-like timestamp that can be combined with a database of known tower locations and acts like a terrestrial GPS satellite). I'm pretty sure 4G d
I think the main thing we're disagreeing about is where SpaceX is likely to launch most of the BFR rockets. I think SpaceX originally explored multiple options (including the floating platform), but decided towards the end of last year to use 39A for most BFR launches once it's officially in production.
FEC is heavily used, but it's double-track in the area.
I'm not 100% sure that it's fully double-track all the way from Jacksonville to Miami, but I'm 99% confident that if it's not... it WILL be within the next 2-3 years.
Virgin/Brightline hasn't (AFAIK) OFFICIALLY announced future expansion to Jacksonville yet, but pretty much everyone takes for granted that it's going to happen, and the only real question is when it will happen compared to the launch of Miami-Orlando and its extension to Tampa. As a practical matter, the only thing Virgin/Brightline really NEEDS to do to add Jacksonville as a destination is build stations in Jacksonville (and probably Daytona, somewhere in Brevard county, and possibly somewhere around Vero Beach), buy more trainsets, and upgrade the crossings & signals to allow 110mph operation... not a trivial expense, but pretty cheap compared to what they're spending to build brand new tracks from Cocoa to Orlando.
My personal prediction is that once Virgin/Brightline is running to Orlando, Tampa, and Jacksonville, Amtrak will revise their long-distance trains in Florida to split them in Jacksonville & send half down FEC to Miami, and the other half along their current route to Orlando & Tampa (and if they're smart, continue them beyond Tampa to a new station next to Sarasota Airport since they'd no long HAVE to continue from Tampa to Miami). They might even have a code-sharing agreement with Virgin/Brightline to allow Miami-bound passengers from New York to ride in the "Tampa" end to Jacksonville, then transfer to Virgin/Brightline for the final leg (or Tampa-bound to ride in the "Miami" end) if the half of the train going to their desired destination sells out.
To make up for the loss of Amtrak service to Winter Haven and Sebring, Sunrail could "sort of" extend its service all the way down to Sebring... still ending MOST trains at Poinciana, but extending 3 or 4 per day all the way down to Sebring. One would be a normal Sunrail train that simply overnighted in Sebring & began its run in Sebring at a time that had it running through downtown Orlando around 8:30am. Another would be a normal southbound Sunrail train that passed through downtown Orlando around 6:15-6:30pm and continued all the way to Sebring. A second would be timed to allow someone in Sebring to arrive in downtown Orlando around 7:30pm, and depart southbound around 10 or 11pm. The third and fourth would only serve stations south of downtown and be timed to provide guaranteed connections to Amtrak's trains via Kissimmee Station. It would be a little less convenient for long-distance travelers, but IMMENSELY more useful for people who LIVE in Sebring and Winter Haven (by allowing them to take the train to work in downtown Orlando, to attend evening events in downtown Orlando including Orlando Magic games, and allow elderly residents (who live there in ABUNDANCE) to easily take the train to visit doctors in downtown Orlando, or connect to Brightline (via the airport station) for travel to Miami, Tampa, or Jacksonville.
Even if SpaceX decides to do BFR launches from the sea, I'll be shocked if the majority of their other launches don't use Cape Canaveral. It just doesn't make economic sense to do sea launches when you have a perfectly good launch site on dry land that can easily be reached, absent some really urgent, compelling safety reason to do the launch offshore. At sea, literally EVERYTHING becomes an expensive exercise in logistics... employees, supplies, EVERYTHING. Sure, they might do it if they're testing a new design that has a nontrivial chance of blowing up... but for routine launches, it would be senseless. Especially since they already have a lease on pads 39a and 40, and have spent HUGE amounts of money on fixed ground infrastructure there.
KSC's visitor operations are run by a company that has little to do with launch operations. NASA tells them what they're allowed to do on launch day & reviews their plans, but has very little to do with the direct handling of those launch-day crowds.
Over time, the service would presumably evolve to accommodate different crowds for different launches. For example:
* Routine launch, one of 4-6 SpaceX launches taking place that week: Single train operated by Sunrail under contract. Departs from DisneyCelebration station, stops at MCO, stops at the future Brevard County Virgin/Brightline station, and ends at the Banana Creek viewing area station. Arrives 30 minutes before launch, departs 10 minutes after the last booster landing visible from KSC.
* Noteworthy launch likely to generate a significantly larger crowd: two charter Virgin/Brightline trains (Miami-FLL-WPB-KSC, Tampa-Lakeland-Disney-MCO-KSC). Train leased for event from Sunrail runs Disney-MCO-Brevard-KSC in the morning (to position the train, and provide an easy way for tourists in Orlando to visit KSC for the day), then runs back and forth between KSC and the Brevard station with at least two inbound trips before the launch, and two after the launch. Depending on how many people are projected to ride and the time of day, the second train could then continue directly home to Orlando, or it could return to KSC and head home a half hour after NASA closes to visitors for the day.
* Launch likely to generate an even bigger crowd: Possibly add another chartered Virgin/Brightline train from Jacksonville, with additional shuttle trains rented from Sunrail and Tri-Rail running between the Brevard station and KSC station during the 2-3 hours before launch & afterwards. Sunrail trains coming from Orlando go directly to KSC, since Brevard-KSC trips are being adequately handled by the shuttle train(s).
Then, there's the BIG event... the future Mars launch. The equivalent of NYE 1999 in Times Square, South Beach, and New Orleans combined... plus Burning Man, Coachella, and Woodstock '69 thrown on top. Launch-day crowd likely to be in the TENS of millions by the time you count everyone within 50 miles who doesn't live in Florida, or live within 50 miles of Titusville.
** Pretty much every railcar in Virgin/Brightline's fleet will be running between Tampa & KSC, Miami & KSC, and Jacksonville & KSC, with regular daily service around Florida suspended (but arranged so that someone traveling Miami-Orlando/Tampa could get off the train in Brevard, and transfter to a train heading back to Tampa after dropping off its passengers at KSC).
** Amtrak suspends regular service for 2-3 days before and after the launch. Amtrak aggregates its sleeper cars & dining cars into rolling hotel trains that get parked on the spur adjacent to the northern end of the shuttle runway and become the largest adhoc rail-hotel in the history of the world after running from various cities to KSC (to cheaply make room to park basically Amtrak's entire fleet of sleeper cars, they cut a pair of shallow trenches in the road that continues beyond the tracks' end to the north end of the runway & drop in steel rails... you wouldn't want to RUN trains on rails like that, but they'd be good enough to park the trains on for a day or two).
** Meanwhile, Amtrak's entire fleet of coach cars gets temporarily re-deployed to do runs between Jacksonville and Miami for 12-24 hours before and after launch. These trains don't go to KSC itself... not even trains can get THAT many people into KSC. Instead, their goal is to prevent several million cars from turning every road within 25 miles of Brevard County, including 528, I-4, the Turnpike, and I-95, into a multi-day parking lot. They stop at Virgin/Brightline's stations, as well as a half-dozen adhoc stations built for the event within walking distance of the causeways leading to NASA, or other spots further off that are adjacent to vast amounts of parking. The causeways themselves are basically clos
The last thing the US wants to do is "take out" Russia's economy, because then we'd have to worry about dealing with an impoverished, destabilized country that owns a large arsenal of nuclear weapons with substantial resale value. It's in our best interest for Russia to be affluent, happy, and feel secure. Politics isn't a football game.
The US is enormously safer and better off when Russia is a stable, wealthy, happy partner to do research and business with. It's fine for the US and Russia to be adversarial, as long as you recognize that an "adversary" isn't necessarily an "enemy". Sometimes, it's good to have a little bit of healthy adversity between worthy opponents... it keeps everyone honest & avoids stagnation. But you don't want it to turn into silly cheerleading and enmity, because that just leaves EVERYONE worse off.
And the fact is, by the time SpaceX really starts to eat into Russia's market share, they'll be following the same path towards reusability and lower cost as SpaceX. Remember, half the battle in inventing something is knowing it's possible. Now they know.
The fact is, Russia's space program isn't going away, even IF it becomes unable to compete with SpaceX on cost, because manned spaceflight is as important to Russia's national pride and sense of identity as it is to America's. If SpaceX undercuts Russia, Russia will follow in SpaceX's footprints, duplicate its success, and will hemorrhage as much money as necessary in the meantime to keep up appearances. Because the alternative is inconceivable to Russians.
Americans were traumatized when the shuttle program ended with no replacement in sight, but we could at least take a small bit of comfort knowing that it wasn't the first time we were temporarily out of the game. The same thing happened in the 1970s... Apollo ended, Skylab crashed, and the Shuttle just kept getting delayed and delayed. Then there was the lapse after the Challenger explosion. And another lapse after Columbia's accident. In contrast, most Russians have NEVER known a world where they didn't have the ability to send men into space. Even when the Soviet Union was disintegrating and Russia was on the brink of civil war, Mir was still occupied. And by the time Mir was deorbited, the ISS was already under construction (and might, in fact, have already had the Russian module in place, though I don't think it was ready for continuous habitation at that point).
Kennedy Space Center desperately needs to improve their spectator logistics. The biggest single thing limiting the number of people who can watch launches "up close" isn't crowd capacity, it's limited parking and road capacity into KSC.
KSC should try to make a deal with FEC Railroad, Brightline, Tri-Rail, and Titusville Mall:
Titusville Mall is practically dead, has a huge parking lot, and sits a short block away from FEC's tracks. I'm sure its owners would be absolutely thrilled to have an excuse to collect $10/car to park there on launch days.
FEC owns the tracks leading to the spur that goes to KSC itself.
They could lease the vacant lot at/near 3547 S. Hopkins Avenue (south of the Shell Station at Country Club Drive) so they'd have a place for people waiting for the train to stand. To save money, they could build a wood platform (with stairs and a single wheelchair ramp) wide enough to span between two Tri-Rail bi-level cars, and stick additional wood stairs on concrete pads for access to two more cars. It would take some time to get everyone on board, but that's OK... it's not like it would be one station of many for daily commuter rail service. The idea is to keep it cheap enough to be basically "throw-away", so that even if they ended up replacing it with something better a couple of years later, it would be no huge loss.
Virgin/Brightline could use one of their trains for a chartered Miami-Fort Lauderdale-WPB-KSC run before and after major launches. Yeah, in theory, SpaceX is sort of a competitor for Virgin Galactic... but not really. Just about the only thing VG and SpaceX have in common is, "launching rockets into space". Their market segments don't overlap AT ALL. Meanwhile, branding Virgin/Brightline as Florida's official "Space Train" would be an EPIC win for Virgin/Brightline in almost every conceivable way. Combined with the shuttle train(s) between KSC and the off-site parking lot, it would be a huge win for SpaceX as well, by vastly increasing the number of spectators able to watch a launch up close. More spectators = more political support for US space travel = more funding from Congress = more money for SpaceX.
They could additionally rent a couple of Tri-Rail's bi-level coaches for a couple of days before and after a major launch. Tow the coaches from SFRC/CSX to FEC, let FEC pull them up overnight with one of their freight trains, then use a FEC locomotive up in Titusville to haul them back and forth between the temporary mall station and the more permanent station at KSC itself.
The station at KSC itself could be constructed near the Banana Creek Launch Viewing area. People buying expensive tickets (that include admission to KSC) get to use the bleachers at the launch viewing area. People buying cheaper tickets (without admission to KSC, since KSC itself could never actually handle that many visitors on a launch day anyway) have a short bus ride to the Shuttle Landing Facility's runway, which could probably accommodate a quarter of a million visitors without being particularly crowded. Park some food trucks next to the runway, throw down a few dozen porta-johns, done.
They could also offer three different price levels for the rail shuttle... say, $A, $B, and $C. The difference? After the launch (or scrub), there would be three lines to board at the station. The $A tickets would be limited to the total capacity of two trips using the bi-level coaches rented from Tri-Rail. Each time a train arrives after launch/scrub, everyone in the $A line gets to board until they're either all on board, or the train is full. Then the $B line. Then finally, the $C line. After the first "mall shuttle" train (using the Tri-Rail cars) departs after launch, the Virgin/Brightline train would board, and head straight to Miami. With a little luck, the Virgin/Brightline train would reach the mainline and be heading south a minute or two before the mall-KSC train heading back to KSC reached the spur leading into KSC.
Later, once Virgin/Brightline's track to Orlando is
There's nothing to steal. This is all technology that has existed for years. Besides, posting it here is even better than patenting something I couldn't afford to pursue anyway... it'll help ensure that it becomes a free, open standard that NOBODY can successfully patent, and anybody can implement for free. Oh, sure... someone could TRY to patent it. They might even get a patent granted. But the moment they go to sue someone for infringement, the defendants' lawyer will find this post via Google & have credible evidence of prior art to argue for the patent's invalidation. I might not be able to become a millionaire, but I can at least enjoy the satisfaction of knowing that nobody ELSE got to become a millionaire based on the idea, either.
Exactly. We might be decades away from cars being able to drive to arbitrary destinations under wildly-varying road conditions, but if you constrain the problem's scope to "limited-access highways with grade-separation in relatively sane weather and driving conditions" or "bumper-to-bumper gridlock just about anywhere, where the car is basically creeping ahead a few inches at a time", current technology is STILL better than an average extraordinarily-distracted driver... and absolutely useful.
People who bitch about Tesla drivers on freeways (or bumper to bumper gridlock) not remaining fully alert to their surroundings are missing a very important key point... at least the Teslas have SOMETHING paying close attention to their surroundings, which is far more than you can say for at least 40-60% of the cars within 100 feet of them.
Anybody who thinks the overwhelming majority, let alone "all", of the drivers stuck in bumper-to-bumper traffic traffic are vigilantly paying attention is delusional & living in a fantasy world that hasn't existed for at least 5-10 years. Limited autonomy that covers the freeway+gridlock scenarios might not be 100% perfect, but it's still a net improvement over the real-world status quo that exists today.
For buses, 18-wheelers, and garbage trucks, the driver is probably the cheapest part of the daily operating expenses ANYWAY.
Automation is definitely coming to 18-wheelers, but it'll mostly be as a safety feature & way to reduce the training and skill necessary to safely drive one. Today, driving an 18-wheeler is HARD. If they can lower the bar to the point where anybody qualified to drive a 20-foot U-haul truck could safely drive an 18-wheeler across the country, that alone would be a huge cost-savings for the industry (not to mention, reduce the number of expensive accidents). At most, 18-wheelers MIGHT get to the point where they could have a single cross-country driver on board with a sleeper cab whose job is to babysit it over the long-haul, but who doesn't have to actively pay attention most of the time (with the truck automatically pulling over alongside the road if it decides it needs the driver & he/she can't take control in time). And even THAT would be a huge cost-savings for trucking companies, because it would allow regulators to relax the limits on how many hours any single driver can drive. It's one thing to say you can only drive {n} hours per day if you're sitting behind the wheel actively driving and have to keep it safe. It's another matter entirely if you're "working" for 30 hours (in the sense of, "you have to be on board the truck while it's in motion"), but only 2-4 of those hours involve actually sitting behind the wheel or doing anything besides sleep, read, play games on your Xbox One, etc.
Likewise, even if a bus didn't literally need a DRIVER, you'd almost certainly still need a human ATTENDANT on board. A bus like the ones used by big cities is UNGODLY expensive to buy and operate, and the savings from replacing a $30-50/hour driver with a $15-20/hour attendant is hardly a drop in the bucket compared to the amount of damage people could -- and WOULD -- do to an unattended expensive bus. Not to mention the lawsuits and social cost of having people get mugged or raped because the mugger/rapist and the victim were the only ones on board.
The only kind of transit-type vehicles for which unattended driverless operation really makes sense is something like an extended golf cart, like you'd find carrying people around a resort, or between a building and some off-site parking lot a block or two away. Maybe it would be different in other countries, but if a city like Miami or Atlanta had a $400,000 bus running unattended at 3am, it would be vandalized into oblivion within a matter of DAYS. You'd have homeless people using the rear section as a toilet, and anyone who had other transportation options would refuse to go anywhere NEAR those buses because they'd be disgusting, destroyed, and perceived (rightfully or not) as being dangerous.
Garbage trucks... maybe. But even then, you're talking about what would be an expensive, unattended vehicle that would probably be covered in graffiti within days. In the grand scheme of things, the cost of paying someone to sit behind the wheel of a big can-emptying robot as it crawls down the street is a drop in the bucket compared to the cost of the vehicle he's driving. Once again, you're talking -- at best -- about replacing a $30-50/hour driver with a $15-20/hour security guard.
Also... commercial vehicles tend to have relatively long service lives compared to passenger cars. In any given year, the total number of new 18-wheeler cabs, garbage trucks, and city buses that get sold is probably less than the number of new cars sold by a random Ford dealer in a medium-sized city in Iowa. Sure, commercial vehicles have bigger profit margins... but when you're talking about merely being able to use cheaper drivers instead of eliminate them entirely, and vehicles whose acquisition, maintenance, and operating costs completely dwarf the cost of their drivers (and the potential cost of things like vandalism), you rapidly get to the point where it's cheaper to just keep using human drivers.
For police cars, they'll eventually do something like this:
* Police officer wants car in front of him to pull over. Hits button signaling this intent.
* Police car computer reads the license plate (or otherwise determines the car's unique ID), creates a "pull over" request, and signs it with a certificate derived from the police department's certificate. It then gets communicated to the car through various means... probably multiple, including somewhere on a network that the car itself polls every few seconds, as well as encoding it into the light's flash pattern, and probably RF as well.
* Car being pursued sees the "pull over" request, verifies the certificate's legitimacy, and pulls over (or, if added as a retrofit safety feature to people worried about carjackers or others trying to trick them into pulling over, notifies the driver that the police officer is legit).
The certificate is important, because it's a safeguard to ensure that someone like carjackers, random hackers, etc. can't spoof "pull over" requests. In fact, I'd expect this to be something that gets implemented fairly quickly, since it's something that could easily be added to existing police cars and would be a fairly important safety feature. If autonomous vehicles react to something like flashing lights without validation, you're creating a MAJOR opportunity for bad guys to exploit it. I'd go so far as to predict that once someone comes up with a viable standard for this, it'll quickly become a popular retrofit feature (and required safety feature for new cars).
Personally, I'd expect something like this to become nearly universal among police cars within 3-5 years of becoming available as a standard retrofit product for existing police cars... a year to raise awareness of its existence, a year to get it put into next year's budget, a year to get it deployed, a year for remaining police departments that initially held out to realize their mistake & get it put into next year's budget, and a year for them to get it deployed as well. The technology all exists, and is relatively cheap & non-controversial... someone just needs to bake it into a viable standard and make it available as an off-the-shelf product, and it'll pretty much sell itself to police departments.
For trains, being early is arguably much, MUCH worse than being a little late, especially if you have to board at one of those intermediate stations. Passengers are annoyed if a train that's supposed to arrive at 5:15pm arrives at 6:30 and departs at 6:35, but they'll be enraged if the train they're supposed to catch at 5:15pm arrives at 4:57pm and departs at 5:04pm.
If your Ring doorbell gets stolen, they have a form you can submit to them along with a copy of the police report. Upon receiving the paperwork, they'll send you a free replacement doorbell and blacklist the one that was stolen.
Hmmm... from what I remember from my last experiment (~4-5 years ago), the big pain points I ran into were:
* Heavyweight desktop environments like Gnome, Cinnamon, and KDE are dysfunctional when running on the remote Linux box. With Windows and RDP, the remote Windows just wraps up its event traffic & passes it along to the client copy of Windows to handle. With Linux, you can't do that. Even IF you're running the same desktop environment on both the remote and local PCs, there's no supported way to transparently have notifications and event traffic originating from the DE on the remote box get handed off and handled by the DE on the client PC that you're using directly. So you lose a huge chunk of functionality right off the top.
* There's no graceful way to run the window manager locally on the client PC while retaining the ability to interactively launch arbitrary programs on the remote PC as if you were simply connected to a remote Windows PC using Remote Desktop. If you want to run the entire remote DE inside a client-side window, the remote PC's window manager has to manage all rendering within that window. In contrast, when you use RDP, the remote PC transparently delegates all of its "window manager" type activities to the "window manager" (Windows itself) on the client PC.
* If you want to use the local PC's window manager to handle the actual rendering, you have to individually and explicitly set up each and every program on the remote Linux box that you want to run so that launching it "locally" spawns an instance of the X11 server on the client PC, connects via SSH to the remote PC, then launches the app and exports its window content to the local PC's X11 server. Meanwhile, even with the window content itself being rendered locally, you're going to end up with the equivalent of a broadcast storm every time anything generates an event (like notifications to the remote PC that the mouse pointer has entered something, is currently over something, has exited something, etc).
In other words, it's kind of like setting up VMware to run a guest operating system's apps inside native host operating system windows... but ENORMOUSLY less convenient, and with significantly worse performance (because every action generates a storm of events that would be inconsequential if you were just passing messages between threads on a single PC, but take an ENORMOUS amount of time and resources to pass and process when you have a network in the middle as your communication bus).
* Did I mention yet that just about everything woven into a heavyweight desktop environment itself is going to be dysfunctional unless you run the DE (and everything spawned from it) within a single window whose contents are managed ENTIRELY by the remote PC's window manager? Forget about casual, adhoc usage via remote X11... every single thing you do has to be deliberately planned and configured, app by app, before it will work.
The problem is, using a desktop environment like Gnome or KDE with Linux on a remotely-hosted server absolutely SUCKS. VNC is awful, and networked X11 somehow manages to be even WORSE. Graphical remote access is one area where Windows has a MASSIVE lead over Linux.
Linux literally has nothing remotely (pun intended) comparable to Windows-native RDP. Linux has "solutions" that can "use" RDP, but all they REALLY do is wrap RDP around VNC and use the minimal subset of RDP that shovels raw bitmaps around. They allow you to connect to a Linux host using "Remote Desktop" (or a RDP-compatible client), but they don't support any of the acceleration features that make RDP such a huge improvement over VNC.
Microsoft has done plenty of things wrong over the years, and fucked up a lot of things, but RDP is an example of a long-term vision they totally got right. You can even use it with a moderately-powered PC with a high-powered video card and get near-native performance with DirectX (because the GPU code IS running locally and natively).
Seriously. Take a computer running Windows 7 in full Aero Glass splendor, and connect to it over a gigabit LAN from a suitably-powerful client PC, and the fact that you're running remotely is practically academic. Even DirectX works, and takes full advantage of your local videocard's capabilities.
Now try that with Linux. Go ahead, just try doing 3840x2560@60fps with 24-bit color using VNC. Let's see just how unsustainable and unscalable VNC's approach really is:
3840w x 2560h x 24bits/frame x 60frames/second = ~14gbps. Ouch.
Just ONE 4k monitor at 60fps, and you've already blown past the bandwidth of 10gbps ethernet by more than 50% by the time you factor in overhead.
Even 30fps comes close to completely monopolizing and maxing out a 10gbps LAN, with almost no headroom to spare. And that's assuming the host PC can even HANDLE 30gbps+ transfers over the PCI bus (15gbps to read the framebuffer from the video card into system RAM, 15gbps to throw it right back at the network adapter with minimal handling) without saturating it or bringing the whole system to its knees. At that point, you might as well just buy a hub to let you use 10gbps ethernet as a Thunderbolt transport layer for DisplayPort and USB, since nothing else is going to be able to meaningfully use that "LAN" anyway. At least then, your computer won't waste half its performance just blindly shoveling gigabytes per second of bitmap data around over its own PCI Express bus.
And X11 can't even DO advanced graphic effects, let alone do them with acceptable performance. In my experience, X11 somehow ends up usually being SLOWER than VNC, even though X11 conceptually seems like it ought to be faster since it's technically NOT trying to shovel the entire frame buffer over the LAN for every single frame.
I speak from experience. This has been one of my pet fetishes for years, going all the way back to 1999. I burned almost a week trying (unsuccessfully) to get Enlightenment to work over networked X11 with full eyecandy, went to Comdex a few months later, met Enlightenment's developers, and was told point blank that it was hopeless... Enlightenment basically had to sink its hooks directly into the kernel and X11 to work its magic, and simply depended upon things that didn't exist in the actual spec for networked X11. About 10 years later, I got Gnome to run (in its entirety) over networked X11 for the first time... and the performance was actually worse than VNC. It's sad, but the best way I've found so far to get high-performance networked graphics with Linux has been to run Linux under VMware on a computer running Windows, then connect to that computer using RDP. And even then, it's a toss-up whether it's better or worse than VNC.
I had high hopes for Wayland a few years ago... until its team unequivocably announced that high-performance native-RDP-like networked graphics weren't just a "non-priority" for Wayland... they weren't on the table as a design goal AT ALL, not even
In Florida, the difference between 'annuals' and 'perennials' is ALREADY kind of academic, and has little to do with their official categorization. Just about ANYTHING left to grow in Florida will survive for years. To Floridian homeowners, the thing that REALLY distinguishes between 'annual' and 'perennial' is, "does it look good year-round, or does it get ugly and look like a weed after it stops blooming?"
Case in point: marigolds. Left to grow without human interference, marigolds in Florida will live for YEARS. But they only bloom for a few months per year, and in the meantime... they look like ugly, spindly weeds.
Ditto, for "grass". If you keep it mowed, it looks like... well... grass. If you leave it to go wild, you'll eventually end up with tufts that are taller than you are, with blades as wide as your arm.
Antarctica wouldn't have had to be all THAT much further north to have had trees... just far enough north, with enough additional continental landmass to the east and west, to put a portion of its northern coastline in contact with warm equatorial ocean currents, in a spot where the jet stream would dissipate much of the remaining warmth over land instead of ocean.
For a very, very rough analogy, imagine that you're sitting outside in the winter on a non-windy cold day. Someone fires up a small jet engine and aims its hot exhaust at you a few hundred feet away. You aren't likely to feel a LOT of warmth from it, but it'll probably be a net improvement over no heat at all. Now, put some big, powerful fans halfway between you and the heater, aimed perpendicular to the exhaust's airflow, and turn them on (or, alternatively, wait for the wind to start blowing perpendicular to the direction of the hot exhaust). Almost instantly, you'll feel colder, even if you don't feel the breeze directly, because the new perpendicular airflow brings the warm jet of air into contact with more cold air, allowing it to give up its heat before it reaches you. That's kind of what happens to Antarctica today... the ocean currents warm the air, then the intense winds south of 30-50 degrees latitude leach the warmth and distribute it over a large area long before it reaches Antarctica's coastline.
Yep, they totally fucked over everyone who bought a WMV/HD disc(*) back around 2006. Sometime around 2012, they shut down the DRM server, and all the discs became fucking useless and unplayable. And they didn't even have the goddamn decency to offer their WMV/HD victims refunds.
---
(*)WMV/HD was Microsoft's short-lived attempt to preempt and hijack BOTH HD-DVD and Blu-Ray by promoting a third format based on VC1 that would have enabled DVD manufacturers to cheaply add the ability to play back HD content from normal single and double-layer DVD media. Officially, Microsoft promoted it as a "connect your laptop to your new HDTV now, and buy a future WMV-HD DVD player later" standard, but there's still disagreement about whether Microsoft genuinely intended to hijack the future HD optical-disc standard, or whether they were just using it as a bargaining chip to force Sony's hand and get them to agree to make VC-1 one of Blu-Ray's mandatory supported codecs. Microsoft already had HD-DVD in the bag, but Blu-Ray's consortium balked until Microsoft agreed to let them bundle it in players for free and charge higher royalties per-disc. Ultimately, it was moot... VC-1 is superior to h.264 and MPEG-2 at lower bitrates, but it now costs more to pay the higher royalties and use VC-1 to allow your content to use a single-layer disc than it does to just use a higher bitrate with a cheaper codec and a dual-layer disc instead.
I think Amazon's motive is to come up with a way for a home theater amp, TV, media device, etc. to watermark its audio output in a way that tells a listening Alexa-implementing device, "don't be triggered by THIS SPECIFIC audio" (so every time someone on TV says, "Alexa" the device WON'T be triggered).
The catch is, the device needs a way to distinguish between "media audio" (that should NOT trigger it) and people in the room (who should ALWAYS be able to trigger it, even while watching a TV show or movie with the 'ignore me' watermark).
It has to be something that a device on the consumer end can add, because remastering a century's worth of media to add it at the content-producer's end just plain isn't going to happen.
Amazon is painfully aware of the "TV triggered Alexa" problem. It's not just annoying, it's a real potential vulnerability (mitigated mostly by the fact that buying radio & TV ads is both expensive & non-anonymous, so an ad that INTENTIONALLY tried to exploit it would get the advertiser sued). They don't want to just overlay a "dumb" "ignore everything for {n}ms" ultasonic tone burst, because THAT could be abused as well (say, by advertisers who wanted to prevent an Alexa-controlled device from accepting commands from ANYONE during the ad). So... it needs to be:
* specific to media being played in the presence of an Alexa-implementing device
* able to be injected at the consumer end, and something that could cheaply be added to something like a blu-ray player (ideally, lightweight enough to implement as a firmware update to existing players).
* NOT affect verbal commands from humans in the room.
Incidentally, I believe Amazon initially considered trying to use Cinavia for this purpose (since it's already present in many movies), but quickly realized it would cause more problems than it solved. Cinavia was designed to robustly (and indiscriminately) scream, "stop recording!", not "ahem... please don't attempt speech-recognition on THIS SPECIFIC audio". If Echo ignored 'Alexa' for {n} seconds after recognizing a Cinavia watermark, mere playback of Cinavia-watermarked content within listening range would effectively disable the use of 'Alexa' entirely for those {n} seconds. Ergo, Amazon had to come up with something better.
To wit, this is NOT about imposing DRM. It's about preventing media content from triggering the device by having someone on-screen say 'Alexa', by giving the device a way to distinguish BETWEEN media content and local users.
About 4 years ago, I dusted off an old Compaq Armada laptop (700MHz Pentium III, 512mb ram) and tried using it with a minimalist Linux distro. The performance of Chrome or Firefox with Amazon.com and Walmart.com was SLIGHTLY better than the performance of the same two web sites with my then-new Galaxy Note 4 (all using wifi, so the mobile network quality never entered into the equation).
The Pentium III is a great reference point, because its zenith (the 1.4GHz Pentium III Xeon) marked the point when Intel temporarily ran into a brick wall and spent the better part of a decade unable to meaningfully improve its single-thread performance. During that period, it was struggling to compete in ARM's home court, and ARM was scoring occasional victories. Compared to Intel's lower-end CPUs, like the Atom family (which, as I understand it, were basically just die-shrunk Celeron IV processors with power management bolted on, the same way the Pentium M family were basically die-shrunk Pentium III Xeons with power management bolted on), ARM looked fairly respectable.
Seriously, I challenge anyone to name ANY ARM-based CPU or SoC that satisfies the following requirements:
* Absolute single-thread performance as good as, or better than, an Intel i9 9900K or 9900KF
* Multi-thread performance as good as, or better than, an Intel i9 9900K[F], the only constraint being that all of the CPU cores have to be on the same slab of silicon inside the same packaged chip.
* The ARM chip has to be available in single quantities, to anyone with a valid credit card, with at most a 7-day lead time, for less than what it would cost our same hypothetical consumer with a credit card to purchase an i9 9900K[F].
* The ARM chip has to be usable in a system that a reasonably sophisticated end user (who nevertheless is NOT Linus Torvalds or doing it as a work-related project with the resources of his employer at his disposal) could install Windows or Linux upon and run normal software directly (emulation doesn't count).
Simply put, such a hypothetical ARM chip IS, in fact, hypothetical. It's fantasy. Even if you managed to solve the chip-availability problem, you'd literally have to be a company with the resources of Qualcomm or Samsung to get anywhere close to being capable of obtaining a genuinely i9-competitive chip and using it in a system capable of running Windows or Linux, because basically NOTHING in ARM-land is standardized. Everything near the highest-performance bleeding edge of ARM ends up being coture and proprietary, and without living at that razor's edge, you can forget about getting performance that's any better than what you'd get from a mediocre, middle-of-the-road x86/AMD64 solution.
ARM is for building cheap, disposable army ants and pack mules. Intel architecture is for building omnipotent combat robots capable of leveling the countryside while its AI ponders early 20th-century human philosophy and its structural contradictions. There's a huge gray area between the two extremes, but the fact is, if you want extreme performance at a halfway-sane price using off the shelf technology and products that aren't one-off custom prototypes, you have one real choice: x86/AMD64.
If you want a new laptop whose designers wished they could have made a sealed slab of translucent Lucite with 60 hour battery life... even if it's slow, and sucks heinously at running any kind of normal Windows or Linux desktop application... by all means, go ARM. If you want 90fps realtime raytracing for your Oculus Rift, pretty much ANY solution involving ARM-based COTS hardware is guaranteed to leave you disappointed for the conceivable future.
Poor people can be extraordinarily profitable if you have the resources, infrastructure, and warped moral compass required to aggressively exploit them. Poor people generally have few options and no bargaining power, so the fact that you're willing to do business with them puts you in an extraordinarily powerful position to dictate "take it or leave it" terms.
And yet, an Android phone with 8+ cores and nominal clock speed of 2GHz+ still can't render a Javascript-heavy web site (like Amazon, Walmart, or Sears) as well as a 15 year old 700MHz Pentium III.
> without having an astronomical price
Scale an ARM-based solution up to the point where it's capable of genuinely matching the performance of an i9, and you'll find that the ARM-based solution is probably quite a bit MORE expensive.
> without requiring a nuclear power station sitting on the desk
Compared to the power and cooling requirements of a Pentium IV with 15kRPM hard drive, an i9 with RTX and SSD is practically a laptop watt-wise. 20 years ago, I literally cut a hole in the wall between my computer room and the hallway so I could put my computer in the hall & pass the cables through the wall to get the heat and noise out of my face.
> 2) Cost of running the CPU in heat and power is *significantly* less than intel/amd
ONLY true when the ARM's performance is significantly less than Intel/AMD as well. Beef an ARM up to i9 specs, and it's going to burn as much power and throw off as much total heat AS an i9 with identical raw performance.
It's like LED lighting. A single LED might throw off light with just milliwatts of power... but crank it up so it's throwing off EXACTLY the same amount of light as a 100-watt halogen lightbulb (measured from every direction), with color fidelity that's at least as good as that 100-watt halogen bulb (none of this "80+ CRI" shit, or even "92+ CRI with weak R9"), and it's going to CONSUME at least 70-80 watts and throw off almost as much heat AS the original incandescent bulb. Because the only way to get deep, saturated reds without making the light appear 'pink' is to crank up the near-infrared output (which stimulates your 'long' cones, without bleeding into green/blue territory and desaturating it). And even if you settle for lower-quality light, the power consumption is no better than fluorescent bulbs, because a "white" LED basically IS a "fluorescent" bulb.
If you want the equivalent of an elderly personal servant or ten thousand army ants instead of a half-dozen deity-like level bosses, ARM might win over Intel/AMD64. Try to scale the army ants TOO much, and you end up wasting most of your effort just trying to keep them coordinated (the current bane of multithreaded programming).
Technically, GMT is NOT the same as UTC. There are actually three different standards... GMT, UTC, and TAI.
They differ because the precise length of an orbital & rotational year is neither 100% consistent nor predictable.
GMT is defined by solar noon at the Greenwich Observatory in London. If observation reveals that we've wobbled by a few milliseconds, GMT changes to reflect that. It sounds nice in theory, but 99.999% of use cases honestly don't give a fuck whether solar noon at Greenwich happens a few hundred milliseconds (or entire seconds) early or late.
TAI is kind of like Unix time, except it has much greater precision. It defines a second as a precise number of cesium-137 decay periods, a year as a precise number of seconds, and counts both as an offset from its starting point. TAI currently deviates from GMT by ~32 seconds.
UTC was envisioned as a compromise between GMT and TAI. It adds and removes seconds to ensure that UTC's noon falls within a half second of Greenwich solar noon. It's also a royal pain in the ass to deal with, because unlike TAI, UTC is a historical moving target. 9:47:42 July 18, 1997 UTC is NOT precisely 8 years before 9:47:42 July 18, 2005 UTC (even accounting for leap year gymnastics), because a couple of seconds were added as well
UTC makes a mess of things like timestamped logs, the same way DST does... but worse, because most people using UTC for timestamps are doing it PRECISELY to avoid the DST timestamp problem, and have no idea that "leap seconds" even EXIST until the first time they get burned by it.
UTC-vs-TAI was exacerbated by the sudden popularity of using internet time protocol (NTP) to automatically set clocks on computers. In the past, people set the time, and let it go until they manually updated it at their own convenience. Leap seconds were rare to begin with during that era, and a second or two gain or loss when the computer got rebooted was lost in the greater disruption of the reboot itself.
Fast forward to sometime around 2006, when UTC-via-NTP had become commonplace, and a leap second occurred, Linux computers all automatically observed it, and all hell broke loose when software that assumed that "UTC" behaved like TAI found itself with 2 seconds' worth of logged activity bearing the same timestamp (and often, undefined weirdness if computations involving milliseconds were involved on computers that did 64-bit timekeeping).
As I understand the "Linux" problem, programmers want TAI-like behavior, but POSIX compliance explicitly requires UTC... switching Linux to TAI would require changes to POSIX to allow timestamps to unambiguously indicate whether they're UTC or TAI, and the current 32-second difference is too big to just sweep under a rug and ignore. So instead, we have a complicated system where computers use NTP to sync up to TAI, then the OS converts TAI to UTC and adds/removes leap seconds before exposing it as the leap-second-mangled offset from midnight January 1, 1970 for consumption by programs that don't actually CARE about the precise moment of solar noon @ Greenwich.
The proposed solution is almost worse... ending leap seconds in UTC (to avoid rewriting POSIX & everything it dictates, causing YEARS of insidious bugs in the process), and inventing a FOURTH standard to do what UTC currently does & keep astronomers happy.
Compounding matters even more is disagreement about how to handle the leap seconds we already have. If UTC retroactively wipes them out, we're back to the problem of ambiguity with "UTC" timestamps between the 1980s and present... no way to indicate whether it's a "legacy" UTC timestamp or a "revised" one. If it doesn't, we'll still have to deal with those legacy timestamps in perpetuity.
The net result is that we're likely stuck with UTC and dealing with leap seconds in Linux for at least another decade or two. My guess is that POSIX will be left alone, UTC will eventually stop adding leap seconds (but leave the existing ones as-is), and they'll come up with a new standard for Astronomers to take the place of UTC.
Slashdot Mirror
Just to add another example of how 5G could offer improved location service...
GPS works by having a constellation of satellites with very accurate clocks onboard that periodically broadcast a timestamped beacon. At the receiving end, you note the (local) time the beacon was heard.
Then, you look up the coordinates, motion vector, and timestamp of the satellite's last ephemera update, then calculate where it OUGHT to be as of the instant specified in the timestamp... and repeat for all the satellites in view. Because satellite orbits drift over time, the ephemera data has to be updated periodically (ironically, I think the GPS satellites determine THEIR OWN locations by triangulation from similar beacons at precisely-known locations on earth).
Once you know where each satellite was located at the instant of their timestamp, you can derive your own location (by comparing your own clock's timestamps on each beacon datagram with those from the satellite, based on the speed of light & known signal-propagation characteristics).
You might see a catch-22... your phone's clock isn't as accurate as the clocks in the GPS satellites, and there's always going to be a degree of uncertainty if you have to set it BASED UPON a consensus of GPS satellites & local towers. HOWEVER, if a tower's physical location is precisely determined by surveyors, its clock-setting logic can use that information to derive a more precise time from GPS satellites (basically, adjusting its own clock until the locations derived from GPS match the location determined by the surveyor). And phones can precisely set their own clocks, because the speed of light over a mile or so is practically instantaneous compared to the distance to a GPS satellite.
The main limit with 5G is the stability of the antenna & support structure itself. I think one difference between 4g and 5g is that 5g ALSO reports its predicted margin of error & confidence, and might do additional tower-site logic to take things like tower-sway into account. Because otherwise, you might calculate a location that claims to be within 33mm, but could vary by 12 feet due to the antenna being mounted on a tower that's swaying by 12 feet at the tip. When you start trying to get THAT kind of precision, uncertainty about the location of the antenna ITSELF becomes a big deal.
Conceivably, a 5G tower that wanted to be extraordinarily accurate as a location source could use additional sensors to measure that moment-to-moment deviation. Not just accelerometer & gyro, but also cameras observing it from different angles, anemometers coupled with the tower's known flexure at a given temperature & wind speed, etc... and providing a way to obtain (via side-channel) the additional raw sensor data, so clients won't have to be limited by the software running at the tower site itself. Someone (like a researcher) COULD actually grab the "raw" data, and do his own calculations with it. Basically, the goal with 5G was to avoid imposing arbitrary limits. You can get precise location data now, but you could potentially get MORE precise data in the future as the sensors & certifications of the site improve, better algorithms are discovered, etc.
Remember... EVERY measurement ALWAYS has some degree of uncertainty... and some sensors are a lot more "uncertain" than others. You can take advantage of known parameters (like location surveyed with high precision), but ultimately EVERYTHING is at least slightly wrong. For a perfect example, think back to analog paddle controllers back in the "Atari" era. Even with low-res displays, you had at least a few pixels of frame-to-frame jitter. No sensor EVER gives you a 100% accurate instantaneous reading. It's just how sensors ARE. You can improve accuracy by oversampling & integrating readings from multiple sensors, but ultimately... every reading is STILL an educated guess.
2G specifically would have severe scalability problems. AFAIK, each 2G data link is basically a circuit-switched voice call that skips the modem part and goes straight to the bitstream. In landline terms... kind of like ISDN. The point is, if a given tower is provisioned to handle ~24 simultaneous voice calls, each 2G data connection eats up one of those slots for its duration.
So... 2G might work if the collars connected only infrequently, for a few seconds, and had the ability to wait random delays before attempting the next connection... but even a single herd with a few thousand cattle attempting to "phone home" daily would probably have a noticeable impact on at least a single tower's capacity.
3G could handle daily uploads without breaking a sweat, but would run into problems if collars tried to treat it like an "always on" connection. AFAIK, no single tower in a 3g network can handle more than a single subnet, and IP leases are (usually) for an hour, so after the first {n} radios connect and establish a session, nothing else can connect until users from the first {n} go away and stay away for the remaining duration of their lease.
I'm not sure how much of 3G's limit is hard-baked in to the standard itself, vs the de-facto limits imposed by off the shelf hardware, software, and configurations used by carriers out of habit, but I know 3G doesn't deal well with situations that involve HUGE numbers of transient users over a short window of time... the crowd blows through the tower site's DHCP pool, and for a while nobody else can connect at all.
I think 3G's max tower-users-per-time-interval can be tweaked upwards (by allocating more IP addresses per tower, reducing DHCP lease times, etc), but the point is that an "average" 3g tower with typical urban-suburban configuration would probably have issues if a farmer suddenly lit up tens of thousands of 3G radio collars over the span of a few days without at least coordinating it with the cellular network (to give it a few months to re-provision the affected tower site with a more appropriate configuration).
The point is, it goes beyond merely "total bits per second". There are also limits on the total number of user sessions per time-interval, and those limits can become significant if an area suddenly experiences an unanticipated surge in total connections, even if they aren't transmitting more than a few bytes of payload data apiece.
4G mainly gives enough headroom to make "lots of ephemeral connections from lots of users within a short interval of time" less of a problem. It HAD to, because the rapid emergence of Android & Iphone (all continuously making network requests in the background) pushed existing 3G networks to the breaking point. A 3G tower next to a 14-lane freeway that might have once served a few thousand users who "went online" deliberately suddenly had tens of thousands of users per hour driving by & establishing data sessions so they could ping Facebook or Twitter in the background. 4G had other benefits, but the increase in the default connection limit per tower site between middle-stage 3G and early 4G was a big one. It's also why it's legit to call HSPA "4G"... a tower configured for HSPA can basically handle as many connections per hour as a LTE tower of the same era, and WAY more than the same tower could back when it first went online in early-3G UMTS form. It's not as efficient as LTE, but most of the hard limits users associate with "3G" are gone.
Ditto, for 4G vs 5G. If you only care about ping times & speedtest benchmarks, a pimped-out LTE tower with lots of low AND high-frequency spectrum doesn't look all that different to end users than a "5G" tower with the same spectrum and users. 5G's benefits are mostly in the "efficiency" realm, plus features like enhanced location-positioning (basically, every 5G tower broadcasts a periodic beacon with GPS-like timestamp that can be combined with a database of known tower locations and acts like a terrestrial GPS satellite). I'm pretty sure 4G d
I think the main thing we're disagreeing about is where SpaceX is likely to launch most of the BFR rockets. I think SpaceX originally explored multiple options (including the floating platform), but decided towards the end of last year to use 39A for most BFR launches once it's officially in production.
FEC is heavily used, but it's double-track in the area.
I'm not 100% sure that it's fully double-track all the way from Jacksonville to Miami, but I'm 99% confident that if it's not... it WILL be within the next 2-3 years.
Virgin/Brightline hasn't (AFAIK) OFFICIALLY announced future expansion to Jacksonville yet, but pretty much everyone takes for granted that it's going to happen, and the only real question is when it will happen compared to the launch of Miami-Orlando and its extension to Tampa. As a practical matter, the only thing Virgin/Brightline really NEEDS to do to add Jacksonville as a destination is build stations in Jacksonville (and probably Daytona, somewhere in Brevard county, and possibly somewhere around Vero Beach), buy more trainsets, and upgrade the crossings & signals to allow 110mph operation... not a trivial expense, but pretty cheap compared to what they're spending to build brand new tracks from Cocoa to Orlando.
My personal prediction is that once Virgin/Brightline is running to Orlando, Tampa, and Jacksonville, Amtrak will revise their long-distance trains in Florida to split them in Jacksonville & send half down FEC to Miami, and the other half along their current route to Orlando & Tampa (and if they're smart, continue them beyond Tampa to a new station next to Sarasota Airport since they'd no long HAVE to continue from Tampa to Miami). They might even have a code-sharing agreement with Virgin/Brightline to allow Miami-bound passengers from New York to ride in the "Tampa" end to Jacksonville, then transfer to Virgin/Brightline for the final leg (or Tampa-bound to ride in the "Miami" end) if the half of the train going to their desired destination sells out.
To make up for the loss of Amtrak service to Winter Haven and Sebring, Sunrail could "sort of" extend its service all the way down to Sebring... still ending MOST trains at Poinciana, but extending 3 or 4 per day all the way down to Sebring. One would be a normal Sunrail train that simply overnighted in Sebring & began its run in Sebring at a time that had it running through downtown Orlando around 8:30am. Another would be a normal southbound Sunrail train that passed through downtown Orlando around 6:15-6:30pm and continued all the way to Sebring. A second would be timed to allow someone in Sebring to arrive in downtown Orlando around 7:30pm, and depart southbound around 10 or 11pm. The third and fourth would only serve stations south of downtown and be timed to provide guaranteed connections to Amtrak's trains via Kissimmee Station. It would be a little less convenient for long-distance travelers, but IMMENSELY more useful for people who LIVE in Sebring and Winter Haven (by allowing them to take the train to work in downtown Orlando, to attend evening events in downtown Orlando including Orlando Magic games, and allow elderly residents (who live there in ABUNDANCE) to easily take the train to visit doctors in downtown Orlando, or connect to Brightline (via the airport station) for travel to Miami, Tampa, or Jacksonville.
Even if SpaceX decides to do BFR launches from the sea, I'll be shocked if the majority of their other launches don't use Cape Canaveral. It just doesn't make economic sense to do sea launches when you have a perfectly good launch site on dry land that can easily be reached, absent some really urgent, compelling safety reason to do the launch offshore. At sea, literally EVERYTHING becomes an expensive exercise in logistics... employees, supplies, EVERYTHING. Sure, they might do it if they're testing a new design that has a nontrivial chance of blowing up... but for routine launches, it would be senseless. Especially since they already have a lease on pads 39a and 40, and have spent HUGE amounts of money on fixed ground infrastructure there.
KSC's visitor operations are run by a company that has little to do with launch operations. NASA tells them what they're allowed to do on launch day & reviews their plans, but has very little to do with the direct handling of those launch-day crowds.
Over time, the service would presumably evolve to accommodate different crowds for different launches. For example:
* Routine launch, one of 4-6 SpaceX launches taking place that week: Single train operated by Sunrail under contract. Departs from DisneyCelebration station, stops at MCO, stops at the future Brevard County Virgin/Brightline station, and ends at the Banana Creek viewing area station. Arrives 30 minutes before launch, departs 10 minutes after the last booster landing visible from KSC.
* Noteworthy launch likely to generate a significantly larger crowd: two charter Virgin/Brightline trains (Miami-FLL-WPB-KSC, Tampa-Lakeland-Disney-MCO-KSC). Train leased for event from Sunrail runs Disney-MCO-Brevard-KSC in the morning (to position the train, and provide an easy way for tourists in Orlando to visit KSC for the day), then runs back and forth between KSC and the Brevard station with at least two inbound trips before the launch, and two after the launch. Depending on how many people are projected to ride and the time of day, the second train could then continue directly home to Orlando, or it could return to KSC and head home a half hour after NASA closes to visitors for the day.
* Launch likely to generate an even bigger crowd: Possibly add another chartered Virgin/Brightline train from Jacksonville, with additional shuttle trains rented from Sunrail and Tri-Rail running between the Brevard station and KSC station during the 2-3 hours before launch & afterwards. Sunrail trains coming from Orlando go directly to KSC, since Brevard-KSC trips are being adequately handled by the shuttle train(s).
Then, there's the BIG event... the future Mars launch. The equivalent of NYE 1999 in Times Square, South Beach, and New Orleans combined... plus Burning Man, Coachella, and Woodstock '69 thrown on top. Launch-day crowd likely to be in the TENS of millions by the time you count everyone within 50 miles who doesn't live in Florida, or live within 50 miles of Titusville.
** Pretty much every railcar in Virgin/Brightline's fleet will be running between Tampa & KSC, Miami & KSC, and Jacksonville & KSC, with regular daily service around Florida suspended (but arranged so that someone traveling Miami-Orlando/Tampa could get off the train in Brevard, and transfter to a train heading back to Tampa after dropping off its passengers at KSC).
** Amtrak suspends regular service for 2-3 days before and after the launch. Amtrak aggregates its sleeper cars & dining cars into rolling hotel trains that get parked on the spur adjacent to the northern end of the shuttle runway and become the largest adhoc rail-hotel in the history of the world after running from various cities to KSC (to cheaply make room to park basically Amtrak's entire fleet of sleeper cars, they cut a pair of shallow trenches in the road that continues beyond the tracks' end to the north end of the runway & drop in steel rails... you wouldn't want to RUN trains on rails like that, but they'd be good enough to park the trains on for a day or two).
** Meanwhile, Amtrak's entire fleet of coach cars gets temporarily re-deployed to do runs between Jacksonville and Miami for 12-24 hours before and after launch. These trains don't go to KSC itself... not even trains can get THAT many people into KSC. Instead, their goal is to prevent several million cars from turning every road within 25 miles of Brevard County, including 528, I-4, the Turnpike, and I-95, into a multi-day parking lot. They stop at Virgin/Brightline's stations, as well as a half-dozen adhoc stations built for the event within walking distance of the causeways leading to NASA, or other spots further off that are adjacent to vast amounts of parking. The causeways themselves are basically clos
The last thing the US wants to do is "take out" Russia's economy, because then we'd have to worry about dealing with an impoverished, destabilized country that owns a large arsenal of nuclear weapons with substantial resale value. It's in our best interest for Russia to be affluent, happy, and feel secure. Politics isn't a football game.
The US is enormously safer and better off when Russia is a stable, wealthy, happy partner to do research and business with. It's fine for the US and Russia to be adversarial, as long as you recognize that an "adversary" isn't necessarily an "enemy". Sometimes, it's good to have a little bit of healthy adversity between worthy opponents... it keeps everyone honest & avoids stagnation. But you don't want it to turn into silly cheerleading and enmity, because that just leaves EVERYONE worse off.
And the fact is, by the time SpaceX really starts to eat into Russia's market share, they'll be following the same path towards reusability and lower cost as SpaceX. Remember, half the battle in inventing something is knowing it's possible. Now they know.
The fact is, Russia's space program isn't going away, even IF it becomes unable to compete with SpaceX on cost, because manned spaceflight is as important to Russia's national pride and sense of identity as it is to America's. If SpaceX undercuts Russia, Russia will follow in SpaceX's footprints, duplicate its success, and will hemorrhage as much money as necessary in the meantime to keep up appearances. Because the alternative is inconceivable to Russians.
Americans were traumatized when the shuttle program ended with no replacement in sight, but we could at least take a small bit of comfort knowing that it wasn't the first time we were temporarily out of the game. The same thing happened in the 1970s... Apollo ended, Skylab crashed, and the Shuttle just kept getting delayed and delayed. Then there was the lapse after the Challenger explosion. And another lapse after Columbia's accident. In contrast, most Russians have NEVER known a world where they didn't have the ability to send men into space. Even when the Soviet Union was disintegrating and Russia was on the brink of civil war, Mir was still occupied. And by the time Mir was deorbited, the ISS was already under construction (and might, in fact, have already had the Russian module in place, though I don't think it was ready for continuous habitation at that point).
Kennedy Space Center desperately needs to improve their spectator logistics. The biggest single thing limiting the number of people who can watch launches "up close" isn't crowd capacity, it's limited parking and road capacity into KSC.
KSC should try to make a deal with FEC Railroad, Brightline, Tri-Rail, and Titusville Mall:
Titusville Mall is practically dead, has a huge parking lot, and sits a short block away from FEC's tracks. I'm sure its owners would be absolutely thrilled to have an excuse to collect $10/car to park there on launch days.
FEC owns the tracks leading to the spur that goes to KSC itself.
They could lease the vacant lot at/near 3547 S. Hopkins Avenue (south of the Shell Station at Country Club Drive) so they'd have a place for people waiting for the train to stand. To save money, they could build a wood platform (with stairs and a single wheelchair ramp) wide enough to span between two Tri-Rail bi-level cars, and stick additional wood stairs on concrete pads for access to two more cars. It would take some time to get everyone on board, but that's OK... it's not like it would be one station of many for daily commuter rail service. The idea is to keep it cheap enough to be basically "throw-away", so that even if they ended up replacing it with something better a couple of years later, it would be no huge loss.
Virgin/Brightline could use one of their trains for a chartered Miami-Fort Lauderdale-WPB-KSC run before and after major launches. Yeah, in theory, SpaceX is sort of a competitor for Virgin Galactic... but not really. Just about the only thing VG and SpaceX have in common is, "launching rockets into space". Their market segments don't overlap AT ALL. Meanwhile, branding Virgin/Brightline as Florida's official "Space Train" would be an EPIC win for Virgin/Brightline in almost every conceivable way. Combined with the shuttle train(s) between KSC and the off-site parking lot, it would be a huge win for SpaceX as well, by vastly increasing the number of spectators able to watch a launch up close. More spectators = more political support for US space travel = more funding from Congress = more money for SpaceX.
They could additionally rent a couple of Tri-Rail's bi-level coaches for a couple of days before and after a major launch. Tow the coaches from SFRC/CSX to FEC, let FEC pull them up overnight with one of their freight trains, then use a FEC locomotive up in Titusville to haul them back and forth between the temporary mall station and the more permanent station at KSC itself.
The station at KSC itself could be constructed near the Banana Creek Launch Viewing area. People buying expensive tickets (that include admission to KSC) get to use the bleachers at the launch viewing area. People buying cheaper tickets (without admission to KSC, since KSC itself could never actually handle that many visitors on a launch day anyway) have a short bus ride to the Shuttle Landing Facility's runway, which could probably accommodate a quarter of a million visitors without being particularly crowded. Park some food trucks next to the runway, throw down a few dozen porta-johns, done.
They could also offer three different price levels for the rail shuttle... say, $A, $B, and $C. The difference? After the launch (or scrub), there would be three lines to board at the station. The $A tickets would be limited to the total capacity of two trips using the bi-level coaches rented from Tri-Rail. Each time a train arrives after launch/scrub, everyone in the $A line gets to board until they're either all on board, or the train is full. Then the $B line. Then finally, the $C line. After the first "mall shuttle" train (using the Tri-Rail cars) departs after launch, the Virgin/Brightline train would board, and head straight to Miami. With a little luck, the Virgin/Brightline train would reach the mainline and be heading south a minute or two before the mall-KSC train heading back to KSC reached the spur leading into KSC.
Later, once Virgin/Brightline's track to Orlando is
There's nothing to steal. This is all technology that has existed for years. Besides, posting it here is even better than patenting something I couldn't afford to pursue anyway... it'll help ensure that it becomes a free, open standard that NOBODY can successfully patent, and anybody can implement for free. Oh, sure... someone could TRY to patent it. They might even get a patent granted. But the moment they go to sue someone for infringement, the defendants' lawyer will find this post via Google & have credible evidence of prior art to argue for the patent's invalidation. I might not be able to become a millionaire, but I can at least enjoy the satisfaction of knowing that nobody ELSE got to become a millionaire based on the idea, either.
Exactly. We might be decades away from cars being able to drive to arbitrary destinations under wildly-varying road conditions, but if you constrain the problem's scope to "limited-access highways with grade-separation in relatively sane weather and driving conditions" or "bumper-to-bumper gridlock just about anywhere, where the car is basically creeping ahead a few inches at a time", current technology is STILL better than an average extraordinarily-distracted driver... and absolutely useful.
People who bitch about Tesla drivers on freeways (or bumper to bumper gridlock) not remaining fully alert to their surroundings are missing a very important key point... at least the Teslas have SOMETHING paying close attention to their surroundings, which is far more than you can say for at least 40-60% of the cars within 100 feet of them.
Anybody who thinks the overwhelming majority, let alone "all", of the drivers stuck in bumper-to-bumper traffic traffic are vigilantly paying attention is delusional & living in a fantasy world that hasn't existed for at least 5-10 years. Limited autonomy that covers the freeway+gridlock scenarios might not be 100% perfect, but it's still a net improvement over the real-world status quo that exists today.
For buses, 18-wheelers, and garbage trucks, the driver is probably the cheapest part of the daily operating expenses ANYWAY.
Automation is definitely coming to 18-wheelers, but it'll mostly be as a safety feature & way to reduce the training and skill necessary to safely drive one. Today, driving an 18-wheeler is HARD. If they can lower the bar to the point where anybody qualified to drive a 20-foot U-haul truck could safely drive an 18-wheeler across the country, that alone would be a huge cost-savings for the industry (not to mention, reduce the number of expensive accidents). At most, 18-wheelers MIGHT get to the point where they could have a single cross-country driver on board with a sleeper cab whose job is to babysit it over the long-haul, but who doesn't have to actively pay attention most of the time (with the truck automatically pulling over alongside the road if it decides it needs the driver & he/she can't take control in time). And even THAT would be a huge cost-savings for trucking companies, because it would allow regulators to relax the limits on how many hours any single driver can drive. It's one thing to say you can only drive {n} hours per day if you're sitting behind the wheel actively driving and have to keep it safe. It's another matter entirely if you're "working" for 30 hours (in the sense of, "you have to be on board the truck while it's in motion"), but only 2-4 of those hours involve actually sitting behind the wheel or doing anything besides sleep, read, play games on your Xbox One, etc.
Likewise, even if a bus didn't literally need a DRIVER, you'd almost certainly still need a human ATTENDANT on board. A bus like the ones used by big cities is UNGODLY expensive to buy and operate, and the savings from replacing a $30-50/hour driver with a $15-20/hour attendant is hardly a drop in the bucket compared to the amount of damage people could -- and WOULD -- do to an unattended expensive bus. Not to mention the lawsuits and social cost of having people get mugged or raped because the mugger/rapist and the victim were the only ones on board.
The only kind of transit-type vehicles for which unattended driverless operation really makes sense is something like an extended golf cart, like you'd find carrying people around a resort, or between a building and some off-site parking lot a block or two away. Maybe it would be different in other countries, but if a city like Miami or Atlanta had a $400,000 bus running unattended at 3am, it would be vandalized into oblivion within a matter of DAYS. You'd have homeless people using the rear section as a toilet, and anyone who had other transportation options would refuse to go anywhere NEAR those buses because they'd be disgusting, destroyed, and perceived (rightfully or not) as being dangerous.
Garbage trucks... maybe. But even then, you're talking about what would be an expensive, unattended vehicle that would probably be covered in graffiti within days. In the grand scheme of things, the cost of paying someone to sit behind the wheel of a big can-emptying robot as it crawls down the street is a drop in the bucket compared to the cost of the vehicle he's driving. Once again, you're talking -- at best -- about replacing a $30-50/hour driver with a $15-20/hour security guard.
Also... commercial vehicles tend to have relatively long service lives compared to passenger cars. In any given year, the total number of new 18-wheeler cabs, garbage trucks, and city buses that get sold is probably less than the number of new cars sold by a random Ford dealer in a medium-sized city in Iowa. Sure, commercial vehicles have bigger profit margins... but when you're talking about merely being able to use cheaper drivers instead of eliminate them entirely, and vehicles whose acquisition, maintenance, and operating costs completely dwarf the cost of their drivers (and the potential cost of things like vandalism), you rapidly get to the point where it's cheaper to just keep using human drivers.
For police cars, they'll eventually do something like this:
* Police officer wants car in front of him to pull over. Hits button signaling this intent.
* Police car computer reads the license plate (or otherwise determines the car's unique ID), creates a "pull over" request, and signs it with a certificate derived from the police department's certificate. It then gets communicated to the car through various means... probably multiple, including somewhere on a network that the car itself polls every few seconds, as well as encoding it into the light's flash pattern, and probably RF as well.
* Car being pursued sees the "pull over" request, verifies the certificate's legitimacy, and pulls over (or, if added as a retrofit safety feature to people worried about carjackers or others trying to trick them into pulling over, notifies the driver that the police officer is legit).
The certificate is important, because it's a safeguard to ensure that someone like carjackers, random hackers, etc. can't spoof "pull over" requests. In fact, I'd expect this to be something that gets implemented fairly quickly, since it's something that could easily be added to existing police cars and would be a fairly important safety feature. If autonomous vehicles react to something like flashing lights without validation, you're creating a MAJOR opportunity for bad guys to exploit it. I'd go so far as to predict that once someone comes up with a viable standard for this, it'll quickly become a popular retrofit feature (and required safety feature for new cars).
Personally, I'd expect something like this to become nearly universal among police cars within 3-5 years of becoming available as a standard retrofit product for existing police cars... a year to raise awareness of its existence, a year to get it put into next year's budget, a year to get it deployed, a year for remaining police departments that initially held out to realize their mistake & get it put into next year's budget, and a year for them to get it deployed as well. The technology all exists, and is relatively cheap & non-controversial... someone just needs to bake it into a viable standard and make it available as an off-the-shelf product, and it'll pretty much sell itself to police departments.
For trains, being early is arguably much, MUCH worse than being a little late, especially if you have to board at one of those intermediate stations. Passengers are annoyed if a train that's supposed to arrive at 5:15pm arrives at 6:30 and departs at 6:35, but they'll be enraged if the train they're supposed to catch at 5:15pm arrives at 4:57pm and departs at 5:04pm.
If your Ring doorbell gets stolen, they have a form you can submit to them along with a copy of the police report. Upon receiving the paperwork, they'll send you a free replacement doorbell and blacklist the one that was stolen.
https://support.ring.com/hc/en...
If you really want to get rid of CO2, just burn silane (a/k/a "Martian Coal") in it:
SiH4 + 2CO2 --> SiO2 + 2C + 2H2O
or, put another way... burn silane in a carbon dioxide atmosphere, and end up with quartz, carbon, and water.
Of course, getting the silane itself might create more CO2 than it actually locks up...
Hmmm... from what I remember from my last experiment (~4-5 years ago), the big pain points I ran into were:
* Heavyweight desktop environments like Gnome, Cinnamon, and KDE are dysfunctional when running on the remote Linux box. With Windows and RDP, the remote Windows just wraps up its event traffic & passes it along to the client copy of Windows to handle. With Linux, you can't do that. Even IF you're running the same desktop environment on both the remote and local PCs, there's no supported way to transparently have notifications and event traffic originating from the DE on the remote box get handed off and handled by the DE on the client PC that you're using directly. So you lose a huge chunk of functionality right off the top.
* There's no graceful way to run the window manager locally on the client PC while retaining the ability to interactively launch arbitrary programs on the remote PC as if you were simply connected to a remote Windows PC using Remote Desktop. If you want to run the entire remote DE inside a client-side window, the remote PC's window manager has to manage all rendering within that window. In contrast, when you use RDP, the remote PC transparently delegates all of its "window manager" type activities to the "window manager" (Windows itself) on the client PC.
* If you want to use the local PC's window manager to handle the actual rendering, you have to individually and explicitly set up each and every program on the remote Linux box that you want to run so that launching it "locally" spawns an instance of the X11 server on the client PC, connects via SSH to the remote PC, then launches the app and exports its window content to the local PC's X11 server. Meanwhile, even with the window content itself being rendered locally, you're going to end up with the equivalent of a broadcast storm every time anything generates an event (like notifications to the remote PC that the mouse pointer has entered something, is currently over something, has exited something, etc).
In other words, it's kind of like setting up VMware to run a guest operating system's apps inside native host operating system windows... but ENORMOUSLY less convenient, and with significantly worse performance (because every action generates a storm of events that would be inconsequential if you were just passing messages between threads on a single PC, but take an ENORMOUS amount of time and resources to pass and process when you have a network in the middle as your communication bus).
* Did I mention yet that just about everything woven into a heavyweight desktop environment itself is going to be dysfunctional unless you run the DE (and everything spawned from it) within a single window whose contents are managed ENTIRELY by the remote PC's window manager? Forget about casual, adhoc usage via remote X11... every single thing you do has to be deliberately planned and configured, app by app, before it will work.
The problem is, using a desktop environment like Gnome or KDE with Linux on a remotely-hosted server absolutely SUCKS. VNC is awful, and networked X11 somehow manages to be even WORSE. Graphical remote access is one area where Windows has a MASSIVE lead over Linux.
Linux literally has nothing remotely (pun intended) comparable to Windows-native RDP. Linux has "solutions" that can "use" RDP, but all they REALLY do is wrap RDP around VNC and use the minimal subset of RDP that shovels raw bitmaps around. They allow you to connect to a Linux host using "Remote Desktop" (or a RDP-compatible client), but they don't support any of the acceleration features that make RDP such a huge improvement over VNC.
Microsoft has done plenty of things wrong over the years, and fucked up a lot of things, but RDP is an example of a long-term vision they totally got right. You can even use it with a moderately-powered PC with a high-powered video card and get near-native performance with DirectX (because the GPU code IS running locally and natively).
Seriously. Take a computer running Windows 7 in full Aero Glass splendor, and connect to it over a gigabit LAN from a suitably-powerful client PC, and the fact that you're running remotely is practically academic. Even DirectX works, and takes full advantage of your local videocard's capabilities.
Now try that with Linux. Go ahead, just try doing 3840x2560@60fps with 24-bit color using VNC. Let's see just how unsustainable and unscalable VNC's approach really is:
3840w x 2560h x 24bits/frame x 60frames/second = ~14gbps. Ouch.
Just ONE 4k monitor at 60fps, and you've already blown past the bandwidth of 10gbps ethernet by more than 50% by the time you factor in overhead.
Even 30fps comes close to completely monopolizing and maxing out a 10gbps LAN, with almost no headroom to spare. And that's assuming the host PC can even HANDLE 30gbps+ transfers over the PCI bus (15gbps to read the framebuffer from the video card into system RAM, 15gbps to throw it right back at the network adapter with minimal handling) without saturating it or bringing the whole system to its knees. At that point, you might as well just buy a hub to let you use 10gbps ethernet as a Thunderbolt transport layer for DisplayPort and USB, since nothing else is going to be able to meaningfully use that "LAN" anyway. At least then, your computer won't waste half its performance just blindly shoveling gigabytes per second of bitmap data around over its own PCI Express bus.
And X11 can't even DO advanced graphic effects, let alone do them with acceptable performance. In my experience, X11 somehow ends up usually being SLOWER than VNC, even though X11 conceptually seems like it ought to be faster since it's technically NOT trying to shovel the entire frame buffer over the LAN for every single frame.
I speak from experience. This has been one of my pet fetishes for years, going all the way back to 1999. I burned almost a week trying (unsuccessfully) to get Enlightenment to work over networked X11 with full eyecandy, went to Comdex a few months later, met Enlightenment's developers, and was told point blank that it was hopeless... Enlightenment basically had to sink its hooks directly into the kernel and X11 to work its magic, and simply depended upon things that didn't exist in the actual spec for networked X11. About 10 years later, I got Gnome to run (in its entirety) over networked X11 for the first time... and the performance was actually worse than VNC. It's sad, but the best way I've found so far to get high-performance networked graphics with Linux has been to run Linux under VMware on a computer running Windows, then connect to that computer using RDP. And even then, it's a toss-up whether it's better or worse than VNC.
I had high hopes for Wayland a few years ago... until its team unequivocably announced that high-performance native-RDP-like networked graphics weren't just a "non-priority" for Wayland... they weren't on the table as a design goal AT ALL, not even
In Florida, the difference between 'annuals' and 'perennials' is ALREADY kind of academic, and has little to do with their official categorization. Just about ANYTHING left to grow in Florida will survive for years. To Floridian homeowners, the thing that REALLY distinguishes between 'annual' and 'perennial' is, "does it look good year-round, or does it get ugly and look like a weed after it stops blooming?"
Case in point: marigolds. Left to grow without human interference, marigolds in Florida will live for YEARS. But they only bloom for a few months per year, and in the meantime... they look like ugly, spindly weeds.
Ditto, for "grass". If you keep it mowed, it looks like... well... grass. If you leave it to go wild, you'll eventually end up with tufts that are taller than you are, with blades as wide as your arm.
Antarctica wouldn't have had to be all THAT much further north to have had trees... just far enough north, with enough additional continental landmass to the east and west, to put a portion of its northern coastline in contact with warm equatorial ocean currents, in a spot where the jet stream would dissipate much of the remaining warmth over land instead of ocean.
For a very, very rough analogy, imagine that you're sitting outside in the winter on a non-windy cold day. Someone fires up a small jet engine and aims its hot exhaust at you a few hundred feet away. You aren't likely to feel a LOT of warmth from it, but it'll probably be a net improvement over no heat at all. Now, put some big, powerful fans halfway between you and the heater, aimed perpendicular to the exhaust's airflow, and turn them on (or, alternatively, wait for the wind to start blowing perpendicular to the direction of the hot exhaust). Almost instantly, you'll feel colder, even if you don't feel the breeze directly, because the new perpendicular airflow brings the warm jet of air into contact with more cold air, allowing it to give up its heat before it reaches you. That's kind of what happens to Antarctica today... the ocean currents warm the air, then the intense winds south of 30-50 degrees latitude leach the warmth and distribute it over a large area long before it reaches Antarctica's coastline.
Yep, they totally fucked over everyone who bought a WMV/HD disc(*) back around 2006. Sometime around 2012, they shut down the DRM server, and all the discs became fucking useless and unplayable. And they didn't even have the goddamn decency to offer their WMV/HD victims refunds.
---
(*)WMV/HD was Microsoft's short-lived attempt to preempt and hijack BOTH HD-DVD and Blu-Ray by promoting a third format based on VC1 that would have enabled DVD manufacturers to cheaply add the ability to play back HD content from normal single and double-layer DVD media. Officially, Microsoft promoted it as a "connect your laptop to your new HDTV now, and buy a future WMV-HD DVD player later" standard, but there's still disagreement about whether Microsoft genuinely intended to hijack the future HD optical-disc standard, or whether they were just using it as a bargaining chip to force Sony's hand and get them to agree to make VC-1 one of Blu-Ray's mandatory supported codecs. Microsoft already had HD-DVD in the bag, but Blu-Ray's consortium balked until Microsoft agreed to let them bundle it in players for free and charge higher royalties per-disc. Ultimately, it was moot... VC-1 is superior to h.264 and MPEG-2 at lower bitrates, but it now costs more to pay the higher royalties and use VC-1 to allow your content to use a single-layer disc than it does to just use a higher bitrate with a cheaper codec and a dual-layer disc instead.
I think Amazon's motive is to come up with a way for a home theater amp, TV, media device, etc. to watermark its audio output in a way that tells a listening Alexa-implementing device, "don't be triggered by THIS SPECIFIC audio" (so every time someone on TV says, "Alexa" the device WON'T be triggered).
The catch is, the device needs a way to distinguish between "media audio" (that should NOT trigger it) and people in the room (who should ALWAYS be able to trigger it, even while watching a TV show or movie with the 'ignore me' watermark).
It has to be something that a device on the consumer end can add, because remastering a century's worth of media to add it at the content-producer's end just plain isn't going to happen.
Amazon is painfully aware of the "TV triggered Alexa" problem. It's not just annoying, it's a real potential vulnerability (mitigated mostly by the fact that buying radio & TV ads is both expensive & non-anonymous, so an ad that INTENTIONALLY tried to exploit it would get the advertiser sued). They don't want to just overlay a "dumb" "ignore everything for {n}ms" ultasonic tone burst, because THAT could be abused as well (say, by advertisers who wanted to prevent an Alexa-controlled device from accepting commands from ANYONE during the ad). So... it needs to be:
* specific to media being played in the presence of an Alexa-implementing device
* able to be injected at the consumer end, and something that could cheaply be added to something like a blu-ray player (ideally, lightweight enough to implement as a firmware update to existing players).
* NOT affect verbal commands from humans in the room.
Incidentally, I believe Amazon initially considered trying to use Cinavia for this purpose (since it's already present in many movies), but quickly realized it would cause more problems than it solved. Cinavia was designed to robustly (and indiscriminately) scream, "stop recording!", not "ahem... please don't attempt speech-recognition on THIS SPECIFIC audio". If Echo ignored 'Alexa' for {n} seconds after recognizing a Cinavia watermark, mere playback of Cinavia-watermarked content within listening range would effectively disable the use of 'Alexa' entirely for those {n} seconds. Ergo, Amazon had to come up with something better.
To wit, this is NOT about imposing DRM. It's about preventing media content from triggering the device by having someone on-screen say 'Alexa', by giving the device a way to distinguish BETWEEN media content and local users.
About 4 years ago, I dusted off an old Compaq Armada laptop (700MHz Pentium III, 512mb ram) and tried using it with a minimalist Linux distro. The performance of Chrome or Firefox with Amazon.com and Walmart.com was SLIGHTLY better than the performance of the same two web sites with my then-new Galaxy Note 4 (all using wifi, so the mobile network quality never entered into the equation).
The Pentium III is a great reference point, because its zenith (the 1.4GHz Pentium III Xeon) marked the point when Intel temporarily ran into a brick wall and spent the better part of a decade unable to meaningfully improve its single-thread performance. During that period, it was struggling to compete in ARM's home court, and ARM was scoring occasional victories. Compared to Intel's lower-end CPUs, like the Atom family (which, as I understand it, were basically just die-shrunk Celeron IV processors with power management bolted on, the same way the Pentium M family were basically die-shrunk Pentium III Xeons with power management bolted on), ARM looked fairly respectable.
Seriously, I challenge anyone to name ANY ARM-based CPU or SoC that satisfies the following requirements:
* Absolute single-thread performance as good as, or better than, an Intel i9 9900K or 9900KF
* Multi-thread performance as good as, or better than, an Intel i9 9900K[F], the only constraint being that all of the CPU cores have to be on the same slab of silicon inside the same packaged chip.
* The ARM chip has to be available in single quantities, to anyone with a valid credit card, with at most a 7-day lead time, for less than what it would cost our same hypothetical consumer with a credit card to purchase an i9 9900K[F].
* The ARM chip has to be usable in a system that a reasonably sophisticated end user (who nevertheless is NOT Linus Torvalds or doing it as a work-related project with the resources of his employer at his disposal) could install Windows or Linux upon and run normal software directly (emulation doesn't count).
Simply put, such a hypothetical ARM chip IS, in fact, hypothetical. It's fantasy. Even if you managed to solve the chip-availability problem, you'd literally have to be a company with the resources of Qualcomm or Samsung to get anywhere close to being capable of obtaining a genuinely i9-competitive chip and using it in a system capable of running Windows or Linux, because basically NOTHING in ARM-land is standardized. Everything near the highest-performance bleeding edge of ARM ends up being coture and proprietary, and without living at that razor's edge, you can forget about getting performance that's any better than what you'd get from a mediocre, middle-of-the-road x86/AMD64 solution.
ARM is for building cheap, disposable army ants and pack mules. Intel architecture is for building omnipotent combat robots capable of leveling the countryside while its AI ponders early 20th-century human philosophy and its structural contradictions. There's a huge gray area between the two extremes, but the fact is, if you want extreme performance at a halfway-sane price using off the shelf technology and products that aren't one-off custom prototypes, you have one real choice: x86/AMD64.
If you want a new laptop whose designers wished they could have made a sealed slab of translucent Lucite with 60 hour battery life... even if it's slow, and sucks heinously at running any kind of normal Windows or Linux desktop application... by all means, go ARM. If you want 90fps realtime raytracing for your Oculus Rift, pretty much ANY solution involving ARM-based COTS hardware is guaranteed to leave you disappointed for the conceivable future.
> How would Facebook monetize these poor people?
Poor people can be extraordinarily profitable if you have the resources, infrastructure, and warped moral compass required to aggressively exploit them. Poor people generally have few options and no bargaining power, so the fact that you're willing to do business with them puts you in an extraordinarily powerful position to dictate "take it or leave it" terms.
> ARM can be easily scaled to hundreds of cores
And yet, an Android phone with 8+ cores and nominal clock speed of 2GHz+ still can't render a Javascript-heavy web site (like Amazon, Walmart, or Sears) as well as a 15 year old 700MHz Pentium III.
> without having an astronomical price
Scale an ARM-based solution up to the point where it's capable of genuinely matching the performance of an i9, and you'll find that the ARM-based solution is probably quite a bit MORE expensive.
> without requiring a nuclear power station sitting on the desk
Compared to the power and cooling requirements of a Pentium IV with 15kRPM hard drive, an i9 with RTX and SSD is practically a laptop watt-wise. 20 years ago, I literally cut a hole in the wall between my computer room and the hallway so I could put my computer in the hall & pass the cables through the wall to get the heat and noise out of my face.
> 2) Cost of running the CPU in heat and power is *significantly* less than intel/amd
ONLY true when the ARM's performance is significantly less than Intel/AMD as well. Beef an ARM up to i9 specs, and it's going to burn as much power and throw off as much total heat AS an i9 with identical raw performance.
It's like LED lighting. A single LED might throw off light with just milliwatts of power... but crank it up so it's throwing off EXACTLY the same amount of light as a 100-watt halogen lightbulb (measured from every direction), with color fidelity that's at least as good as that 100-watt halogen bulb (none of this "80+ CRI" shit, or even "92+ CRI with weak R9"), and it's going to CONSUME at least 70-80 watts and throw off almost as much heat AS the original incandescent bulb. Because the only way to get deep, saturated reds without making the light appear 'pink' is to crank up the near-infrared output (which stimulates your 'long' cones, without bleeding into green/blue territory and desaturating it). And even if you settle for lower-quality light, the power consumption is no better than fluorescent bulbs, because a "white" LED basically IS a "fluorescent" bulb.
If you want the equivalent of an elderly personal servant or ten thousand army ants instead of a half-dozen deity-like level bosses, ARM might win over Intel/AMD64. Try to scale the army ants TOO much, and you end up wasting most of your effort just trying to keep them coordinated (the current bane of multithreaded programming).
Technically, GMT is NOT the same as UTC. There are actually three different standards... GMT, UTC, and TAI.
They differ because the precise length of an orbital & rotational year is neither 100% consistent nor predictable.
GMT is defined by solar noon at the Greenwich Observatory in London. If observation reveals that we've wobbled by a few milliseconds, GMT changes to reflect that. It sounds nice in theory, but 99.999% of use cases honestly don't give a fuck whether solar noon at Greenwich happens a few hundred milliseconds (or entire seconds) early or late.
TAI is kind of like Unix time, except it has much greater precision. It defines a second as a precise number of cesium-137 decay periods, a year as a precise number of seconds, and counts both as an offset from its starting point. TAI currently deviates from GMT by ~32 seconds.
UTC was envisioned as a compromise between GMT and TAI. It adds and removes seconds to ensure that UTC's noon falls within a half second of Greenwich solar noon. It's also a royal pain in the ass to deal with, because unlike TAI, UTC is a historical moving target. 9:47:42 July 18, 1997 UTC is NOT precisely 8 years before 9:47:42 July 18, 2005 UTC (even accounting for leap year gymnastics), because a couple of seconds were added as well
UTC makes a mess of things like timestamped logs, the same way DST does... but worse, because most people using UTC for timestamps are doing it PRECISELY to avoid the DST timestamp problem, and have no idea that "leap seconds" even EXIST until the first time they get burned by it.
UTC-vs-TAI was exacerbated by the sudden popularity of using internet time protocol (NTP) to automatically set clocks on computers. In the past, people set the time, and let it go until they manually updated it at their own convenience. Leap seconds were rare to begin with during that era, and a second or two gain or loss when the computer got rebooted was lost in the greater disruption of the reboot itself.
Fast forward to sometime around 2006, when UTC-via-NTP had become commonplace, and a leap second occurred, Linux computers all automatically observed it, and all hell broke loose when software that assumed that "UTC" behaved like TAI found itself with 2 seconds' worth of logged activity bearing the same timestamp (and often, undefined weirdness if computations involving milliseconds were involved on computers that did 64-bit timekeeping).
As I understand the "Linux" problem, programmers want TAI-like behavior, but POSIX compliance explicitly requires UTC... switching Linux to TAI would require changes to POSIX to allow timestamps to unambiguously indicate whether they're UTC or TAI, and the current 32-second difference is too big to just sweep under a rug and ignore. So instead, we have a complicated system where computers use NTP to sync up to TAI, then the OS converts TAI to UTC and adds/removes leap seconds before exposing it as the leap-second-mangled offset from midnight January 1, 1970 for consumption by programs that don't actually CARE about the precise moment of solar noon @ Greenwich.
The proposed solution is almost worse... ending leap seconds in UTC (to avoid rewriting POSIX & everything it dictates, causing YEARS of insidious bugs in the process), and inventing a FOURTH standard to do what UTC currently does & keep astronomers happy.
Compounding matters even more is disagreement about how to handle the leap seconds we already have. If UTC retroactively wipes them out, we're back to the problem of ambiguity with "UTC" timestamps between the 1980s and present... no way to indicate whether it's a "legacy" UTC timestamp or a "revised" one. If it doesn't, we'll still have to deal with those legacy timestamps in perpetuity.
The net result is that we're likely stuck with UTC and dealing with leap seconds in Linux for at least another decade or two. My guess is that POSIX will be left alone, UTC will eventually stop adding leap seconds (but leave the existing ones as-is), and they'll come up with a new standard for Astronomers to take the place of UTC.