I recommend a used 3090, as that has 24 GB of VRAM and generally can be found for $800ish or less (at least when I last checked, in February). It’s much cheaper than a 4090 and while admittedly more expensive than the inexpensive 24GB Nvidia Tesla card (the P40?) it also has much better performance and CUDA support.
I have dual 3090s so my performance won’t translate directly to what a single GPU would get, but it’s pretty easy to find stats on 3090 performance.
Not directly, but indirectly. You gerrymander the district-based positions, which allow you to pass legislation enabling you to suppress enough votes to win the statewide elections, too.
That sounds like something someone who’s never heard of gerrymandering or voter suppression would say.
To be clear, I’m measuring the relative humidity of the air in the drybox at room temp (72 degrees Fahrenheit / 22 degrees Celsius), not of the filament directly. You can use a hygrometer to do this. I mostly use the hygrometer that comes bundled with my dryboxes (I use the PolyDryer and have several extra PolyDryer Boxes, but there are much cheaper options available) but you can buy a hygrometer for a few bucks or get a bluetooth / wifi / connected one for $15-$20 or so.
If you put filament into a sealed box, it’ll generally - depending on the material - end up in equilibrium with the air. So the measurement you get right away will just show the humidity of the room, but if the filament and desiccant are both dry, it’ll drop; if the desiccant is dry and the filament is wet, it’ll still drop, but not as low.
Note also that what counts as “wet” varies by material. For example, from what I’ve read, PLA can absorb up to 1% or so of its mass as moisture, PETG up to 0.2%, Nylon up to 7-8%… silica gel desiccant beads up to 40%. So when I say they’ll be in equilibrium, I’m referring to the percentage of what that material is capable of absorbing. It isn’t a linear relationship as far as I know, but if it were, that would mean that: if the humidity of the air is 10% and the max moisture the material could retain is 1%, then the material is currently retaining 0.1% moisture by mass. If my room’s humidity is kept at 40%, it’ll absorb moisture until it’s at 0.4% moisture by mass.
That said, this doesn’t measure it perfectly, since while most filament materials absorb moisture from the air when the humidity is higher, they don’t release it as easily. Heating it both allows the air to hold more moisture and allows the filament (and desiccant) to release more moisture.
The above post says it has support for Ollama, so I don’t think this is the case… but the instructions in the Readme do make it seem like it’s dependent on OpenAI.
What have you done to clean the bed? From the link to the textured sheet, you should be cleaning it between every print - after it cools - with 90% IPA, and if you still have adhesion issues, you should clean it with warm water and a couple drops of dish soap.
Has the TPU been dried? I don’t normally print with TPU but my understanding is that it needs to be lower humidity than PLA; I use dryboxes for PLA and target a humidity of 15% or lower and don’t use them if they raise above 20%. The recommendation I saw for TPU was to dry it for 7 hours at 70 degrees Celsius, to target 10% humidity (or at least under 20%) and to print directly from a drybox. Note that compared to other filaments, TPU can’t recover as well from having absorbed moisture - if the filament has gotten too wet, it’ll become too brittle if you dry it out as much as is needed. At that point you would need to start with a fresh roll, which would ideally go into a dryer and then drybox immediately.
You should be able to set different settings for the initial layer to avoid stringing, i.e., slower speeds and longer retraction distance. It’s a bit more complicated but you can also configure the speed for a specific range of layers to be slower - i.e., setting it to slow down again once you get to the top of the print. For an example of that, see https://forum.prusa3d.com/forum/prusaslicer/bed-flinger-slower-y-movement-as-function-of-z/
What’s the max speed you’re printing at? My understanding is that everything other than travel should all be the same speed at a given layer, and no higher than 25 mm/s. And with a bed slinger I wouldn’t recommend a much higher travel, either.
In addition to a brim, have you tried adding supports?
Are you saying that NAT isn’t effectively a firewall or that a NAT firewall isn’t effectively a firewall?
Is there a way to use symlinks instead? I’d think it would be possible, even with Docker - it would just require the torrent directory to be mounted read-only in the same location in every Docker container that had symlinks to files on it.
Depending on setup this can be true with Jellyfin, too. I have a domain registered, use dynamic DNS, and have Traefik direct a subdomain to my Jellyfin server. My mobile clients are configured using that. My local clients use the local static IP.
If my internet goes down, my mobile clients can’t connect, even on the LAN.
On the other hand it is a conduit for censorship. If an admin doesn’t like what you post on another instance, then they can censor you everywhere.
Such a user can
Orcas are dolphins, though. Do you mean bottlenose dolphins specifically?
Under notes, where you said my name, did you mean “Hedgedoc?”
local docker hub proxy
Do you mean a Docker container registry? If so, here are a couple options:
Invidious link didn’t work… Do you have the youtube link?
Heads up for future reference: the video ID is the same between Youtube and Invidious, so you can just replace the invidious domain (inv.nadeko.net in this case) with youtube.com.
You can control that with a setting. In Settings - Privacy, turn on “Query in the page’s title.”
My instance has a magnifying glass as the favicon.
Giant squids are the bears of the ocean
Giphy has a documented API that you could use. There have been bulk downloaders, but I didn’t see any that had recent activity. However you still might be able to use one to model your own script after, like https://github.com/jcpsimmons/giphy-stacks
There were downloaders for Gfycat - gallery-dl supported it at one point - but it’s down now. However you might be able to find collections that other people downloaded and are now hosting. You could also use the Internet Archive - they have tools and APIs documented
There’s a Tenor mass downloader that uses the Tenor API and an API key that you provide.
Imgur has GIFs is supported by gallery-dl, so that’s an option.
Also, read over https://github.com/simon987/awesome-datahoarding - there may be something useful for you there.
In terms of hosting, it would depend on my user base and if I want users to be able to upload GIFs, too. If it was just my close friends, then Immich would probably be fine, but if we had people I didn’t know directly using it, I’d want a more refined solution.
There’s Gifable, which is pretty focused, but looks like it has a pretty small following. I haven’t used it myself to see how suitable it is. If you self-host it (or something else that uses S3), note that you can use MinIO or LocalStack for the S3 container rather than using AWS directly. I’m using MinIO as part of my stack now, though for a completely different app.
MediaCMS is another option. Less focused on GIFs but more actively developed, and intended to be used for this sort of purpose.
Wouldn’t be a huge change at this point. Israel has been using AI to determine targets for drone-delivered airstrikes for over a year now.
https://en.m.wikipedia.org/wiki/AI-assisted_targeting_in_the_Gaza_Strip gives a high level overview of Gospel and Lavender, and there are news articles in the references if you want to learn more.
This is at least being positioned better than the ways Lavender and Gospel were used, but I have no doubt that it will be used to commit atrocities as well.
For now, OpenAI’s models may help operators make sense of large amounts of incoming data to support faster human decision-making in high-pressure situations.
Yep, that was how they justified Gospel and Lavender, too - “a human presses the button” (even though they’re not doing anywhere near enough due diligence).
But it’s worth pointing out that the type of AI OpenAI is best known for comes from large language models (LLMs)—sometimes called large multimodal models—that are trained on massive datasets of text, images, and audio pulled from many different sources.
Yes, OpenAI is well known for this, but they’ve also created other types of AI models (e.g., Whisper). I suspect an LLM might be part of a solution they would build but that it would not be the full solution.
As it is, you only see new comments if you scroll past the post again (and your client has refreshed it) or if you open it directly. If your client hasn’t updated the comment count or if you refresh your feed and the post falls off, you’ll never see it anyway.
A “Watch” feature would solve this better. If you watch a post, you get aggregated notifications for edits and comments on the post. If you watch a comment, you get aggregated notifications for replies to it or any of its children.
By aggregated notifications, I mean that you’d get one notification that said “The post you watched has been edited; 5 new comments” rather than a notification for each new comment.
Then, in addition to exposing a “Watch” action on posts and comments, clients could also enable users to automatically hide posts that are watched, either by marking them as hidden or by hiding watched posts without updates.
If the latter approach were taken, notifications might not even be necessary - the post could just get added back into the user’s feed when changes were made. It would result in a similar experience to forums, where new activity in a topic would bump it to the front, but it would only impact the people who were watching it.
You can kinda get that behavior by sorting your feed by Active, but this could be used with other sorting methods.
Look up “LLM quantization.” The idea is that each parameter is a number; by default they use 16 bits of precision, but if you scale them into smaller sizes, you use less space and have less precision, but you still have the same parameters. There’s not much quality loss going from 16 bits to 8, but it gets more noticeable as you get lower and lower. (That said, there’s are ternary bit models being trained from scratch that use 1.58 bits per parameter and are allegedly just as good as fp16 models of the same parameter count.)
If you’re using a 4-bit quantization, then you need about half that number in VRAM. Q4_K_M is better than Q4, but also a bit larger. Ollama generally defaults to Q4_K_M. If you can handle a higher quantization, Q6_K is generally best. If you can’t quite fit it, Q5_K_M is generally better than any other option, followed by Q5_K_S.
For example, Llama3.3 70B, which has 70.6 billion parameters, has the following sizes for some of its quantizations:
This is why I run a lot of Q4_K_M 70B models on two 3090s.
Generally speaking, there’s not a perceptible quality drop going to Q6_K from 8 bit quantization (though I have heard this is less true with MoE models). Below Q6, there’s a bit of a drop between it and 5 and then 4, but the model’s still decent. Below 4-bit quantizations you can generally get better results from a smaller parameter model at a higher quantization.
TheBloke on Huggingface has a lot of GGUF quantization repos, and most, if not all of them, have a blurb about the different quantization types and which are recommended. When Ollama.com doesn’t have a model I want, I’m generally able to find one there.