You're suggesting that the retired, teenagers, stay-at-home parents, and college students make up the majority of the US working population? Yeah, not buying that one at all. The US economy is fucked right now, we've been madly spinning the plate to try to keep it going, but it's starting to wobble badly. Unless something major is done soon it's only a question of when not if things start to implode.
Our economy has become so overwhelmingly top heavy that the majority of the population is losing the ability to take part in it. The middle class used to be the mean income, but these days the mean has drifted so far from the mode that the distinction between middle class and lower class has all but vanished. Just taking a brief look at the 2014 census numbers, the mode income was centered around $22,000 a year while the mean was $75,000. Let that sink in. The largest percentage of the US population makes less than $25,000 a year.
It's interesting you mention graphics cards because that very behavior has lead to the gaming community favoring benchmarks derived from a handful of current gen games min/max/avg FPS over so called synthetic benchmarks. It only took a handful of instances of companies baking in "benchmark" modes that get triggered when certain benchmarks are detected for people to start discounting those benchmarks in favor of more organic measurements.
> Interestingly enough the local US-US flight seems to still have a lot of passengers on it (50ish%)
That's probably a mix of people with critical jobs needing to travel, people having to move for a variety of reasons, and people listening to the ignorant and ignoring the advice to social distance.
> This is utterly false thing that you learn if only read news articles. The value and quantity of manufacturing is now the highest it has ever been in the US.
I've seen it first hand. I've talked with people that have been impacted by it. I've also seen the corporate slight of hand that tries to disguise it. Components manufactured in China, shipped to Mexico for assembly, then shipped to the US to have some decorative panels and stickers slapped on so they can put a "made in USA" sticker on the side.
Go grab virtually anything from around your house (excluding food) and it's more likely than not that that thing was manufactured in whole or in part outside the US. That didn't used to be the case. Coming out of WW2 it was rare for people to own non-domestically produced goods.
This isn't a case of US manufacturing just being so ridiculously efficient that you just don't need many companies making things. That might hold water if most goods were still manufactured in the US, but they aren't. Cars are about the only manufactured consumer good still made in the US, and even they are quite often assembled in Mexico. Pretty much any electronic device is made in China.
Here's a case study, Ikea which is a very popular furniture manufacturer (among other things) mostly assembles their products in Mexico and China. They do have some US manufacturing, but that's largely because they acquired rights to some large swaths of woodland and it makes sense to process and assemble that on site.
To be clear, you mentioned agriculture, and yes, the US does have a thriving agriculture sector, but agriculture isn't manufacturing.
The US screwed up badly when it let basic manufacturing get outsourced. When the factories making screws and transistors are all based in other countries, eventually all the other factories are going to follow them.
The US industrial base was mighty, but these days it's a very pale shadow of what it was. Rampant cost cutting, outsourcing, and lack of protecting domestic production has absolutely devastated US manufacturing. There's still lots of design work that goes on, but almost all the actual manufacturing takes place elsewhere. What little is actually "made" in the US is almost entirely assembled from raw components that are themselves manufactured outside the US.
First a disclaimer, this is pure speculation on my part, but based on what others have said about github cracking down on sanctioned countries. I'm guessing they audited and found some accounts that belonged to people they suspected of being from sanctioned countries, and then went massively overboard and nuked any repo those users ever contributed to.
Anything sufficiently advanced to produce working code from vague design documents would be functionally indistinguishable from true AI. Barring some kind of major breakthrough in the field of AI (not machine learning, actual AI), this is basically a pipe dream. At best they'll produce something that given a very detailed and rigid set of instructions can produce a working program... which is exactly what a compiler does.
> A graveyard orbit sounds like it will be flying around up their indefinitely as high speed shrapnel. Does anyone know why they would choose this instead of destroying it on re-entry?
It sounds like there's confusion about that point. The article says that the plan says that they're going to de-orbit the satellite so it can burn up on reentry, and that it will be in a graveyard orbit, which are contradictory objectives to each other. It sounds like AT&T hasn't responded yet to clarify which of the two they actually meant.
Part of the problem is that "systems programming" is an overloaded term that means a number of different things. Is writing a web browser "systems programming"? What about a CLI utility like grep? Kernel module? Bare metal on a STM32? Depending on who you ask most of those will get both a yes and a no answer. On a related note, some language are more or less suitable for each of those. Can you write an OS in Java? Yes. Should you? Probably not.
I think one of the previous comments, and others on other forums have things right when they say that Rust is a better C++. Anything you would consider using C++ for is a good candidate for using Rust for. Rust is not a better C though, it's just a bit too high level for that. There are languages that are aiming to be a better C (Zig is REALLY interesting, but very very new right now), but Rust isn't really one of them.
I could very easily see something like an OS aimed at x86 desktops being written in Rust. Desktop systems are beefy enough and the problem space is complex enough that the extra overhead involved in Rust (similar to C++) makes sense. On the other hand if you're doing some bare metal work on something like an Arduino you just don't have enough there to justify the extra overhead and something very basic like C (or assembly, or Zig once it matures a bit more) is probably a better fit.
If you're doing anything higher level than kernel programming, Rust is just as viable as anything else, at that point it's mostly down to personal preference on whether you can deal with not having conveniences like garbage collection or not.
Your confusion is around where the end is in this case. E2E would be encryption from the ring device to your other device being used to view the feed (your cellphone for instance). Part of the difficulty in that case is getting the encryption key securely transferred between the two devices without exposing it to anyone else (a non-trivial problem). Assuming that was done in this case Ring employees would only have access to the encrypted videos with no access to the decryption keys to actually view them.
E2E Encryption is usually referenced in messaging applications where the ends are understood to be the two communicating parties, while in this scenario it's a little more nebulous.
The gaming market is in some ways on the trailing edge of technology. While they're often one of the first to embrace new hardware, they're very slow to adopt changes in software or architecture because the engines that drive most of that are few and tend to evolve slowly. Until Unreal Engine, Unity, or one of the other major game engines fully embrace an architecture that allows developers to easily saturate multiple cores, most games are still going to be bottlenecked by single core performance. On the other hand, it should be blatantly obvious to anyone even remotely connected with development that full multi-core utilization is the only way to keep improving performance going forward, so sooner or later the game engine developers are going to need to fully embrace that.
It's the corporate structure. The CEO either grows the year over year profits or he gets punished/fired by the board. Boards pick CEOs based on a history of delivering growth at any cost (this is one of the irrational decisions, they should prioritize long term growth over short term, but they rarely do). This in turn provides a strong incentive to CEOs to make bad long term decisions if it means short term gains, because they either won't be around to see the eventual collapse (having moved on to another CEO position) or else they take the long term plan and get fired by the board for not providing enough growth (or worse, reduction).
There's also elements of selection bias as well. If you're highly transparent it's likely that people who value that will be drawn to your product, so when you subsequently take steps to reduce that transparency somewhat (such as roping in a third party from an industry known to engage in shady things), and make it mandatory for users in the most intrusive way possible, it's likely to garner a bigger backlash than for a less transparent product because your user base cares about that sort of thing more.
Future is something that will eventually produce a value.
CompletableFuture is a Future that you can register a callback on for when it completes.
RunnableFuture I'm not completely sure on, but I'd guess it's a Future that will complete but won't produce a value (basically a Future<Void>).
ScheduledFuture is a Future that you can specify when it should run in the future.
ScheduleRunnableFuture is a RunnableFuture that has a defined time it should start running.
FutureTask is a RunnableFuture you can cancel. OK, so I cheated on this one, I didn't actually know what it was and had to look it up.
Edit: I looked up RunnableFuture and I was half right. It's something that's both a Runnable and a Future, so it has a run() method that causes the future to be evaluated but doesn't return its result at that time. It actually seems pretty niche and probably only useful if you already have some API that's expecting a Runnable, otherwise it's exactly equivalent to calling get() on a Future then ignoring the returned value.
The only difference between them and others is that they're plain in their language rather than obfuscating it behind lawyer speak. All providers have similar provisions hidden in their TOS, it's just buried behind layers of legalese and addendums. Personally although it might not look "professional" I wish more companies would use plain language that states what they actually mean plainly without forcing you to higher a lawyer to go through the TOS with a fine tooth comb.
It's a problem of delegation. Some executive "reads" some whitepaper (I.E. gets told about offhandedly by their buddy at the golf course), and thinks that it sounds like a great way to prove their "doing something" about moral or diversity or whatever. They then turn around and tell someone under them to "make it so", who does a tiny bit of research and then passes that off to someone under them. Eventually this arrives at someone with a clue who actually does some research and figures out this is an idiotic idea, but at that point you'd basically be telling your bosses bosses boss that he's a moron, so instead you just play along, get it done, and hope everyone forgets about it in a couple months.
I'm pretty sure that was the point he was trying to make. The excuse often made for why rental properties aren't allowed is that tenants are often noisy or cause other problems. He was just pointing out that that can be a problem for owners as well, so whether it's a tenant or a owner that's being noisy is immaterial.
Based on the technical specs $150, even with 12 games seems like price gouging. It's not too far off the Adafruit PyBadge someone else mentioned in another comment only that comes with a color LCD and more buttons for only $35 ($25 if you get the trimmed down version). Sure it doesn't come with a fancy case and it's missing an analog crank (really?), but there's literally hundreds of free games you could get for it that I'm willing to bet are as much fun or more than every single one of those 12 free games that Playdate will include.
Sorry, this looks like a overpriced gimmick. The digital equivalent of a pet rock, or a more modern (and far more expensive) take on a tomagotchi.
Seen similar and also used coding tests to good success. I myself don't have a 4 year degree (I got my 2 year, although truthfully I didn't learn anything new CS related when I got that degree), but I'm also an autodidact that was writing assembly programs by age 12, and OO perl/java before I graduated highschool.
The hard problem is finding a way to filter out fresh graduates (from either college or highschool) who can't code from those that can without having to slog through reams of poorly written coding tests in the process. For people who have been in the business a while it's a bit easier because you can usually take a look at their work history and the keywords they decide to use on their CV and intuitively get a reasonably good feel for where they are career wise. It's still very important to have them go through the code test as well though because CVs can be misleading and I'm still regularly amazed at people that come through with 10+ years of experience on paper who somehow still fail at basic programming tasks.
Ultimately I think tech recruiters may need to just step up their game. It's no longer sufficient to just play buzzword bingo to try to find candidates for a position, they need to actually have some amount of technical chops themselves in order to screen potential candidates. At the moment it seems like the industry standard is that recruiters function primarily as advertisers for open positions, while all the heavy lifting of actually evaluating candidates (of all levels) is ultimately left up to the devs at the hiring company.
I mean, how else are you going to write self-modifying code? It's kind of implicit in the name of the thing that it's going to need to at a minimum have write and exec permission, and read is kind of important to make sure you're actually modifying the right stuff. Yes it's a terrible idea to have write and execute permissions on the same piece of memory, but that's part of why literally the very first line of the article says it's a terrible idea to write self-mutating code.
Interestingly much of the (hobbyist) drone hardware also requires a Ham license to operate, so there's quite a bit of overlap there.
There are at least 3 distinct groups potentially impacted by this. First there are the non-commercial, "toy" users that are flying around cheap little "smart" drones using phones. Most of this class are using drones under 5" and that weigh negligible amounts. The second class are the non-commercial hobbyists that mostly build their own drones and use them either for recreational freestyle or racing. These drones can be anywhere from 3" all the way up to 12" on the extreme end, and similarly have a very wide weight and performance envelope. Much of the equipment in this class requires Ham licenses, or in some cases other federal licensing. Lastly there are the commercial operators that are mostly using drones for aerial photography. These tend to be medium to large sized drones (everything from 6" all the way to multiple foot wide monstrosities) which most definitely require FAA licenses to operate.
Part of the problem here, is that each of these groups has different expectations. Little Timmy getting the 4" plastic drone he flies with his iPhone for Christmas shouldn't really be required to pass a FAA license to fly it around his backyard. The professional across the street with access to the 5 foot wide 150 pound hexacopter with the gyrostabilized 4k camera mount and an effective range measured in miles probably should have some kind of license. The guy who built his own 5" drone out of parts and tools around the local park probably falls somewhere in the middle. Lumping all drones under one single set of regulations really isn't going to work because not all drones are the same. It would be like trying to cover unicycles, bicycles, segways, and motorcycles with a single set of regulations just because they all had less than four wheels and required you to balance on them.
If it was just censorship maybe, but this is also trying to tax them on essentially all content they link to. No way is google taking this one sitting down, if it actually goes into effect expect first google, then probably others (Facebook almost certainly) to slap blanket bans on all of EU with a nice little landing page helpfully explaining exactly what everyone should complain about to their local EU representative.
You're wrong about the interaction model. When you install the client on your phone and pair it with a computer (via QR code) it generates a ssh key. You then need to import the public key into your github (or gitlab etc.) account same as you normally would. Once that's done on the client side there's a SSH plugin that is registered that intercepts the authentication request and pings the krypton server to sign your commit with the private key on your phone (the server relays the signing request to your phone via push notification). Assuming you approve everything on your phone the result is unwound back to your ssh client which finishes the handshake with the server and authorizes you based on the public key you had previously uploaded.
In this particular case it's all about Windows not having a decent SSH client. There's PuTTY... and uh... PuTTY. Oh, and you can sort of maybe run OpenSSH through LSFW or Cygwin, or maybe msys, but those all have some serious gotchas associated with them. Basically it boils down to, there's no standard Windows SSH client, and the ones that are available all have a laundry list of gotchas and problems, and that's without even bringing in the various git clients into consideration. OS X and Linux are low hanging fruit, they both come out of the box with a standard and well supported SSH clients.
I've been using it for about a year now. Works very well. Only gotcha is that it doesn't really have support for Windows (it's on the issue tracker, but progress has been slow). If you do your work on OS X or Linux you're fine, but if you're a Windows user you're in for a bumpy ride.
You also can't discount the (depressingly) massive number of people who believe that climate change is a hoax/conspiracy by… someone (used to be China was the favorite boogeyman, but not sure who they're blaming now)… to do something or other that would in some fashion hurt the USA. It may very well be that people are buying out there under the assumption that nothing is going to change at all and that all the flooding is either just a fluke, or else won't ever get any worse than it currently is.
Any system sufficiently complex to replace programming is indistinguishable from a poorly written and designed programming language. It's the same broken thought process that leads to business rules engines which themselves always end up being maintained by a specialized programming team. You can't magic away the skills and requirements that necessitate a programmer, you can merely make the programmers job easier or harder.