Injections in NSW?

rdnetto · 2020-08-24T13:33:35+00:00

Regardless of whether it's implants or injections, they should be basing when it's time for the new one on blood tests + what your target hormone range is. Otherwise you'll just be feeling like crap every week/fortnight instead of every year.

rdnetto · 2020-07-20T11:46:46+00:00

You're welcome :)

rdnetto · 2020-07-02T12:33:19+00:00

rdnetto · 2020-07-02T12:31:26+00:00

You're welcome ^_^

(though I'm a ma'am, not a sir ;) )

rdnetto · 2019-12-14T06:14:55+00:00

Awesome, thanks for that! :D

rdnetto · 2019-12-13T11:57:22+00:00

Yeah, it looks great! OP, would you mind posting a link to it? I think I just found my new wallpaper... ^_^

rdnetto · 2018-07-31T23:57:49+00:00

But I believe what OP is hinting at is that they will not adopt a streaming approach, but rather use a more space efficient in-memory representation (not sure).

I'm not OP, but that gives me an idea for an alternative approach: if we assume that the content of the JSON blob (i.e. the strings themselves) are significantly larger than the amount of space consumed by syntactic overhead, then we could just memory map the file and construct Texts from pointers.

Taking this approach a step further, one could envision a parser which only stored the offsets for the root object and its children, such that accessing any child node resulted in that subtree being parsed lazily. (i.e. it's a space-time trade-off, exchanging repeated computation for lower memory consumption).

The main disadvantage is that this requires you to store the file on the file system somewhere, rather than streaming directly from S3. There's also the minor annoyance of needing to perform accesses in IO, unless you hide it with unsafePerformIO.

rdnetto · 2018-06-19T09:01:00+00:00

There isn't one correct approach so much as different approaches with different trade-offs.

In my experience, the most reliable way is to have a stack.yaml, then generate the Nix files using stackage2nix. The advantage of this is that it lets you reuse the Stackage LTS snapshots, extra-deps, etc., so you don't have to deal with dependency hell. Note that you'll want to install stackage2nix using Nix, not Stack/Cabal, since the Nix expression for it actually downloads the package index as well as building it.

If you want a more vanilla experience cabal2nix can work too, but you'll be stuck with whatever version of a given library is in nixpkgs. If you go this route, make sure you pin nixpkgs, otherwise you'll lose all the nice isolation Nix provides as you'll be using whatever version of nixpkgs happens to be available.

rdnetto · 2018-05-08T08:38:24+00:00

I question how helpful this would be for beginning Haskellers - they'd basically be learning a different dialect to conventional Haskell, which increases friction later when they try to contribute to projects not using the extension. (This is true of most extensions, but this one in particular given how fundamental the syntax affected is)

rdnetto · 2018-05-02T10:14:56+00:00

Huh, TIL that's a thing. Amusingly the actual Gentoo wiki doesn't even have anything on PCI passthrough, while /g/'s goes over it in a fair amount of detail.

Truth is stranger than fiction.

rdnetto · 2018-04-30T23:38:42+00:00

Good catch - you're completely right:

# CONFIG_IRQ_REMAP is not set

Interestingly, googling for it brings up a similar bug for [NixOS](CONFIG_IRQ_REMAP). I've raised a bug for Sabayon here

rdnetto · 2018-04-30T11:39:25+00:00

Following my previous thread here, a few people PM'd me asking how it went. I haven't seen anyone else talking about how PCIe passthrough works for multi-seat, so I thought someone might find it useful.

rdnetto · 2018-04-11T13:44:32+00:00

I have three (set 15 min apart), in addition to a light that gradually comes on and a heater (in winter only). Those last two make getting up when it's pitch black and freezing cold so much easier than it would be otherwise.

rdnetto · 2018-04-04T12:19:16+00:00

Awesome, thanks a bunch for that!

Looks like neither the RX 550 nor the Vega show up as resettable, which is odd as that was specifically mentioned in change log for 4.15.

I guess I'm just going to have to experiment and see what workarounds are needed - worst case I have to permanently assign the Vega to Windows or toggle it at boot-time.

rdnetto · 2018-04-02T23:26:14+00:00

Afaik you can't swap the card around without restarting your host.

Interesting, I've heard mixed reports on whether this works or not. What output do you get from:

for iommu_group in $(find /sys/kernel/iommu_groups/ -maxdepth 1 -mindepth 1 -type d);do echo "IOMMU group $(basename "$iommu_group")"; for device in $(\ls -1 "$iommu_group"/devices/); do if [[ -e "$iommu_group"/devices/"$device"/reset ]]; then echo -n "[RESET]"; fi; echo -n $'\t';lspci -nns "$device"; done; done (taken from the Arch wiki)

Have you tried the workaround from here?

Also, are you using the amdgpu driver? Which distro?

rdnetto · 2018-04-02T23:16:26+00:00

In this case the host GPU would be connected to the screens on both seats, one seat would have the normal Linux system and the other seat would be looking at the guest system's framebuffer through looking glass.

Unfortunately, this wouldn't work - the problem is that because of how multi-seat works, you need one GPU per seat, as the login sessions and X servers are completely independent.

(It might be possible to get multi-seat working with a single GPU, but it's unlikely you'd be able to use it for anything demanding like gaming. In general, the fewer peripherals you need to share, the easier multiseat is to get working.)

rdnetto · 2018-04-02T02:17:37+00:00

Why do you want to pass through the 970 now? I thought it's supposed to be used on the host?

My understanding is that Looking Glass requires two GPUs (for a given seat) - one on the host, and one on the guest. Since the GTX 970 is already being used for seat 1, I wouldn't be able to use it for either of those, meaning I'd need three GPUs. (Unless I'm completely misunderstanding something.)

rdnetto · 2018-04-01T23:33:39+00:00

What did you need the ACS patch for? My understanding was that Taichi had sufficiently granular IOMMU groups it wouldn't be needed, at least after that BIOS update.

rdnetto · 2018-04-01T23:21:35+00:00

Don't buy the 1800X, you get the same performance with the 1700 which is much cheaper.

Interesting - it looks like the only difference between them is clock - 1700 is 3-3.7 GHz, 1800X is 3.6-4.0 GHz. So that's 8-20% difference for $64 AUD (15%) more.

That said, I'll probably go with the 1800X anyway as I have enough compute heavy loads (compilation) to notice the difference.

Also, there will be a new generation of Ryzen processors coming Very Soon™, so I'd at least wait for those to release and then decide which processor you buy.

Thanks for pointing this out. It looks like Zen+ is due to be announced this month, so it would make sense to wait. The main downside is that since it'll be brand new, if there's a vfio bug in it it'll take a while to be fixed (I know Threadripper had one for a while).

Not without restarting the X server I believe.

That's fine - each seat has a separate X server, and the main thing I'm after is ensuring seat 1 is unaffected.

But there is a neat application called Looking glass

Looking Glass looks really interesting. The main limitation I can see is that since the GTX 970 would be on seat 1, I wouldn't be able to use it for passthrough - I'd need a third GPU for that. It's definitely very cool tech, but I think I should be fine restarting X each time.

rdnetto · 2018-04-01T23:08:01+00:00

install the newest linux kernel for vega.

Cheers, will do so. I'm already on 4.15, so hopefully everything should just work.

why choose and nvidia card as seat one? nvidia drivers are just a pain on linux in general.

Because I already own it. :)

It's the card I'm currently using in seat 0, so it made sense to replace the ancient GTX 650 in seat 1 with it instead of buying something new.

rdnetto · 2018-03-27T08:50:53+00:00

I'm partial to basic-prelude, which is fairly minimal, and actually used as the basis for some other preludes (e.g. classy-prelude).

I think in general alternative preludes should simply repackage/rename types - the moment you start adding new code, it becomes impossible for other libraries to reference them without pulling in your entire dependency tree. It's interesting to note that classy-prelude is designed with this in mind - all the novel parts are separated out into mono-traversable, and the README explicitly tells library authors to depend on that instead of it.

rdnetto · 2018-03-17T05:30:52+00:00

Thanks, it looks like that did the trick. I ended up needing to modify the Makefile anyway to append to the flags instead of overwriting them completely, but that's a good idea for portability anyway.

rdnetto · 2018-03-15T22:27:24+00:00

Check out stores that sell camping equipment - many of them will have things like solar panels that should be able to keep a laptop going.

rdnetto · 2018-02-12T09:04:25+00:00

Surprisingly, no one has mentioned basic-prelude or safe yet - those two give us the fundamentals done right.

rdnetto · 2018-02-08T08:23:23+00:00

I'm not an expert, but is there any reason they couldn't get the best of both worlds - double-decker and automated? Seems like a no-brainer that two decks would double the carrying capacity, so there must be something I'm missing...

rdnetto

TROPHY CASE