muvlon

I'm in Europe, the sky here is literally red at night from fires we are failing to extinguish. France, Spain, UK, Belgium, Germany, Croatia, Serbia are all going through this to different degrees right now.

Meanwhile, Latin a and Cyrillic а, which look identical, have the same origin and are often pronounced identically too, get separate codepoints. CJK unification was not based on any clear preestablished principles but simply an attempt to cling to 16-bit codepoints, Asian languages be damned.

> explanation of how byte-level access to memory objects is done in other languages.

I'm not pjmlp but I can explain this for the case of Rust, where this works a bit like C but with a few interesting differences.

Mainly, in Rust there is not a concept of a "memory object" per se in the runtime semantics. Memory is made of allocations and allocations are made of bytes. Unlike C, bytes are guaranteed to be 8 bits in size. Every byte of memory can hold integer values (0x00 to 0xff), pieces of a pointer or be uninitialized. That means there is nothing like strict aliasing, and therefore no need to have special rules for byte-level access. You can alias any type as any other type, so long as you avoid all the other sources of UB (out-of-bounds access, uninitialized memory access etc.).

The way to practically access this is much the same as in C. You can do things like cast pointers between different types and project a pointer to a struct to a pointer to one of its fields. It should be noted that, unlike with major C implementations, structs do not have a stable, well-defined layout, so if you do manual pointer math you need to put #[repr(C)] on the struct to get C layout rules (which might still yield platform-dependent field offsets, e.g. size_t is not the same size everywhere).

Note also that these are the dynamic rules of Rust, you need to follow these when writing unsafe code to avoid UB. The static rules of safe Rust are much more restrictive and don't allow much at all. It is possible to write unsafe code that exposes safe abstractions for this, one example is the "bytemuck" crate. It provides macros that can parse a type definition to check certain properties (e.g. well-defined layout, no padding) and then provide you with safe functions for byte-level access. Since there is no strict aliasing, for certain types you can also get safe functions for access at other granularities. For example:

  #[repr(C)] struct Foo {
    x: u32,
    y: u16,
    z: u16
  }

can be safely accessed as an array of u32 values (uint32_t in C), but

  #[repr(C)] struct Bar {
    x1: u16,
    x2: u16,
    y: u16,
    z: u16
  }

can not, for alignment reasons.

Huh, I actually think it's the opposite. Classic Linux distros like debian are much more like Lisp, everything is the same big mutable pile of state and you query and edit it from within the system itself. The REPL is just your shell. It's very live and interactive and a bit scary at times.

NixOS by contrast takes the entire Linux userland and makes it an immutable, dead compiler artifact. So it is to debian like C or Rust are to Lisp.

They're supplements, not medication, but I've seen crazy variation in the dosages of Vitamin D pills.

It's for building extremely backend-brained frontend stuff, like a sort of anti-NextJS. Also like NextJS, this sort of domain-bending has some unfortunate operational consequences.

That being said, x86_64 has supported 128-bit atomic writes via cmpxchg16b for over a decade. Modern 64-bit ARM has several ways to do them as well.

Probably still not widespread enough for OpenJDK to unconditionally assume it's supported, but I think we're getting there. (Is there "caniuse" for CPU features?)

Yeah, all the common lispers I know are all about interacting with "live" programs as opposed to "dead", compiled ones. Nix takes the last live, mutable, reflectable part of the world of programmers today, the OS itself, and turns it into a dead program as well. So common lispers tend to hate Nix with a passion (as do Smalltalk users).

Yes. Once you're in such a comfortable position that you'll keep making lots of cash regardless of whether you do well or not, there is little incentive to make good decisions, let alone take risks. This is known as the "curse of Oil" and is also what Intel's decline is attributed to.

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

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.

That's a completely different person, they (ludic and smileplease) just both happen to be publishing on mataroa.blog. This is a blogging website anybody can sign up for, basically Medium but for nerds.

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.

Oh they exist all over the place. Pix is just unique in its success. It has only been around for ~5 years and it's completely taken over the country.

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.

Is it an error though? The general public has noticed, everyone hates their guts but investment is still flowing.

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.

Already a thing between UTC and TAI.

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.

And to Moby music! What's not to love?

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.

Yes, exactly. Black hole mergers are the one thing exempt from the Eddington Limit, because there is no friction there.

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.

The line would look the exact same if you switched it to price per PB. Only the labels on the y-axis would change.

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.