This is a record for my own passthrough setup, I can finally use a single laptop for windows gaming and linux programming at the same time.
My G14 is GA402RJ(6800HS + 6700s) with MT7922 WiFi/BT card.
At this time, BIOS version is 309.
#!/bin/bash | |
CONTAINER=$1 | |
RUNNING=$(docker inspect --format="{{ .State.Running }}" $CONTAINER 2> /dev/null) | |
if [ $? -eq 1 ]; then | |
echo "'$CONTAINER' does not exist." | |
else | |
/usr/bin/docker rm --force $CONTAINER |
https://docs.docker.com/engine/swarm/swarm-tutorial/
swarm
-----
| - manager (alpha) [8GB HDD1/, 32GB HDD2/data, 4 Cores, 6GB RAM]
#!/usr/bin/python | |
import os.path | |
import re | |
import os | |
import sys | |
import copy | |
import eyed3 | |
from eyed3.id3.tag import Tag | |
helptext = """ |
In CS2, when a player is sliding/surfing against some geometry, it's possible that they lose all their momentum/velocity. This is usually called wallbug/rampbug. While the name was inherited from Source 1 games (such as CS:GO, CS:S, TF2,...), rampbugs in CS2 behave much differently from its predecessor. In contrast to source 1 games, it's also possible have the velocity redirected to another direction instead of losing all momentum.
This bug doesn't seem to be common in all source 2 games (HL:A for instance, does not have this bug), and was orignially not present in the very early versions of CS2 Limited Test. Rampbugs become more and more frequent over time, with the Call to Arms update effectively doubling the frequency of these bugs, which is a significant problem for custom gamemodes heavily depending on geometry collision (eg. surf).
Keep in mind that while the player collision hitbox is a box, the images shown below will represent the player as a dot instead for simplicity.
For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.
Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon
with HyperThreading enabled, but it can work without problem on slower machines.
You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.
rebase
vs merge
).rebase
vs merge
)reset
vs checkout
vs revert
)git rev-parse
)pull
vs fetch
)stash
vs branch
)reset
vs checkout
vs revert
)# Apache License 2.0 | |
# 使用法は gist のコメントを見てください | |
import argparse | |
from typing import List, Optional, Union, Iterator | |
from llama_cpp.llama_chat_format import _convert_completion_to_chat, register_chat_completion_handler | |
import llama_cpp.llama_types as llama_types | |
from llama_cpp.llama import LogitsProcessorList, LlamaGrammar | |
from llama_cpp import Llama, llama_chat_format | |
import gradio as gr |
# Thanks https://discuss.pytorch.org/t/rmse-loss-function/16540 | |
class RMSELoss(torch.nn.Module): | |
def __init__(self): | |
super(RMSELoss,self).__init__() | |
def forward(self,x,y): | |
criterion = nn.MSELoss() | |
loss = torch.sqrt(criterion(x, y)) | |
return loss |
Since approximately 2024-04-02, the latest LG Dev Mode app (2.1.2 in the Content Store) copies and resets the permissions of jail_app.conf
/jail_app.conf.sig
on every boot. Therefore, jailpatch.sh
etc. will no longer work.
If you have webOS 5+ and old enough firmware, WTA (which does not require Dev Mode) will still work.
If you have webOS 4.x, you can try CVE-2023-6319. It is unpatched on the latest (final?) firmware for webOS 4.0 (2018) models.