moosingin3space

I've got a pc-engines apu2c4. It's a great little x86_64 PC with 3 Intel NICs. I used to use it as my primary router, and today I'm using it as a development platform for a custom router OS based on Fedora.

There's also the espressobin, which is an AArch64 board with 2 NICs, one attached to a Topaz switch. The espressobin has mainline Linux support, which is awesome.

Meson, btw.

webcompat.com

Contrary to popular HN memes, most Rust developers aren't zealots.

My guess is the raw identifiers syntax introduced in Rust 2018 (`r#` prefix) will handle this.

I agree with your second paragraph. The Librem 5 isn't just a "Linux phone", and Purism is trying to build an ecosystem with strong expectations of privacy and end-user control, which is something we don't have today.

If all you want is a "Linux phone", you could buy a PinePhone for $150 or work on porting postmarketOS to an Android phone. The Librem 5 clearly has higher ambitions and could prove to be a more mass-market product.

Can't reply to the sibling, so replying here. Mozilla used to work that way (upload patch to Bugzilla), but it was so cumbersome they switched to Phabricator.

> 100% of the appeal for this phone is that you'll be able to run GNU/X11 on it.

I just got rid of X11 from all my desktop PCs, no way in hell I'm using that pile of shit on a phone.

Also, it appeals to be because it's a phone that will support mainline Linux, NXP has been willing to support their products for longer terms than Qualcomm, puts the user firmly in the drivers' seat, and is being designed for eventual mainstream appeal.

Could this not be done though the dependency system itself, if it were sufficiently generic?

> WAPM operates synchronously at the moment, but there is no reason why WAPM should not be able to install dependencies concurrently.

I'm sorry, I didn't word that well. In Fedora, there is a feature called Modularity that enables you to switch between different release streams (for instance, Node.js LTS or current). You can do so with `dnf module install nodejs:11` or `dnf module install nodejs:10`. Since `dnf` is installing into a single global space, though, it isn't possible to install both nodejs:11 and nodejs:10, and the Fedora project recommends containers as a solution here. Could WAPM support this use case, without requiring one to buy into the entire container tooling ecosystem?

> no lifecycle scripts

Yes! This could enable a declarative OCI image build tool, which could be used to bridge the gap between Wasmer and the Docker/Kubernetes stack.

> How else do you build native modules

It is my understanding that wasmer is trying to create a new ecosystem that doesn't rely on native modules.

> run initial post-installation configuration scripts

It's been my experience, as a long-time Linux user, that this is actually a bad thing. Stateless systems are far easier to work with -- a package manager can be far faster and simpler if it just extracts an archive. I can't think of a single case where post-installation configuration scripts couldn't be replaced by something simpler, using the filesystem.

I love WebAssembly/WASI, but I'm concerned about us repeating the mistakes of the past.

How does the dependency model work? Can I safely install parallel streams of software? Does it support unprivileged installation? Is the installation stateless (no scriptlets/lifecycle scripts)?

Another fix could be to use Hyper with tokio-tls. Under the hood, that package uses Windows schannel, macOS SecureTransport, and a dynamically-linked openssl on everything else.

This is my extension: https://addons.mozilla.org/en-US/firefox/addon/workspaces-fo...

It's a Sublime Text-inspired navigation tool for Firefox. I use it to jump around between tabs on different workspaces or different monitors. (Yes, I know the default keybinding is bad. I'm going to change that in the post-refactor version.)

My plans are to refactor it for the new Svelte, then improve the fuzzy search, and possibly go cross-browser.

Very happy for this. I wrote a Firefox extension with Svelte v1, and will take this release of Svelte v3 as an opportunity to refactor my extension.

Thank you, contributors!

The really nice thing about Svelte is that it treeshakes really well. I wrote a Firefox extension with Svelte (v1), and when Svelte v3 becomes stable I will be very excited to upgrade.

This is a rather tasteless joke.

How does DoT avoid this issue? IIRC, DoT runs over port 853, which is trivial to block.

The behaviour depends on a few preferences:

* network.trr.mode can be set to 0 (disabled), 1 (race native vs TRR), 2 (TRR first, OS DNS as fallback), 3 (TRR only), 4 (run native and TRR in parallel but use native results, save TRR timings for telemetry), or 5 (off by choice)

* network.trr.uri configures which DoH endpoint is queried

Firefox does maintain a DNS cache, even if you use the native DNS resolver. You can view the cache at about:networking#dns.

Cloudflare 1.1.1.1 is the default.

Why exactly does HN always accuse Rust-related posts of astroturfing? This is completely bizarre to me.

This is probably true, but it would be incredibly cool to see a research project that demonstrates this.

Also, one very nice benefit this has is that balenaOS has safe, automatic updating of the base system.

The key thing you're missing is recruitment. White supremacists need access to the larger platforms in order to recruit new adherents to their bigoted ideology, which is significantly harder to do if they're forced into "underground" spaces. De-platforming works -- if we make it clear that hateful ideology isn't tolerated in large platforms, then people have to actively seek out such ideologies. If such ideologies are already frowned upon in the public sphere, it makes their recruitment much more difficult.

I disagree -- with traditional VMs, you have to deal with multiple mutable systems. In the Docker/OCI container world, containers are immutable, so you can manage all your changes atomically, from a single source of truth (your Dockerfile collection).

I agree about Yum as of RHEL7, but dnf/yum4 are actually quite good in my experience.

I agree that developer experience is paramount. I've actively made choices to choose tooling with better developer experience (Rust and Elixir over C++ and Erlang, for instance), and Podman will need to have Debian/Ubuntu packages eventually. If you're on Fedora, openSUSE, or RHEL, though, Podman is a yum/dnf/zypper install away and works quite well (better than Docker in my experience wrt SELinux issues).

OBS is so good, Fedora (my distro of choice) has a clone of it called Copr: https://copr.fedorainfracloud.org/

Podman and Buildah have registry push/pull built in, so technically you don't need Skopeo except in CI. (Honestly I'm still a little unsure what Skopeo's ideal use case is.) Podman also has a `build` subcommand that takes a Dockerfile, so I'd argue if you're on a development workstation where you only use Dockerfiles to build containers, all you need is Podman. (Buildah supports more interesting build pipelines that can be driven without a Dockerfile.)

There are examples of very efficient IPC, just not in UNIX-land. If your IPC system is integrated with the scheduler, the difference between a dynamic library call and IPC can be minimized into irrelevance.