Denormals therefore count as underflow and strtod() sets ERANGE for them, even though they they are legitimate values to store as strings and parse back.

Some implementations of strtod() return the correct floating-point value for these, while setting ERANGE. Others discard the value and return 0.0, preventing them from being round-tripped to strings.

Almost everywhere outside the US, Canada and New Zealand.

I read that article, and I didn't notice anything that stands out as different from markdown-mode (the non Tree Sitter version).

Regular markdown-mode also highlights everything, hides markup if you like, cycles section visibility if you like, fills paragraphs in bullets, etc. With poly-markdown-mode it also does language-specific syntax highlighting in code blocks, and even language-specific structural editing, automatic indentation, etc. With math-preview it displays TeX/LaTeX math as rendered formulae.

(Though Markdown's inability to nest Markdown inside HTML elements is a terrible default. HTML semantic elements containing marked up text is basically how I write documentation to myself, and obviously the right way to mix plain text-like markup with named, extensible annotations beyond the default syntax.)

I think most of the friction comes because you have to keep converting free text with bold, italics, headings, etc. between the two, costing time when you're moving notes, documentation, README.mds, code comments nowadays in Markdown, etc. back and forth between the two. That creates a dilemma: Should I write README.org or README.md in my personal project? Should I write Org notes about my work to help me track of WIP and notes that might become documentation, or Markdown blocks inside Org, or Markdown notes? What if I'm collaborating with others, or think I might in future? What about collaborating with LLMs?

It's just enough friction that I ended up avoiding Org for organising my work, even though I like the idea in principle and use Emacs all the time.

Linux runs very well in a VM on macOS. There are many good options for this, some free and open source (QEMU, UTM, Lima, Colima), some proprietary (VMware Fusion, Parallels).

But Linux in a VM doesn't get access to the real GPU, so model performance is limited. Those running on the CPU perform well, and those needing the GPU don't.

However, macOS on M-series macs is excellent for local models. (Maybe not as excellent as a box full of the best nVidia GPUs, but still excellent).

So if you're getting Apple hardware, like Linux, and want to run all of it locally, a fine setup for a machine to run local models, with agentic characteristics:

- macOS running one of the many local model runners. I used to use Ollama and Whisper, and now use llama.cpp instead of Ollama. Others use LM Studio, oMLX, etc. Provide HTTP endpoints to access the models.

- Linux in a VM for overall control and orchestration, with standard VM settings, and bridged networking so it appears as its own machine on your network. Also, in here provide a robust shared file server for shared state. Use this VM as your desktop and primary access to the machine, if you like Linux.

- Linux in a VM to launch ephemeral, volatile containers, with the containers using a memory-only tmpfs overlay on top of a read-only Linux filesystem in a VM disk image, with tools in this filesystem. Alternatively, a writable Linux filesystem in a VM disk image, with disk buffering set to use macOS host buffering and discard fsync requests. These settings optimise for container disk performance for data that's only ephemeral which will be deleted soon or on system shutdown. (You can combined both VMs, but need to use two VM disks to get equivalent behaviour, and be careful about VM disk configuration of the two disks.)

- Containers spawned within that second Linux VM can be spawned very quickly and run quickly, so are ideal for LLM agents that need a quick sandbox. These sandboxes generally run faster than a macOS sandbox, despite being on the same machine with VM overhead, because Linux is faster at some things. Teach the LLMs to store files and memories they want to keep in the shared file server.

Sometimes they do. From Gemini 3, some AppleScript:

  if something then
    if something then
      if something then
        stuff
      end if
    end if
  

After about 10 turns the problem went away.

See the sibling thread parallel to yours, https://news.ycombinator.com/item?id=49329791

Democrats have a track record that speaks to them being more fiscally responsible than GOP, in spite of the rhetorical narrative.

You can't assume anything about the next crew. Past performance is no guarantee of future results. But if you're predicting fiscal responsibility, past performance favours the Democrats.

It"s actually SQL "ite" as in rocks, minerals and fossils. Their version control system is called "Fossil".

Company A publishes invention 1, when they know inventions 2, 3, 4 follow naturally in their own roadmap but those things aren't obvious to other people yet. Invention 1 is just a stepping stone in company A's larger vision, and it's not useful by itself, but they can't publish (or patent) everything at once, it takes time to develop them. It's also not permitted to patent 4 inventions in one patent. There are time, expense and R&D factors.

Company B studies invention 1, realises invention 2 follows naturally (as does everyone who looks at invention 1), and company B patents invention 2 before anyone else.

They can do this because inventions 2, 3, 4 are not obvious to persons skilled in the art who haven't seen invention 1. They are only obvious to anyone who works with invention 1.

The standard is not "if you knew about invention 1, would 2 be an obvious next step", it's "would 2 be obvious with general industry knowledge alone".

When that happens company A is stuck, whether they patented invention 1 or just published and/or used it.

With their prior art, they can continue to use invention 1, even if they didn't patent it, but it's not much use by itself. They can't develop it further in the directions they'd had in mind all along. And sometimes company B's patent and company A's prior art will mean company A can continue to use invention 1 but nobody else can.

A defensive strategy is for company A to patent invention 1, even if they hate patents, just so that company B can't use invention 1 when they need it in invention 2. This doesn't stop company B from patenting invention 2 before company A, by the way. It just creates leverage for company A to persuade company B to license invention 2, instead of company A having to abandon its entire roadmap and switch to a different kind of product.

> I's only your right to exclude others from it that gives a patent any defense... it's all about exclusivity

Yes, but not all companies want to exclude. Some even want to share their work openly as they proceed. But even sharing openly and creating prior art as you go is not safe.

The natural line of development they have mapped out can be shut down by others seeing the way ahead and blocking it, which is a strategy, as I said, that I have seen discussed in real patent lawyer meetings.

For those companies, "what is the point of a patent if not to enforce the right of exclusivity it grants" -> the point is not to enforce exclusivity over anyone, because they don't want to. It's to use the granted rights as defensive leverage so they can continue developing, publishing and using their own work.

When you launch the Emacs editor, you're loading an Emacs Lisp image that was populated at build time by running Lisp code, with the resident Lisp definitions "dumped" to make an image file.

The image file used to actually be the `emacs` executable you'd run, using a clever but non-portable mechanism called `unexec` to make an executable.

But as of version 27.1 (in 2020), the image file is separate from the executable for portability reasons.

Usually it's to defend against another company using a "blocking patent" by pursuing you for infringing their patent which is built upon the thing you patented, doing the next step which was always obvious to you.

So that you can continue building what you started in the first place, instead of being shut down while someone else takes your idea forward.

Not for exclusivity.

> My guess is that's a fake one.

I've seen fake Apple chargers in local shops recently, with complete Apple packaging, "made by Apple in California" etc. and only detectable by close inspection of the details, specs not matching any Apple product, device info reported electronically that doesn't match any Apple specs, and the tiny inset writing not making sense when looked at under magnification. So that sounds plausible to me.

I didn't have time to fix it so downloading the binary module has been the only option.

I had the same problem with vterm when I first tried it. The C module failed to compile, with a compiler error about a line in the source. As there was no downloadable binary module I fixed that one.

This isn't about opinions. Very large political financing is not a mere opinion. It has a much larger material effect.

I don't think it's possible to separate "mission of our company" from "large scale political financing", for purely structural reasons.

I think the legal and fiduciary concept of Conflict of Interest is relevant here, but perhaps only by analogy. https://en.wikipedia.org/wiki/Conflict_of_interest is quite informative.

In some business, political and legal roles, we deem certain structural relations to be a conflict of interest regardless of what people on those roles actually do..

The mere potential for excessive improper influence arising from the structure of their relationships and roles is what creates the deemed conflict.

As the owners of a company making substantial profit like Mullvad, you always had the potential capability to financially influence political outcomes on a scale which most your customers cannot, in ways that may seriously harm some of your customers and to be potentially against the stated mission of your company.

I think the relationship between running a company with an openly advertised public mission, or even an implied mission in the minds of customers, while in another role (wealthy private citizen) being able to make a substantial material action against the same mission, should be recognised as inherently a conflict of interest. But obviously it's one we can't avoid, as long as we allow people to get rich from a mission-driven company.

What we can do, is recognise that if someone actually takes a large material action against the company's mission, then they have gone a step further and demonstrated the conflict of interest.

We generally favour free speech, including political donations. But when the money for very large political financing comes mostly from customers who, by virtue of the advertising and marketing of the company's mission, are led to believe they are supporting the company's mission?

In my view, at that point the customers are being tricked into paying for something while their money is paying for something else which opposes the thing they thought they were funding.

At the least, it should be dealt with in a similar way that conflicts of interest are dealt with when, for example, directing multiple companies: By making sure everyone knows, so other people are able to consent or not on the major conflict issues those other people might have a view on. The analogy for customers is their consent shown by their informed decision to become or remain customers.

In Mullvad's situation, that would mean Mullvad should explain to customers, embedded clearly within it's public marketing of the company missions and values, that one of its current major owners receiving customer funds by way of profit, is the main financier of a political party which sponsors remigration in Sweden. Because that is clearly a thing some customers care about when evaluating whether to pay for Mullvad's services from now on. You know that, I know that, so there's no legitimate excuse for not letting customers who would care know.

Then, as you said, customers will be free to choose.

Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.

Mobile phone as WiFi access point is another common way people access the net nowadays. I've occasionally seen permanent installations, with a phone taped to a window. I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.

I really enjoyed programming in Nim professionally, and got to know it well. But I've literally never seen a job ad which mentions Nim since then, except at the company I already left (Status), so that's not really an option.

After realising there's no work in it, I struggled to justify using Nim in new projects including personal projects, even though I like the language.

If anyone's reading this and looking to hire someone who knows (or rather, knew) Nim well enough to do quite advanced work in it and doesn't need training, please do drop me a line :-)

Alternatives to VMware can run VMware VMs almost immediately, by translating the configuration and with only a few (or sometimes no) changes to the guest. Usually those changes are scriptable. I've done it a few times, moving between VMware and KVM of Windows guests pretty much just worked; the rest was optimisation, i.e. guest driver changes, etc.

Live migration is not realistic between different hypervisors, but a very short downtime per VM is realistic if the new hypervisor can adopt the old disk images directly, which some can. If you want, you can convert formats in the background while the VM is running on the new hypervisor. E.g. KVM and things built on KVM can do all these things.

So to each guest, it looks like a quick reboot with a quick hardware upgrade.

If that's coordinated properly, with a generic HA or Kubernetes setup, there's absolutely zero service downtime (if there are no serious mistakes), as it's just nodes within a cluster taken down one at a time while the others keep the services running, and state migrates among the nodes which are live.

Most of the things you'll change when migrating are the same for large numbers of VMs that are configured the same way except for their disk images, and easily minor things like MAC/IP. So after you've verified a small number, you can go right ahead and script the migrations for another thousand VMs, even doing them in parallel.

You don't need to migrate all VMs at the same time, and you shouldn't do that anyway. So the temporary hardware / cloud cost can be in the low single-digit percentage (for a few weeks to months at 40k VM scale, a few hours to days at 10 VM scale). You probably have some slack in there already, though, so might not need any additional hardware.

Although the code worked on Win32, and works on most modern C compilers, it's not guaranteed to work on modern C compilers, especially with aggressive optimisation turned on.

cgroups v1 might be the most irritating, because it was useful and something a shipped application or service might realistically use.

Wrong, misleading and possibly FUD. Yes you can ship GPL licensed software with your application, even a proprietary, closed source application.

You have to comply with the GPL terms, but that's easy to do for every library or auxiliary program that you'd link to or call in a Linux distro.

The GPL is designed to support this use case, with it's "mere aggregation" clause making it clear that it's allowed.

The one thing you can't do if you're shipping a closed source application is link to GPL-licensed code (unless there's an special exception clause, or it's LGPL, or it's dual-licensed to allow this). But for this type of GPL library, you can't use the Linux distro's shipped version either. So the GPL constraint makes no difference to the question of whether you can ship a frozen or fallback version with your application in lieu of the distro version.

If there's a corner case the above doesn't cover, I'm not aware of it and I've studied GPL compliance more thoroughly than most people. So I'd like to know about it :-)