lima

Contrary to popular opinion, Nix builds aren't reproducible: https://luj.fr/blog/is-nixos-truly-reproducible.html

For development, "localhost" has a convenience bonus: it has special treatment in browsers. Many browser APIs like Service Workers are only available on pages with a valid WebPKI cert, except for localhost.

On my Linux machine with systemd-resolved, this even works out the box:

  $ resolvectl query foo.localhost
  foo.localhost: 127.0.0.1                       -- link: lo
                 ::1                             -- link: lo

Another benefit is being able to block CSRF using the reverse proxy.

They can do that, yet somehow, Gemini Assistant on Pixel phones still fails to reliably set timers or add shopping list items :-)

(which worked fine with Google Assistant)

One of the best things about Gerrit - besides stacking and turn-by-turn review - is how it emphasizes good commit messages by making them part of the process.

Each commit becomes one "unit of review", and the commit message can be reviewed just like the code changes.

The real answer here is downloading a tarball generated from a tag - those are generated by the GitHub backend.

Not sure what kind of answer you are looking for? I did not criticize the author's post. It was an enjoyable read, and I personally would have given up a long time before going to such impressive lenghts. The fact that the app isn't using certificate pinning is really interesting and the sheer amount of hacker spirit and determination is extremely wholesome.

I am, however, very familiar with this particular engineering challenge (specifically, attempting to build on pfSense and using mitmproxy scripts in production), so I wanted to share my personal experiences to hopefully save someone else some time and frustration while attempting the same thing.

Should I not have commented at all?

A small C++/Go/... proxy can do the same thing with much, much less overhead. Been there, done that - for something well-defined like this, it is more stable and less work than fighting mitmproxy.

Routing everything through the proxy will degrade performance even with SNI interception.

Same with pfSense - a plain Linux server and a simple iptables rules set would do the job without having to fight against all the pfSense abstraction layers.

Write a .proto file with just enough of the reverse-engineered proto fields to auto-generate code and flip the flag. Cheaper than the Python implementation and easier to update when the proto changes.

Ignoring unknown field tags is an important Protobuf feature - it allows for compatible schema changes without breaking existing deployments.

It's impossible to read this without an awful lot of scrolling, even zoomed out...

Worse security posture (it took decades to even catch up with Chrome w.r.t. sandboxing).

Doesn't want to implement useful standards which I use in my own applications (filesystem API, WebSerial, WebUSB...).

The researchers found undocumented hardware functionality which allows someone who already has code execution a greater-than-expected degree of low-level access to the ESP32 wifi stack.

Calling this a "backdoor" is just pure clickbait.

Chrome's list of transparency logs. The actual CT logs are operated by multiple parties, including Google.

CF's announcements are quite fragmented/deaggregated due to traffic engineering. Here's a much shorter list of the actual IP blocks: https://www.cloudflare.com/ips/

It can make things worse: Ghostscript is not particularly safe to run on untrusted/potentially malicious input. It has a giant attack surface and no proper mitigations, unlike the PDF reader in your browser.

At a minimum, you'd have to sandbox it using something like gVisor.

Depends, it might take a very long time.

That would permanently destroy the yellow ink path.

For most modern inkjet printers, there's a simple reason: there must be ink inside the printhead at all times[1] or some of the nozzles will dry out and clog.

[1]: https://superuser.com/questions/409473/how-to-print-in-black...

The ID they use is from a US government database: https://nssdc.gsfc.nasa.gov/nmc/spacecraft/display.action?id...

I'm not sure if it was the lack of trajectories or the unusual orbit which caused the automation issue at MPC.

It's being tracked, but not by the "Minor Planet Center".

This is more or less how Phabricator (dead, but lives on as Phorge[1]) works. It uploads/downloads patches via HTTP.

IMO, using Git remotes but with a one-review-unit-per-commit approach like Gerrit has a much better UX. Shipping around diffs has all sorts of sharp edges, especially when you stack multiple changes or binary data, and you end up reinventing native Git functionality but worse.

Phabricator started out as "paste your diff here" and eventually ended up with a CLI tool that reinvented half of the Git CLI.

[1]: https://we.phorge.it

> What I haven't seen at a quick glance is the ability to link to any place in the document (sink) from withing the document itself (source).

You can create an anchor:

    (my-anchor)=

...and then link to it:

    [see here](#my-anchor)

(https://mystmd.org/guide/cross-references)

Quarto rendering is quite slow compared to Myst. It is more focused on R Markdown and Observable JS.

It doesn't handle these either - what stops the user from entering their password on an attacker-controlled phishing page?

Passkeys work because the user can't be tricked into entering their private key on a phishing website.

It's not quite as bad, your average user with an iPhone or Android phone will be fine. Just scan a QR code on the Windows machine and log in with the phone.

The problem is that the UX for this is extra super confusing, and people will end up with passkeys that aren't backed up anywhere and get locked out of their accounts.

In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing fundamentally wrong with the approach.

I guess you're talking about the relative vs. absolute import paths?

This solves it: https://github.com/cpcloud/protoletariat

No. It doesn't apply to either case ("leitende Angestellte" are exempt).

The headline is a bit sensationalized: the article focuses exclusively on small SaaS exits, which are usually done by selling assets, NOT the whole company. In Germany, these sales are treated like any other business income.

If you're aiming for a normal exit - where you actually sell the company - things are much more favorable.

You need to set up a holding company, which is usually a UG. This is easy and cheap: there is a simplified process for it ("Musterprotokoll"), and it requires no upfront capital like a GmbH. As of recently, it can be done online without having to visit a notary in person. The overhead is negligible.

Once the holding sells its subsidiary ("share deal"), in most cases, the effective tax rate at the holding level is only ~5% due to § 8b KStG. This is not bad at all, since you'll want to reinvest most of the money anyways.

There are gotchas in every jurisdiction, and you need to get professional advice by a local accountant. Germany is a fine place to run a business. If you already live here and don't want to move your family for tax reasons, you don't have to.

You can get it reimbursed in some cases.

Many teams use topics for this.