yjftsjthsd-h

there were enough things you couldn't get on streaming, so getting the discs was important to fill those gaps.

That's true today, Netflix just misses those gaps outright now.

Depends. Either you need to guard against e.g. fingerprinting the GPU, in which case you still need a separate machine, or you only need simple separation of cookies and the like, in which case you never needed that and could just use separate browser profiles. But yeah, I think in the latter case containers should work, though if it matters you should double check what exactly they do and don't separate.

and when that inevitably fails

This assumption is doing a lot of work. Surely the question was precisely why it would fail?

That feels like a plugin or external program, not configuration

I stand by the statement. Modern browsers typically do not include all that functionality. For instance, consider... well, as you say - Firefox supposedly was the cut down version that didn't include all that stuff. If Mozilla wants to make seamonkey a major part of their product suite, I'd be basically on board with that, but that thing's niche.

No, it's still a weird scope creep. Browsers can view a lot of things (HTML document, various pictures, sounds, videos), but they don't typically include editing functionality.

Arch linux aarch64 port is not a fork, it uses the same upstream PKGBUILD which contains minimal aarch64

I was under the impression that that's what ALARM was. And that seems supported by https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/R... (and the small number of packages in that repo). Was I mistaken?

In a space where names include git, mercurial, fossil, and jujutsu? I think it's fine.

So it's mostly intended to be a better replacement for whisper? Mostly? With better support for more models and maybe acceleration backends?

100% is from those 4 clouds?

Battery packs are meant to address one of the most common things I hear from new Rust adopters. Everyone loves the wealth of high-quality crates available on crates.io. And everyone hates having to spend a bunch of time researching and comparing alternatives.

[...]

One of the key ideas from battery packs is that anybody can publish one.

So now we get to research and compare alternative battery packs? I guess it could help if there's fewer of them, but I don't see why that would be.

devices randomly disconnect for hours even when they are 2ft from the coordinator

I don't think that's normal. Like, to the point where I'm wondering if you have a bad opinion of the whole protocol because you got a faulty device.

The Linux syscall ABI is (famously) stable; on x86* you can still call into 0x80 just fine. There might be new interfaces made available, but existing programs shouldn't break. Although, in C there could be value in abstracting over the per-platform differences like int/syscall. I've only ever done raw syscalls from assembly where portability was rather moot:)

Huh. So it's not the window manager. It's individual applications that are working or not.

Working: tile, dwm, pcmanfm-qt, feh, dmenu, glass

Not: alacritty, st

So... Thus far, anything but a terminal other than glass. I'd think the problem was alacritty doing fancy things with APIs that frame doesn't have, but st??

I am loving the shift from 'X11 is too big and messy to ever reimplement' to 'there are multiple wildly different X servers being built from scratch'.

Also, has anyone run it successfully? I got as far as building and running with --display and then running `DISPLAY=:7 dwm` and `DISPLAY=:7 alacritty`, but I can't seem to focus the window to actually type. Given that the author posted a picture of the thing actually running a live environment and claims to actually be using it, I'm pretty sure this is a me problem but I haven't been able to figure out where it is. Mouse works, too.

At a glance, that looks like an X client library, not an X server?

The bars, in fact, don't grow as you scroll. And I don't even see why they should.

On my device, they grow as I scroll to them.

We've never used the term custom ROM since it isn't accurate and propagates misconceptions. It's best to avoid it.

It's a ROM (in the phone sense), and it's not stock (so installing it is a customization). In what way is it not a custom ROM?

The history and context are included in the git history and you can see the progression, different approaches, and other details.

As someone interested in this area: thank you

Another example, which I find very annoying, is `systemctl status`; when the service has... either enough log lines or wide enough lines, idk, it will helpfully page them. So checking the status of a service randomly may or may not block your terminal. I cannot stress enough that I do not want to have to look at the screen and decide interactively whether or not I need to hit q before I can run another command.

BusyBox v1.36.1 is 2.1 MiB and has 272 tools which is just about 7.6 KiB per tool, so when it comes to space efficiency BusyBox is probably hard to beat.

GNU coreutils is also quite happy to build itself all into a single binary. On a sample NixOS box, this binary is 1.5M and lists 106 tools (although that number should be read with a grain of salt since it's at least double listing [ and test).

https://news.ycombinator.com/item?id=48927724 seems to say dollars? Although yes the phrasing could be clearer in the post

It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such).

Different thing, but I am reminded of the BSDs having SIGINFO.

It's not bad; but fluff like this can't be in band with the output, or at least not by default.

FWIW, I would describe stderr as being out of band. IIRC that's how e.g. pv works; `<file.img pv | dd of=/dev/foo` sends data along stdout while giving status info to the user since stderr isn't being piped.

This port cost over 25k in opus/fable tokens for debugging and JIT research

This was just a fun experiment to push the boundaries of WebAssembly

I'm a huge fan of the project, but I have to ask. If spending $25k is a "fun experiment", where exactly is your threshold for serious work?

In mean... It kinda feels like this is legitimately true? An attacker trying to do anything on a user's machine through this would have to find a Firefox vulnerability and a vulnerability in the wasm runtime, which is such a high bar that I would actually feel remarkably safe running this thing. The only question is how performance works and whether there are any pain points using as a daily driver, but those feel likely to be a pretty minor point. Oh, and the usual caveat that an attacker can still compromise things inside the sandbox which does leave a certain amount of exposure (but if you run different things in different instances they're isolated).

Right - if it was all SGI, or even a mix of unix workstations, I wouldn't have blinked. It's just the macs that throw me.

Right. I just mean that macs running pre-Darwin Mac OS seem an odd choice.

Generally full marks on realism, but I have to ask: Is a combination of SGI and old school macs a sensible platform for running a park? I guess if the macs can get on an appropriate network then they could at least send control commands, but they feel like an odd fit compared to the UNIX™ boxes.

If it runs as your user and can only log in as you, then I wouldn't expect it to be able to become root. But if it can log you in as different users, I would expect that 1. it needs to run from root, and 2. it can log in as root.

It's really not. Source code, even with no history, can be modified, adapted, ported, fixed, and improved. Having history is nice, but it's way lower marginal utility.