The concept of waste-heat-to-power (WHP) exists, but its efficiency is limited by thermodynamics.
Basically, heat energy is not equal to usable energy. All energy ultimately wants to be heat energy, and it is much easier and more efficient to go from electrical or mechanical energy to heat than vice-versa. Therefore, when you do have an application that actually wants heat, not electricity, such as a public swimming pool or district heating, it is way more efficient to use your waste heat as heat. Even in cases where the desired temperature is wildly different from that of your waste heat, you can convert one heat level into another very efficiently using heat pumps.
We are no longer in the era of FOSS where contributions are purely motivated by either scratching your own itch, altruism or curiosity. Haven't been for over a decade, since that's how long companies have been checking out applicants' GitHub pages during hiring.
These people are farming contributions to major FOSS projects as a form of CV-padding. The same is happening with vulnerability reports. The sloppers may genuinely think they're helping out, or they may know their 'contributions' are a net negative for the projects, in the end it doesn't matter much. When you're motivated by direct economical incentives and your situation is precarious enough (in today's labor market, it is), externalities are not high on your list of concerns.
FWIW, debian did the gentoo approach for years. I used to run debian with OpenRC during a time when systemd was already the default. It and other init systems remained fully supported by the distro for quite a while.
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.
Besides Romanians, there are several more eastern european romance-language-speaking peoples ("Vlachs") like Aromanians, Megleno-Romanians and Istro-Romanians. I think they might also deserve a mention.
We are saying the same things, just expressing them in different terms. Yes, only idempotent methods and "safe" POST requests don't need preflight. And I'm saying you need to make sure in your server implementation that those are actually safe. The article states that the CORS header will prevent random other websites from talking to localhost at all, which is just wrong.
Even TFA seemingly doesn't understand CORS. Or at least misreprents it grossly:
> The webserver listening in on localhost:19421 should implement a REST API and set a Access-Control-Allow-Origin header with the value https://zoom.us. This will ensure that only Javascript running on the zoom.us domain can talk to the localhost webserver.
No, that does not do that. JavaScript from any other website can still talk to localhost:19421 just the same. CORS doesn't restrict anything, it loosens the default set of restrictions (ignoring preflight requests for now and assuming we're talking just about "safe" Methods). That Access-Control-Allow-Origin header just allows JavaScript running on zoom.us to read the responses when it queries localhost:19421. The requests happen in any case, and you must ensure in your backend that they don't cause any adverse effects.
Well, is this mad dash for AI producing "outcomes that are beneficial for society at large" yet? So far it looks like its mostly producing a ton of negative externalities and wealth transfer to corrupt elites.
Also, no, abandoning ethics is not an option, what a ridiculous suggestion.
We would not be able to agree on that. Already today, some of the people who would actually be able to unplug some of them (Anthropic) are worrying about "model welfare". I think you are not putting together how much of an anti-human death cult this is.
> WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way?
FWIW, that's exactly what they shipped first, with WASI preview 1 (wasip1). You can still use this today, and all runtimes with any level of WASI support will be able to run it.
Most of the points listed are hardly considered lispy anymore these days, Python also has most of these.
Where Ruby's lisp lineage really shows is the fact that it's got Kernel#callcc, aka call with current continuation. It doesn't get any lispier than that!
It's a bit of in-group signaling but I think, importantly, also date signaling. A 2026 hype website looks different from a 2020 hype website looks different from a 2010 hype website. Having a generic 2026 hype website look tells visitors that you're either new or update your website's design to follow current trends.
They do the same with cars, where it's even more important and even more explicit. The design language has to change every couple years so that you can tell when somebody is driving a car older than 5 or so years. For example, currently we're doing blobs but with a few sharp features and muted colors. Before that it was more colorful and more metallic paint. Before that, in the 00s, it was pure blobs. Before that it was all sharp edges etc. Now sharp edges are beginning to make a comeback.
That's why I don't think we'll ever have the "one true design language". Fads and trends will continue, repeating themselves to a degree but also changing in new ways.
No. We have an infinitely more succinct formalism, it's Turing machines. Succinctness is not necessarily a desirable property, it just says where on the capability-tractability tradeoff something is. Turing machines can express literally anything computable, but in exchange we can't use computers to reason about them in general (Rice's Theorem). Regexes are much more limited, they famously can't even recognize HTML, but we get to automatically prove things about them.