HN user

muvlon

930 karma
Posts0
Comments102
View on HN
No posts found.

In many deployments, Wordpress started out as just a blog that is easy to edit right from the web browser, but then grew into way more. Most commonly, people end up retrofitting all kinds of e-commerce features onto it, and that's how you really get into the whole plugin mess. At that point, for better or worse, the Wordpress instance is serving important business needs that are not addressed by a static page.

I've definitely realized this in a couple of markets: Buy cheap, get trash. Buy expensive, get expensive trash with better marketing. Working with power tools from various brands has made me realize they all cheap out in the same ways. Plastic gears where there used to be metal, undersized motor drivers that fry themselves under sustained load, trigger switches that start misbehaving or die completely after a few months.

Also, all of the brands (cheap or expensive) will sometimes mess up the cost-cutting and make something reliable by accident. Buying cheap gives me more chances to get lucky in this way.

Interesting that you'd mention Brazil. I consider it one of the very few examples of countries successfully replacing PayPal with a publicly owned service. Pix is ubiquitous in Brazil and has been for years. It has not only displaced PayPal but also cash and (in large parts) Visa/MasterCard, even in the face of US tariff threats.

Why? Because their messaging is not addressing the general public, but their investors. And they've realized that their investors are really receptive to panic-baiting (we'll get rid of jobs, ASI is right around the corner, p(doom) = 25% etc).

There is deliberate randomness in stockfish. The easiest way to see this is from the fact that, when playing the white pieces, it won't play the same opening move every time. Often it's e5, but it also goes for e4 or Nf3 or something else entirely.

This is by design, and very much necessary for a competitive chess engine. Otherwise, people could do basically what you say: Run an offline (as in, ahead of time, with ample compute resources) search against stockfish that finds a line where it loses, then make an engine that plays that every time.

As a consequence, even if you know that your opponent is running stockfish, you can't really use that against them. Your best bet is also just running stockfish.

Ah yes, the thing wrong with AI is how it won't help you kill your wife.

I didn't check the author first so I was about to go "why the hell is this on the front page?" but oh well. geohot being geohot.

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.

No, a classic GR black hole does not have its own magnetic field. It can have electric charge, along with mass and spin, but that's it.

There is a somewhat fringe alternative idea called a MECO, which can have a magnetic field. Unlike some of the other fringe black hole alternatives, this one at least produces falsifiable predictions.

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.

- electricity (from solar, hydro, nuclear, whatever). maintained by robots.

- it is repaired by robots using resources mined or reclaimed by robots.

- you guessed it, robots.

- robots with weapons.

If we actually want to prevent this doomsday scenario, I don't think it's wise to bet on "robots will never be able to do X".

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.