I suspect that whatever replaces Linux will probably involve a paradigm shift at the lowest level. Perhaps capability-based IPC, perhaps seamlessly integrating local and networked nodes, etc. It’s going to take major major improvements to move the world off of the Linux kernel.
While true, I wonder what fraction of those automobiles are used to get into the areas below Central Park on a regular basis. I've always had a romantic idea of making all the surface streets below 96th street between 2nd Ave and 10th Ave bus/taxi only, perhaps with special zones for residents to own cars, and repurposing large swaths as pedestrian/greenspace... But it's an unlikely dream.
Title is misleading, it’s still a desktop app but will probably use electron (so “technically” a web app, I suppose) but title implies a fundamental change in functionality/usability on Mac which is not happening.
It’s the intention. Intention is really important in the US legal system; killing someone on purpose is murder but by accident is manslaughter, even if the result is the same. Same goes for finance; failing to do something you intended to do is one thing, but lying to investors and the public that you’re doing it even though you secretly are not is another. And so we punish the second because there was an intent to defraud investors, even if the investors were foolish too.
In a lot of ways, the field has already come to this conclusion. At NeurIPS this year some of the biggest topics in Deep RL were model-based RL and meta-learning for RL, both of which aim to learn a generalized representation of an environment that can be used in a variety of downstream tasks.
Just a minor technicality, it’s not that Bob travelled faster than the speed of light, it’s that the distance between you and Bob increased faster than the speed of light. Nothing can travel FTL through space, but space itself can be made smaller or larger.
You’d probably lose a lot of the advantages because you lose the naturally extremely effective radiation shielding of the earths magnetic field and atmosphere.
It's almost certainly the carriers imposing this restriction. The reason these features took so long is because, as they did for SMS, every single carrier across the world has to get on board with this. , so I'm sure that's the reason it's not encrypted. The Messages app might be a Google product, but the underlying transport has to be implemented by carriers, and I'm sure there are many, many carriers who aren't interested in encrypting the messages that are carried across their networks (either because they don't have the technical competency, they want the data for themselves, or they have to comply with local law enforcement regulations about texting).
This is not to excuse the lack of encryption, but the finger should probably be pointed more at carriers (and maybe OEMs) than at Google.
One question I have is whether Google-account to Google-account messages will be encrypted, like how Apple does it with their iMessage/SMS boundary within the same app...
From what I have heard, the toolchain story is being worked on heavily. There are some legacy reasons why toolchains were designed the way they were (mostly due to the fact that Google essentially only uses one compiler for each language, and certain toolchains were implemented natively instead of as plugins), but the confusing semantics are improving! Maybe give it another shot in 6-12 months.
This is a simplistic view. When push comes to shove, companies don't behave with political principles. Apple is not going to throw away access to 1/6 of world's population over a political dispute. It's unrealistic to expect any company to, if they're sufficiently large. The only way to achieve political goals is to apply political pressure directly at the state level, or to work with domestic movements that seek to undermine the policies in question.
The major difference here is the economies of scale. When you have a centralized facility, you can afford to invest in expensive, high-throughput machinery because you make up for those investments with volume. However, centralizing necessitates some distribution costs, which in the case of many foods imposes some harsh constraints on ingredients and quality; there’s a reason those pizzas are all frozen, and don’t reaaaaaallly taste all that fresh. If the cost of these small-scale production robots drops low enough (achieved through smarter control rather than high-precision parts), you can remove the ingredient constraints and make a better product while capturing savings of automation.
At FAANG companies, it's not unheard of for new SWE grads to command $200k+ starting compensation. For someone with 5 years experience at the company it would actually be unusual for them to make less than $200k, in the US at least.
This resource is pretty accurate for the lower levels, in my experience: https://www.levels.fyi/
Data might pass through many different hands between collection and submission the the FDA. I can totally imagine a clinical trial where one lab tech enters some results into an Excel spreadsheet, and that sheet gets emailed to another person, and that sheet gets modified in some way, on and on. There aren’t a ton of guarantees you can make about how accurate the data is once it makes it to submission, so I could see some sort of hashing/blockchain tech being mandated within an organization to certify results.
This seems to be a fairly obvious finding, doesn’t it? Any change in business practices that gives you a competitive advantage gives you, well, a competitive advantage!
The study seems to say: if your company automates jobs away, you’ll actually create jobs in the long run because you’ll be able to take over competitors’ market share! But I don’t think those jobs are of the same type as the ones eliminated - probably trading manual labor for strategy/marketing/engineering, which is not much consolation to current manual workers at your firm.
Also, the study neglects to mention industry-wide effects. Maybe one tech-savvy company can grow its headcount even after automating a bunch of jobs away, but given the heavy headcount losses sustained by competitors, will it still be a net increase in the industry? I would suspect not.
The coverage and accuracy of the information provided by the MTA APIs is poor, in my experience. Additionally it doesn’t take into account crowding or any of the other quality-of-trip components (i.e. closed elevators, altered service, etc.).
Typically when you buy a large fraction of a cow, the butcher will process it into a bunch of different cuts, I.e. ribeye, flank, chuck, tenderloin, etc. the cuts are usually single-serving, except if you want to keep the tenderloin whole or something. You also get a bunch of hamburger patties or ground beef. Point is, you get all the meat pre-cut before your freeze, so you can use only what you need at any given time.
Java is a fine language, and the JVM is a powerful environment that enables some really cool things - Kotlin and Scala prime among them. That said, I wouldn’t be surprised if we are past peak Java/JVM in terms of new projects and developer mindshare. Java was an excellent tool for a world where ecosystems were rather self-contained, lots of code had to be written in-house, and source code distribution platforms and good tooling for cross-language development weren’t nearly as prevalent. A developer could basically do everything they needed in Java, unless they needed super-performant code, in which case they’d drop to C/C++.
The proliferation of great new languages, stellar package managers, and comprehensive tooling have reduced the need for a single, do-it-all language. Now, there are a wide variety of languages that are better fit for specific domains (I.e. Go is very good for small services, python is good for data science and prototyping, rust is good for system programming, typescript is good for Frontend, etc), and the barrier to entry for all of those languages in a professional environment is lowering (if not already low). To me, this means that the next generation of developers will be versed in several of these more domain-specific languages, rather than spend their career working with a single language. Java may well be one of these languages, but I see a possibility that it will gradually fade out of mainstream greenfield development. Of course, the world is now built on the JVM so it will stay for a very long time, but maybe not for new projects.
1500 (out of 1600) on the SAT, 4.0 out of 4.0 grade point average (GPA), took 12 Advanced Placement (AP) courses, akin to foundational college-level courses, while in high school. Generally just getting the highest possible marks on every typical academic metric.
From my (admittedly limited) experience with Qt, it’s an extremely powerful framework with a somewhat-steep learning curve. Dead-simple apps are dead-simple, but there’s a lot of Qt-specific stuff (I.e. QML, control paradigm, extensive libraries, etc.) that you need to learn in order to get the full value out of it. That said, it’s still a great cross-platform option, and the fact that it has bindings in most popular languages and is extremely performant (if you write it properly....) means that it’s probably worthwhile if you need to make a desktop application.