u/singron
singron
singron
Re water/sewer: I've seen it when multiple tenants share a single water meter, so the tenants can't be directly billed individually. The landlord splits the bill among the tenants according to some fixed proportion. It's probably more common on properties converted to multi-unit or split lots. A purpose-built apartment building or multi-plex should have separate meters.
singron
Inspect the perimeter of your home for openings. A mouse can squeeze through fairly small holes and chew through many materials to widen a gap. They are also surprisingly brave climbers, so don't just check near the ground. Also make sure your doors and windows are sealing well. Garage doors are often a problem.
It's basically the same process as trying to seal your house to keep the air in, so things like IR cameras could be helpful to find leaks. You might even save a little money on HVAC.
If you need to plug a hole, I recommend stainless steel wool (e.g. a bit of a dish scrubber) combined with caulk/silicone to seal and hold it in place. Also check things like laundry vents. You can block vent pipes without blocking air flow by drilling some holes and stringing it up with wire like a tennis racket or installing a wire mesh. You can also replace the opening fixture with a more pest-resistant model.
Traps baited with peanut butter work well to catch mice once they get in, although if you don't seal your house, they will keep getting in. You don't want to poison mice since you don't want them to die and rot inside a wall. Trap them ASAP since you don't want babies, urine, or feces.
singron
How do you do it?
singron
I didn't even know there was any residential entry. I thought all the residences entered onto side streets like Twin Peeks Cir. I took a look on Google Maps and sure enough there are 5ish farm/farmhouse-looking addresses (some have multiple entrances and outbuildings, so it's hard to count just from satellite). They are somewhat clustered south of 9 Ave, but it might be too complicated to adjust the speed limit around just those properties.
singron
WoW64 itself is thunking, but the API that gets thunked is roughly the same as syscalls+libc on linux. In linux, 32-bit processes make a normal syscall into the kernel, and the kernel switches back into 64-bit mode and handles it appropriately. In WoW64, the WoW64 dlls switch into 64-bit mode in userspace before calling into the kernel.
Any dll besides the kernel interface is a real 32-bit dll. You can't use 64-bit dlls besides WoW64 itself. You would not be able to run typical applications unless you had 32-bit versions of all the normal dlls except ntdll.dll. A WoW64 build of wine/proton has 32-bit versions of all the dlls.
singron
nix-channel --list only shows channels for the current user. nixos-rebuild uses the nixos channel for the root user, which is probably still on 26.05 for you. You can verify with sudo nix-channel --list. I think most users on channels should only have root-owned channels to avoid this confusion. If you delete a channel for a user, it will default to using the root-owned channel instead.
If channels seem like a big pain, you could switch to flakes or niv instead to manage the nixpkgs version.
singron
I'm very late to this thread, but I thought you could get a better answer.
Any allocation <64 bytes will benefit from the literal fine-grained cache locality (i.e. the fact that it shares a cache-line with something else that might be accessed near the same time). Even larger objects can benefit since the beginning or end of the object might share a cache-line with another non-freed object.
An allocator that never frees always has to return new memory, which causes cache evictions sooner. The cache replacement policies in CPUs are fairly unintelligent since they have to be very fast and small (e.g. pseudo-LRU or Random-Replacement), so they are very likely to evict cache lines for in-use allocations even when cache lines for "freed" allocations could be evicted. Even a completely accurate LRU policy is suboptimal for many workloads since allocations are often used immediately before they are freed.
E.g. an allocator that stays entirely in L3 cache never has to evict a cache-line from L3, and so it never goes to main memory. A non-freeing allocator will evict as soon as it allocates an L3-amount of bytes, regardless of the size of the working set, and it's luck of the draw on whether it has to re-fetch any of those cache-lines from main memory.
The other thing is that blind-writing to uncached memory is not as fast as writing to cached memory. Since the cache is managed in terms of entire cache-lines, if you write less than a full cache-line, it first has to fetch the cache-line from memory (i.e. the cache does a read-modify-write even if your instruction is just a write). The CPU store buffer can hide the latency of this, but the store buffer can fill up and stall or require a flush (e.g. synchronization). In some hasty tests I ran, blind writes got 2-5x slower throughput once they no longer fit in L3.
singron
Anubis doesn't work as well as it used to. This is a really good explanation: https://people.kernel.org/monsieuricon/creepy-crawlies
TL;DR: scrapers easily solve anubis challenges and use residential proxies so that they only make a few requests to your domain from each IP. A single anubis instance can't correlate enough traffic to block scrapers before they change IPs.
Cloudflare can correlate traffic from all of their sites and essentially ban bots before they make the first request to your site.
singron
aoe2insights: https://www.aoe2insights.com/user/609650/
1v1 drop rate: 2.5% out of 933 games
That seems pretty high?
singron
Tuples are structurally typed, but structs and tuple-structs are (currently) always nominally typed (i.e. (u32, u32) == (u32, u32) but struct A { x: u32} != struct B { x: u32}). Adding structurally-typed structs would seriously complicate a lot of things. E.g.:
#[repr(C)]
struct A { y: u8, x: u32 }
struct B { y: u8, x: u32 }
let args = {y: 1, x: 2};
if cond {
let _: &A = &args;
} else {
let _: &B = &args;
}
What is the layout of args? It's structurally compatible with A and B (has the same field names and types), but it can't have the same memory layout as A and B at the same time.
I think a realistic proposal needs to keep nominal typing, and if the unnamed struct value can't be unambiguously inferred as a single nominal type (like the above example), then the compiler returns an error (similar to when trait method resolution is ambiguous).
singron
I love this as a brief summary of the issue.
One thing this doesn't cover is what happens if we don't add named parameters. In one sense, it's obvious since that's the life we all live now, but I see a couple different things. The post mentions builders, but I think they are relatively rare. It's so much boilerplate to create one, so I don't think they are often used unless the additional flexibility is needed (e.g. type conversion, complex mutations, or convenience methods) or as part of a heavily used library.
In practice, I feel like I see structs used to fake this:
use foo::{call_foo, CallFooArgs};
call_foo(CallFooArgs{x: 1, y: 2, z: 3})
// or
call_foo(CallFooArgs{x: 1, y: 2, z: 3, ..Default::default()})
This really suffers from java7-like "stuttering" (e.g. Object object = new Object()). If you redefine default() as a standalone function, it cuts down on noise, but the struct name is unavoidable.
I think I would be perfectly happy with nameless struct literals in argument position in practice. E.g.
call_foo({x: 1, y: 2, z:3})
// or with some extra symbol to denote inference:
call_foo(*{x: 1, y: 2, z: 3})
This leads to weirdness since this is either a special syntax you can only use as an expression in a function call, or if you allow to use them in any other position (e.g. a variable), then it opens a type-inference rabbit hole:
let args = {x: 1, y: 2, z: 3}; // Likely too bizzare
// What type is args? What if calls are generic?
// What if field values are infer-able too?
if (cond) {
call_foo(args);
} else {
call_bar(args);
}
singron
The swap problem in the article (pages only accessed while the world is stopped) is a little easier to fix than swap/GC behavior in general.
It would probably work well to fault in the metadata pages right before stopping the world (e.g. MADV_POPULATE_WRITE). And/or the metadata pages could be MADV_FREE'd after a GC, which prevents them from being swapped out and lets the kernel zero them instead (despite the name, the kernel doesn't immediately reclaim them if there isn't memory pressure). The syscall overhead might hurt on microbenchmarks with small heaps, but it's probably not significant on anything bigger. E.g. for a 51us pause, a ~100 nanosecond syscall only adds 0.2% overhead if nothing needs to be swapped in and would likely completely prevent the stop-the-world swap-in.
singron
The coal coming out of the buckets at the top doesn't physically make sense. In real life, it would dump the coal on top of the next bucket going down. There isn't a place to put the chute to catch the coal that wouldn't also block the bucket.
Instead, flip the bucket chain around so that the right side is moving up. Then, slightly before the bucket reaches the top, it dumps to the right into the chute before flipping over to the left and going back down. You can put a pinion on each bucket and a rack near the top to cause the rotation to the right. You can also make the right side of the bucket hinged and have it open and close.
singron
These are all four bar linkages. There are only two kinds in this post (parallelogram and crank-rocker), but if you vary the link lengths in more ways, you can get all kinds of different motions. It's one of the best ways to create 2d motions from a single rotational power source.
singron
No. Individuals already had ad discounts. This allows non-individuals like the parties and PACs to also get the discounts.
This is a massive benefit for Republicans since the RNC has substantially more money than the DNC and Republicans have more PAC money. It's kind of confusing to tally up PACs, but the largest democratic PAC (ActBlue) doesn't actually accept most donations itself and instead coordinates donations to individual candidates, so Democrats have less PAC money than you might think.
singron
All I want to do is solve why Nixos takes forever to do anything when I do a Sudo Nixos-rebuild switch
You might have a specific problem in your config that you could fix (e.g. evaluating multiple nixpkgs or IFD), but in general NixOS evaluation has gotten slower over time since it has to import all of its modules. See this thread or this issue.
singron
Capital gains tax is a tax break. You get to exclude capital gains from your income and instead pay a lower tax rate.
singron
In particular, non-reproducibility (e.g. embedding a UUID or timestamp) prevents the "early cutoff" optimization (name from this paper). E.g. if you change a comment and recompile with a reproducible process, the compiler object output will probably be unchanged and you can skip recompiling dependent libraries, linking the executable, and running tests.
It's especially bad if the rmeta files are non-reproducible since that would force all dependent crates to recompile, which would force all their dependent crates to recompile, and so on.
singron
I'm using sops-nix currently and mostly like it. I like that it can decrypt secrets at activation time using the host ssh key. Working with sops text files is a little awkward but it's fine. It seems better for an organization since you can define who should have access to each secret and make sure everything is re-encrypted.
Previously I've used nix-extra-builtins to call gpg, but that's a big pain since you need to unlock your key to evaluate your config, which gets in the way of CI and automation.
singron
Your first config works for me. If you are using an old version of nixpkgs from before 26.05, you should use mpv-unwrapped.wrapper and mpv-unwrapped.scripts instead since they get renamed. I think something like this:
(mpv-unwrapped.wrapper {
scripts = with mpv-unwrapped.scripts; [uosc sponsorblock];
})
Although I would probably just update to unstable or 26.05.
singron
I had a similar problem and it turned out I had a corrupted file in my nix store. I ran nix-store --verify --check-contents --repair to fix it.
singron
SD&D workload depends on your project and teammates. The class is about everything except coding, and you only incidentally write code so that you have a project around which you can do all that other work, so don't pick a project that needs a bunch of code. I think I only spent 2 hours writing code the whole semester, but other teams absolutely swamped themselves with huge projects, and we all got the same grade.
I never took any of the other classes, but I've taken one of Malik's other classes before and it was a decent amount of work.
IMO if you love CS (or quantum computing) and want to take as many of those as you can, then this is great, as long as you can handle the coursework. I took 20 credits per semester, and it's completely doable as long as 1-2 classes are light on homework and only 1-2 classes are heavy on homework.
singron
I wrote a crate for catching SIGBUS from an mmapped file. It's unpublished on crates.io but the code is here. I don't think it's that useful since it's really hard to program if you think some arbitrary process is monkeying with your mmapped files, and if you can just assume that won't happen, then you probably don't need to catch SIGBUS at all.
I guess if you want to gracefully handle a disk error through an mmap (e.g. redownloading the segment from s3 to a different disk), then it could be useful. In practice it just seems so rare (and typically unrecoverable) that crashing would be OK.
singron
Just pay staff 7% of receipts then. It doesn't have to be a surcharge added on bills after the total

I had heard the tar format was cursed, but now I know exactly how cursed it is. I've heard similar things about zip and cpio too. I'm surprised more-sane formats aren't more popular. I can't even think of one. Nix has NAR, which works for their usage, but I don't think it would be able to replace the other formats generally.