One small piece of nuance here is that a lot of the times they're not selling your email address, they're hashing it and using it as an identifier for targeting on other sites (so that two sites that both have your email address can coordinate to sell you ads, but sites that don't already have your email address don't learn anything new).
Which parts of the UK Civil Service would you say are more competent / effective in your personal experience? From the outside (US) perspective it's hard to see it as anything except the same-old bureaucracy and crazy rules that make it impossible to have any positive impact in America. (For example, the UK rules for getting a passport basically make it impossible to find somebody to countersign your application unless you happen to know a lot of lawyers / doctors professionally)
If your work isn't being adequately acknowledged and appreciated, that's a major culture problem. I've never felt that my code reviews were thankless. In fact, as I've become a more senior developer on the team, I've found that my code reviews or suggestions can sometimes crowd out acknowledgment for more junior members, so I try to redirect praise where appropriate—code reviews are in my mind the most pure expression of pair programming, where you get a collaborative outcome that's better than either the programmer or the reviewer would be able to achieve independently.
"In the playoffs you don't tell your star player to stop shooting and pass more" yes, you absolutely do? if the players are making their shots but having a hard time getting open or dealing with defenders then more passing can definitely be the right solution.
If your company isn't budgeting/estimating development effort appropriately, then it's going to affect a lot more things then just code reviews: writing good planning documents, adding tests, Q&A, fixing bugs, design polish, small touches, etc. are all going to suffer if the organization is broken in this way.
Is it? I think it's important to understand that this type of robotics research requires serious ethical considerations no matter where it happens or who works on it—this work specifically was funded by the US military, but it applies just as equally to weaponization projects happening within China.
I can't really speak for many other institutions. I know plenty of robotics labs that are doing completely civilian work under NSF grants, grants from corporations, some civilian manufacturing and automation work through the national labs, etc. And even among those institutions working on DARPA-funded projects, not every institution has NREC right down the street working on autonomy systems for ground combat vehicles: https://www.nrec.ri.cmu.edu/solutions/defense/other-projects.... The research done by students at CMU directly makes these types of weapons platforms possible, and vice versa.
It's certainly true that many, many universities are deeply embedded with the DoD, defense contractors, and other weapons manufacturer ecosystems. Certainly CMU isn't exceptional here. But I think it's very important to keep in mind the reality of these programs when they come up in the news, like this article, which is why I left the link to how "the other side" sees these types of research programs.
The problems being related to the backup generators make me think about the current Freefall arc (written by a nuclear engineer, even), which focuses in part on a unethical space station manager who is skimping on maintenance regimes to create a temporary life-support failure (requiring the use of backup generators) that would trigger the automatic reallocation of unused manufacturing robots from a nearby in-orbit factory to bolster his workforce and lower his labor costs (storyline starting around ... here http://freefall.purrsia.com/ff3800/fc03702.htm, although prior to that are a few fun strips about procurement bureaucracy)
As a reminder: CMU and its robotics program is intimately associated with the US Department of Defense, and although there are certainly civilian applications for this technology, one of the most likely short-term applications is improving legged drones for battlefield deployment (often, it should be said, in humanitarian roles, including search and rescue, or support roles, such as ammo, food, and water resupply, but deployment of armed legged drones is also an active area of research).
Plenty of browsers allow self-signed certs—Firefox and Safari, to the best of my knowledge, treat HTTP/3 certs exactly the same as they treat HTTP/2 and HTTP/1.1 certs. Chrome has taken the position that it will no longer allow self-signed Root CAs for HTTP/3 websites, to prevent SSL interception with companies intercepting all of your traffic. For personal use, you can always whitelist an individual certificate using a CLI flag without allowing a trusted root CA
"Mozilla.social is currently available to a closed beta group as we experiment, gain input from participants, learn, and improve the experience. Eventually we hope to build a safe, well-organized space within Mastodon that is open to all audiences."
The examples GP gave were java-specific, but the concept of codegen meaning "deterministic generation of code in a 'compile' phase" is universal—think of OpenAPI libraries, Go pre-generics, Babel, etc.
OP said that they did this with a first-gen kindle, and I would not be surprised if it had an always-on wifi connection and was processing data much more frequently then you suggest. I agree that there are plenty of ways to build this in a power-efficient way, I just want to suggest that given modern battery controllers, heat is a much more likely cause of failure then keeping the kindle plugged in all the time.
This happens all the time at traditional finance firms also. For example, last May an investor in the Nordic region sold off hundreds of thousands of shares of an index fund leading to an 8% drop in dozens of stocks https://www.bloomberg.com/opinion/articles/2022-05-03/citi-d...
Obviously when you frame it like this it sounds insane, but the fact of the matter is that responding to support tickets and triaging bugs have a real, hard cost in $$$ spent. If supporting Linux platforms doubles your time spent responding to support requests and triaging tickets—even if you never fix an additional bug, it could very well be enough to entirely tank the profitability of adding Linux support, well above the value that any additional minor bugs they find might bring.
> I think the point being made is that the fact that a user has rksh as their shell means nothing to samba, ftp, some features of ssh, httpd, cron, and etc
Which has been true for...... 30 years? If not longer?
not stronger isolation between different flight plans? it seems "obvious" to me that if one flight plan is causing a bug in the handling logic, the system should be able to recover by continuing with the next flight plan and flagging the error to operators to impact that flight only
In what sense are the Bun.* APIs "proprietary"? They're open source, no? If you want to port them to another language, it would be completely possible to.
You're getting confused between the words "Analog" and "Analogue".
Analogue: something that is similar or comparable to something else either in general or in some specific detail : something that is [analogous] to something else
Analog: of, relating to, or being a mechanism or device in which information is represented by continuously variable physical quantities
GP's comment has nothing to do with whether the simulation is "analog" (as opposed to digital), their point is that instead of being a "model" of a way a physical system might behave, the mechanism in this case has the exact same physical properties represented in a different form. An example might be doing a calculation in decimal vs doing it in binary—the exact steps you take will look different, and the answer might look strange, but there's absolutely no doubt about the fact that you'll get the same answer however you happen to compute it. Another synonym for the word "analogue" in the sense that the GP is using it might be "isomorphism"—you can prove that some transformation holds, and then you can do whatever you want to the transformed version and know that the results you get can be "transformed back" to the original form and reinterpreted.
Google Calendar does, at least. It even supports representing events that being and end in different timezones (like a plane flight or a cross country trip)
You say that "IP addresses + timestamps can be tracked to a subscriber"—how do you account for the existence of TOR and no-log proxies like Proton VPN? If you were law enforcement, how would you track those IPs to a unique subscriber?
"I can only presume there is a limit on song length for albums,"
Definitely not, I have plenty of real songs in my Spotify library that are an hour long or longer. My guess is that it has more to do with how Spotify calculates artist payouts and that white noise "creators" found that they could get 20x the number of views if they split all of their tracks up into 3 minute chunks.
"prohibiting future uploads while redirecting the audience towards comparable programming that was more economical for Spotify" — this sounds like Spotify generating the white noise on device or partnering with an app that does so, which seems like a much better use of resources then letting users upload thousands of GB of machine generated audio per week streamed to hundreds of thousands of viewers. I don't think there's much indication at all that the goal is stopping people from listening to white noise and forcing them to listen to other podcasts. And i don't necessarily think they'd be wrong in assessing that this is a very poor use of bandwidth costs, or wrong in thinking that it's one that significantly changed the marginal economics of the platform (auto generated white noise can be uploaded in bulk by computers with no human involvement compared to the time it takes to create even the most bare bones podcast episode, and one "episode" of white noise is indistinguishable from a another for most users, leaving Spotify holding the bag for thousands of hours of back catalog that may never get listened to)