On this particular front Europe is doing OK as well, but it definitely needs to build more, faster, and now. And to do that it needs to build more ties with China. Honestly looking at the (lack of) EU response over the latest US war crimes I’m not holding my breath here.

Felipe VI of Spain can (constitutionally) do the funniest thing right now.

That said, everyone on this planet needs to be building renewables, grid storage, bike lanes and railways ASAP to shake off oil dependency.

I think the correct term is not “insisted on provoking” but “started”. Dropping bombs on primary schools and city centers is not a provocation, it is an act of aggressive criminal war

Man vs reeducation camp guards

If you’re ok with a little piracy, this exists: https://f-droid.org/en/packages/com.dd3boh.outertune

And then you can also buy your favorite albums/songs on bandcamp to actually support the artists!

Soo, they piped a probabilistic token predictor straight into a root console of a customer-facing service, and it only caused an outage twice so far? They should consider themselves lucky.

Here is translation from HR speak to English:

“fast-paced” - requirements change multiple times during each sprint

“exciting” - your manager will be an idiot

To expand on the other comment, Luddites were not necessarily against technological progress. Rather they used destruction of certain types of machinery as a political tool: to temporarily extend their power as skilled laborers, and to intimidate the factory owners into recognizing their unions or getting certain laws passed. Most Luddites were not against technological progress in general.

They’re writing a new package manager/build system and bootloader. So I guess mostly NIH, which is totally fine by me.

Abstraction, when used well, is actually a tool that produces more simple code in the long run. It separates different concerns into different pieces of code, makes code readable by extracting common logic and giving it a recognizable name, and reduces boilerplate.

That said, OOP-style inheritance-based abstractions, while useful in some cases, quite often lead people down the complete opposite path - mushing together unrelated logic and then making call sites difficult to understand with a lot of hidden state that has to be kept in mind.

BTW Guix+Hurd, a fully GNU OS, has been around for quite a while now: https://guix.gnu.org/en/blog/2020/a-hello-world-virtual-machine-running-the-hurd. You can even run it on real hardware: https://guix.gnu.org/blog/2024/hurd-on-thinkpad/

Oh my, I hope she knows how to sed the release name in /etc/apt, or else it’s very out of date by now…

Hm, you should clue me in. I thought the Planck length being the “minimum” unit of length was more to do with particles with a short wavelength to be comparable to a Planck length would need to have so much energy that they will become black holes, which means it’s not really feasible to investigate anything “happening” at scales smaller than that. So to me it doesn’t feel particularly relevant to the uncertainty principle. But it’s been a long time since my physics courses, so I might be missing some obvious connection.

I’m glad to hear you’re getting help! Hope you pull through this. I think myself and others are really wishing the best for you, please don’t be offended.

As for your physics theory & code though, I must repeat what others are saying. Stop using LLMs (be it copilot or gemini), they are clouding your thoughts and blurring any original ideas you may have into an incoherent sloppy mess.

Scrap your repo, clear your mind, start over. Don’t have many expectations, most (I’d guess 99%) of amateur physics theories out there turn out to be wrong.

Open a markdown document in a simple editor and write down your ideas, by yourself, with no stupid computer program telling you what to think.

Then take a pen and paper and try to distill your ideas into mathematical formulae, with no stupid computer program (which doesn’t have any real mathematical knowledge or rigor) making up bogus equations.

Then, using that same pen and paper, try to work through a few examples of applying those formulae to specific physical situations. Start simple, don’t try to reproduce the entire universe at all scales at once, maybe start with a finite universe containing a couple of electrons and see how their interactions play out. Don’t let a stupid computer program (which can’t even perform basic arithmetic by itself) make grave mistakes.

If it seems like the model works for a couple very simple examples, try to put it into code. Don’t use Rust or GPUs or even scipy for your first prototype, just write it in pure python. And for the love of all that is good, don’t use LLMs for this either. Just take your formulae from your piece of paper and translate it into python by hand, with no stupid computer program (which can’t even count the number of R’s in a word strawberry) stealing code from others and writing boilerplate instead of describing your original ideas.

Don’t worry about performance for a prototype, if the results it produces are at least interesting, you can worry about optimizations later.

The high level idea (uncertainty principle looks like we’re on a grid, which feels familiar to programmers) is fine, that’s a common and pretty solid argument for living in a simulation.

Is that actually true? AFAIR the uncertainty principle is just a natural outcome of the position being a matter wave, and the momentum being a Fourier transform of that wave; and if a wave is “localized” at one point, its Fourier transform will be “dispersed” (and vice versa, due to the Fourier inverse theorem). A good, but vastly simplified analogy is that it’s impossible to precisely define the audio frequency of a single sharp clap.

There’s nothing “simulation grid” about that, because a Fourier transform applies to continuous-domain and continuous-variable functions.

Harsh, but might be best to heed this advice. You can’t resolve trauma and relationship issues by inventing a physics theory, even if it was correct (which it probably isn’t).

Rust does not have exceptions. You never have to try/catch. Functions usually encode the possible failures in their types, so you’d have something like this C++ snippet:

struct HttpError {
  std::string message;
  int responseCode;
}

struct FsError {
  std::string message;
}

typedef std::variant<HttpError, IoError> FileDownloadError;

std::variant<std::filesystem::path, FileDownloadError> downloadFile(std::string url) { /* ... */ }

And then the caller of downloadFile has to decide what to do if it returns an error:

auto res = std::visit(overloaded {
	[](FileDownloadError e) { /* ignore error, or handle it somehow, and return a new path */ },
	[](std::filesystem::path p) { return p; }
}, downloadFile(url));

/* res is guaranteed to be a valid std::filesystem::path, you don't have to care about errors from downloadFile anymore */

However, Rust makes this whole thing a lot easier, by providing syntax sugar, and there are helper libraries that reduce the boilerplate. You usually end up with something like

#[derive(Error, Debug)]
enum FileDownloadError {
  #[error("HTTP request failed")]
  HttpError(http::status::StatusCode),
  #[error("Filesystem error: {0}")
  FSError(#[from] std::io::Error),
}

fn download_file(String url) -> Result<Path, FileDownloadError> {/* ... */}

(notice the #[from], which forwards the error message etc from the std::io::Error type)

The Result type is kind of like a std::variant with two template arguments, and, mostly by convention, the first one denotes the successful execution, while the second one is the error type. Result has a bunch of methods defined on it that help you with error handling.

Consumer code is something like this:

let res : Path = download_file(url).unwrap_or_else(|e| {
  /* Ignore the error or handle it. You have to return a new path here */
});

/* res is guaranteed to be a valid Path, you don't have to care about errors from download_file anymore */

Or

let res : Path = download_file(url)?;

/* res is guaranteed to be a valid Path, you don't have to care about errors from download_file anymore */

Which will just forward the error to your caller (but your function has to return Result as well), or proceed with the execution if the function succeeded.

Finally, download_file(url).unwrap() is if you can neither ignore, nor handle, nor pass the error to the caller. It will abort if the function fails in any way, and there’s no (practical) way to catch that abort.

It’s worse than just exceptions in C++. There’s (almost) no way for the caller of your function to catch it. It’s a bit like this snippet:

std::optional<int> foo = <...>;
try {
  return foo.value();
} catch(const std::bad_optional_access& e) {
  std::cout << e.what() << std::endl;
  abort();
}

It’s the abort that is the crux of the issue here. Usually you would pass the std::optional up/down the call stack. If you don’t control the types (e.g. using a library or a framework) you’d come up with some “default” value instead, like this:

std::optional<int> foo = <...>;
return foo.value_or(123);

Or in Rust:

let foo : Option<i32> = <...>;
return foo.unwrap_or(123);

But sometimes there’s no good “default” value, and then you have to resort to just unwrap-ing the value, and accepting that the entire program will abort when that function call fails. Usually this is a sign of poor engineering somewhere, likely in a library you’re using, and should be fixed; but sometimes you don’t have the time to fix it, and then it ends up in production.

BTW this is also the case for most network printers. You can just print to them by sending a pdf/postscript file with netcat. CUPS is rarely needed nowadays.

In my experience:

1. All printers are pain. This is a sad fact of computers.
2. If it detects&gets recognized in CUPS, you can usually fiddle with it and make it work eventually.
3. If it works on one distro, there will be some way to hack it enough for it to work on all distros.