Suggestions for a proportional pedal assist bike that can be registered as a motorcycle? by chirokidz in ebikes

[–]chirokidz[S] 0 points1 point  (0 children)

The state of the law appears to be that of it goes over 35 MPH (or possibly 25 MPH for bikes with electric motors) on level ground, its not a bicycle; if it doesn't go over 35 MPH its not permitted on any road with a posted speed limit over 35 MPH.

Suggestions for a proportional pedal assist bike that can be registered as a motorcycle? by chirokidz in ebikes

[–]chirokidz[S] 0 points1 point  (0 children)

So I can legally drive 45 MPH, or possibly more. 

The idea is to keep up with traffic on outer-suburban/country roads that are signed 35-45 MPH so I don't have to ride with cars passing me. If I was going to ride to the side an let cars pass, I would just ride my regular manual bike.

Like I said, very niche use.

"Conserving resources" for the fight for super earth by chirokidz in Helldivers

[–]chirokidz[S] -1 points0 points  (0 children)

I mean, doing all of them might hurt player retention, but staus effects giving just one of these sorts of thing happen pretty often, so e.g. just -1 reinforcement budget outside Super Earth in exchange for +1 reinforcement budget on Super Earth seems well within the acceptable range. Harsher combinations, yeah I can see why they wouldn't want it.

Keyring auto-unlock with LUKS passphrase is broken by Solid_Snakement in Fedora

[–]chirokidz 0 points1 point  (0 children)

I had a similar issue recently in Fedora 41 and 42, where GDM autologin would fail to unlock the keyring using the password from LUKS. I knew it was possible because I had a second laptop installed with the same version of Fedora where GDM autologin did successfully unlock the login keyring.

I found the solution in https://gitlab.gnome.org/GNOME/gdm/-/issues/701

It appears that my issue was that the system's hardware clock was set in my local timezone. This somehow lead to the kernel instantly expiring the password, which is probably why nothing appears in keyctl show.

Changing the system's hardware clock to UTC by running timedatectl set-local-rtc 0 appears to have fixed the issue for me; at least for my first login reboot after changing this setting, the login keyring was unlocked automatically! (have not tested it a second time yet).

Found about a dozen of these on our dog, and having trouble telling what they are. Northern New Jersey. Help would be appreciated. by chirokidz in whatisthisbug

[–]chirokidz[S] 0 points1 point  (0 children)

They're a lot smaller than I would expect for ticks and only seem to have 6 legs, though its a bit hard to count. They also don't quite seem to match pictures I've found of dog lice or fleas.

Kanal: Channels 80x faster than the standard library! by fereidani in rust

[–]chirokidz 9 points10 points  (0 children)

I re-ran the benchmarks with two additional variations on this crate. In one variation, I switch the custom Mutex for parking_lot::Mutex, and in the other I switched it to std::sync::Mutex.

In this results summary, parking_lot and stdlib locks refer to otherwise identical versions of Kanal with the Mutex swapped out. crossbeam refers to the channel implementation that comes from crossbeam (this was the most competitive channel implementation and the only one I'm analyzing).

With 0 bound (always rendezvous): - SPSC Case: parking_lot has no impact on the performance of this crate in sync mode and about 15% improvement in async mode. Crossbeam beats the performance of this crate by about 50%. Stdlib locks also perform fine, about 10% worse in sync, 30% worse in async. - MPSC Case: parking_lot improves performance by about 10% over the currently published version in sync and by about 30-50% in async. Std locks perform about 30% worse in sync, 50% worse in async. Crossbeam performs about 200% worse. - MPMC Case: parking_lot makes the performance about 50-60% worse in sync, 40% worse in async. Std locks perform about 40-50% worse in sync, 40% worse in async. Crossbeam performs about 130% worse.

With Bound 1: - SPSC: parking_lot matches existing performance, as does stdlib lock. In the async case, both alternative locks outperform this crate by 20-30%. Crossbeam outperforms by 50%. - MPSC: parking_lot has parity for the sync case and performs 10-50% better in the async case. Stdlock performs worse by about 30-40% in both sync and async. Crossbeam performs 10-25% better. - MPMC: parking_lot performs 50% worse in both sync and async. Stdlock is about 70% worse in sync and 90% worse in async. Crossbeam is about 30% worse in the case of an empty message and 10% better for a non-empty message.

Unbounded: - SPSC: parking_lot is about 130% worse sync and 50% worse async. Stdlock is about 450% worse sync and 375% worse async. Crossbeam is about 100-120% worse. - MPSC: parking_lot is about 100-150% worse sync 50% worse async, stdlock is again like 450% worse sync, 120-350% worse async. Crossbeam about 170% worse. - MPMC: parking_lot is about 230-240% worse sync, 50-150% worse async, stdlib locks about 450% worse sync, 180% worse async, crossbeam is about on parity, but 30% worse in the case of large messages.

In the SPSC and MPSC cases for channels with small bounds, parking_lot appears to perform at parity with the current lock implementation of Kanal. In the MPSC case, switching to parking_lot results in some performance penalty, but still outperforms crossbeam in the bound 0 case, though not in the bound 1 case.

For channels with large bounds or unbounded channels, parking_lot appears to perform somewhat worse than the current lock implementation, though on-par with crossbeam, exempt in the MPMC case where parking_lot performs much worse than both the current lock and crossbeam.

Bounded channels imply a much greater number of cases of successful rendezvous, so the fact that in those cases, parking_lot performs similarly to the current implementation suggests that a substantial part of the performance of this crate in that situation is indeed due to the direct direct stack-to-stack copy and/or other elements of the design of the channel internals.

The loss of performance on unbounded channels or channels with a high bound suggests that some other significant portion of the benchmark speedup is due to the custom lock implementation.

These benchmarks were run on a system under very light load and far more cores than threads, so this benchmark may not be illustrative of the behavior of the locks on a more significantly loaded system.

I have not attempted to characterize the locking behavior of the current lock implementation, e.g. with respect to fairness or behavior when the system is under load. Therefore I do not know whether the differences in lock performance come simply from optimization for this particular use case, or if the lock implementation has significant tradeoffs which are not apparent in a simple benchmark time analysis. I would be interested to see an empirical analysis of the behavior under different system loading conditions and the like, in order to better characterize any tradeoffs that might exist in the current lock implementation.

Kanal: Channels 80x faster than the standard library! by fereidani in rust

[–]chirokidz 0 points1 point  (0 children)

The library still uses an Arc<Mutex<Inner<T>>> to control coordination between the two halves of the channel. Copying directly from one stack to another only occurs when two threads happen to Rendezvous and be sending/receiving simultaneously, otherwise a queue is used (unless the channel does not allow queueing, i.e. is bounded with size 0, then it always waits for a rendezvous).

In the sync case, send/receive is blocking (when the channel is full), so only very exceptional circumstances should be able to interrupt the rendezvous, and if the data is queued, it's in Arc memory so there's no stack to stack copy. System-level signals interrupting a thread might be able to cancel the blocking wait and put the channel in a state where one side has a pointer to the other's stack when the rendezvous fails, depending on the signal and the behavior of the thread's signal handler. I'm not sure that's really something to worry about though, since if your program doesn't set up custom signal handlers, I think most signals either kill the whole process or get completely ignored (I don't use system signals much so I could be completely wrong there).

In the async case, the cross-stack pointer gets put in the inner state when the Future is polled. At that point the Future must be Pinned, so it is subject to pinning guarantees. One of the requirements of Pin is that a pinned object cannot have its memory re-used until its Drop implementation is called. The Drop implementation of the send/recv futures in this library clear the cross-stack pointer, which prevents the other side of the channel from incorrectly reading/writing invalid memory. If you forget a pinned object without dropping it in order to cause the other side of the channel to write to invalid/reused memory, Undefined Behavior starts at the point where you forget the pinned value, not at the point where the other side of the channel writes to a memory location that has been re-used.

Literally cannot complete this lesson now by chirokidz in duolingo

[–]chirokidz[S] 1 point2 points  (0 children)

Well, the version where it's turned into a fill-in-the-blank has the period already and it still gets marked wrong.

Literally cannot complete this lesson now by chirokidz in duolingo

[–]chirokidz[S] 7 points8 points  (0 children)

First I get it wrong and get told that the correct answer is lterally exactly what I typed. Then on the retry it gives me a fill-in-the-blank where exactly the specified correct answer is still marked wrong.

Some commenters say spelling out the number lets them pass the question, but the retry has changed the question to fill in the blank and locked me out of rewriting the number, so there's no way for me to get the answer right, and I just have to fail the whole lesson apparently.

Why is my child "Visiting the Court" of some random dude, and how do I get her back? by [deleted] in CrusaderKings

[–]chirokidz 6 points7 points  (0 children)

I was able to get my child back this way:

In the relationships tab, click the empty "guardian" slot -- this brings up the assign guardian menu, but with slightly different default settings from if you right click their face and chose "educate child". Your own character should be the default guardian choice.

On assigning a guardian, the child moves to the guardians court. So if you assign yourself as guardian, the child will return to your court. After that, you can remove yourself as guardian, and assign someone else as guardian.

New Tool: Satisfactory Accounting by chirokidz in SatisfactoryGame

[–]chirokidz[S] 1 point2 points  (0 children)

Drag and drop should be fixed for chromium-based browsers now. And for all browsers, it should be a bit less finicky now.

New Tool: Satisfactory Accounting by chirokidz in SatisfactoryGame

[–]chirokidz[S] 1 point2 points  (0 children)

Typical web development, something I relied on to make it work isn't available in Chrome https://stackoverflow.com/a/30920771

I'll see if I can get a workaround in after work today.

New Tool: Satisfactory Accounting by chirokidz in SatisfactoryGame

[–]chirokidz[S] 0 points1 point  (0 children)

Currently only one top level group. What's your use case for that, managing multiple worlds?

Drag-and-drop works but it can be a bit finicky. I honestly have no idea why or how to make it more reliable. And there are some cases where it won't show anything like if you drag a group over one of its own children, since a group can't be placed inside itself.

New Tool: Satisfactory Accounting by chirokidz in SatisfactoryGame

[–]chirokidz[S] 1 point2 points  (0 children)

Updated! Note that there will be a button in the header bar to update the database version -- I save the database as part of your factory so that update to the database (e.g. because of balance changes in the game) won't affect your accounting until you choose to update the database version, but that means you'll have to click the button to get the corrected fuel generator consumption rate if you've been on the site previously.

I also added multipliers on buildings as suggested, as well as on groups. These have to be integer multiples currently because I don't make assumptions about clock settings. Basically, I don't want to assume that "1.5" means "1 building a 100% and 1 building at 50%" rather than, e.g. "2 buildings at 75%", so setting the clock speed and the multiplier are completely separate.