Partisanship is a cancer. Inaction is a choice.
Singular they. Or whatever you like, I won’t take offence.
It’s a resolution they’ve arrived after considering the benefits and downsides of that tool. Nukes can be used for efficient large-scale excavation, but people were sane enough to realize why nuking themselves was a horrible idea.
Considering only the benefits and not the risks and drawbacks of anything is not just reckless. It’s zealotry.
Don’t even get me started on fucking Gigabyte. With all my heart,
It is the single worst manufacturer I’ve ever had to deal with in both a personal and professional capacity. We’ve had to RMA half a classroom over the last two years because of busted motherboards. In separate incidents, two power supplies violently self-destructed and took the motherboards and CPUs with them. My own Gigabyte 2060 Super’s fans had to be replaced within two years because the bearings were crap.
Worse, even the motherboards that didn’t mercifully explode are a fucking chore because Gigabyte’s UEFI implementation is the worst on the fucking planet. No two versions work alike. Some options are in completely different menus. Sometimes CSM or SecureBoot are busted out of the box. If PXE is enabled (which we have to use frequently), it will ALWAYS put PXE at the start of the boot order. And if it can’t connect to a PXE server, it doesn’t fall back to the next boot option. It gracefully shits itself and sits on an error message until someone manually restarts it and interrupts the process.
Fuck Gigabyte.
All of the alternatives eventually run into the same “Will my banking app work on it?” problem. The absence of a healthy app economy is the one thing that can’t be fixed by throwing software engineers at it, and it is what caused the death of Windows Phone.
just a spare nvme drive thrown in an external enclosure
A spare NVME? In this economy?
There are interfaces that allow a sufficiently privileged process to change EFI settings from the OS. Those settings are stored in the UEFI chipset, independent from the bootloader.
If you want to dual-boot Windows and Linux, I strongly recommend that you install them on separate devices, and physically disconnect your Linux device. It’s a pain in the ass, but Windows Update has a particular appetite for bootloaders and will eventually eat whatever you have on your EFI partition (including the Linux kernel and ramdisk) and replace it with its own.
Otherwise, you can use Chris Titus’ winutil script to delay or completely disable updates, and also to debloat the system and disable anti-features like telemetry and the start menu search.
Not sure if this applies to LTSC, but if you can, install a European edition of Windows (-N suffix) and set an EU location and timezone, it will allow you to more easily uninstall components because of EU regulations.
As others have said, Tailscale is the most pragmatic solution. It’s a mesh VPN based on Wireguard. It’s implemented in such a way that you don’t need a static IP and don’t need to open any ports on your firewall. The caveat is that you either need to register an account on tailscale.com (it’s free for small-scale use) or set up a self-hosted alternative like Headscale on a VPS. Then you have to install the Tailscale client on each of the hosts you want to access and log into your account.
Tailscale nodes will be accessible using an internal, private address in the 100.64.0.0/10 address space. You can also set up a split DNS that allows you to access your hosts using a DNS name like hostname.your-tailnet-name.ts.net.
Do they accept photographs of my money, or will I have to phone them and jingle some coins at the handset?
Nah, I don’t want that. He is actually hilarious… but in the same way as a drunk methhead redneck who keeps slipping on shit while trying to wrestle a pig. A cheap laugh at an obviously futile crusade against an imaginary enemy, but also a little pathetic and tragic; a terminally online Don Quixote.
Everyone criticizing the community has the opportunity
That’s a lie. The community and every post on it was locked for several months.
"We spent two decades making sure the compiler will never produce memory-unsafe code. It requires a lot of nigh-illegible boilerplate code to even compile and adds massive cognitive load, but the effort will be worth it.
Anyway, here’s a type whose only purpose is to disable all of that shit."
The hate boner against Linux is one thing, but honestly, the comments that aren’t related to computers are way more concerning. The guy is wildly antisemitic, but has tried to downplay it because of phrasing… while also referring to Judaism with a very colorful expression.
Everybody in this thread got baited.
I mean whatever level of access is required to upload an image. That can be access to the web app (with login), access through WebDAV, or access to the underlying OS or filesystem. If you can put a file on Nextcloud, it is sufficient access.
I forgot to mention that the vulnerability can only be exploited if libraw is also compiled with a particular flag that enables the vulnerable feature. That flag is disabled on base Debian. Docker’s service doesn’t test whether the vulnerability is actually present in the image, only that the package version is listed as affected.
Those vulnerabilities are inherited from the Debian base image. Debian is extremely diligent about fixing high-risk vulnerabilities. A high severity CVE does not automatically mean that you are at severe risk. It’s more an indication of how fucked you can be IF the vulnerability is exploited to its greatest potential.
One of the CVEs affects libraw, which is a library for handling RAW photograph files. If a RAW file contains a particular header, and that header is maliciously constructed in a particular way, extracting an embedded thumbnail can allow the attacker to execute arbitrary code on the server. To make that happen, the attacker must either gain access to a device (e.g. camera) you own, or already have access to the server to upload and process the file, which means that security has already failed.
The Swiss cheese model applies to cybersecurity too.
Forget Lutris, it’s been having a ton of issues lately. The lead developer also started using AI-generated code around the time (and being a real dick about it), but that might just be a coincidence.
Faugus Launcher is my preference. It handles Proton installations on its own without having to install system packages.
Speaking of Magritte… (unrelated, I just really like Interface)
I use Docker Compose to run my Nextcloud server using the community image, which in turn lives inside an unprivileged LXC container.
volumes:
db:
services:
db:
image: mariadb:lts
container_name: mariadb
restart: always
command: --transaction-isolation=READ-COMMITTED --log-bin=binlog --binlog-format=ROW
volumes:
- db:/var/lib/mysql
secrets:
- mysql_root_password
- mysql_nextcloud_password
environment:
- MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql_root_password
- MYSQL_PASSWORD_FILE=/run/secrets/mysql_nextcloud_password
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
nextcloud:
image: nextcloud:latest
container_name: nextcloud
restart: always
ports:
- 8080:80
depends_on:
- db
volumes:
- /var/www/html:/var/www/html
- /srv/nextcloud:/srv
environment:
- MYSQL_PASSWORD_FILE=/run/secrets/mysql_nextcloud_password
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
- MYSQL_HOST=db
secrets:
mysql_root_password:
file: ./secrets/mysql_root_password.txt
mysql_nextcloud_password:
file: ./secrets/mysql_nextcloud_password.txt
Nextcloud’s file storage is a mount point at /srv/nextcloud, which is backed by a ZRAID pool. The secrets are stored in files with 600 permissions. The web server is initially exposed on port 8080.
When you run the container for the first time, it will show a first time setup dialog. You’ll have to fill it out manually, using mariadb for the database type and db for the database hostname.
If Nextcloud works through HTTP, you can then set up a proxy for HTTPS. I used Nginx running on the same LXC. I can’t guarantee that my config is adequately secure, use it at your own risk.
upstream php-handler {
server 127.0.0.1:9000;
}
server {
listen 80;
listen [::]:80;
server_name nextcloud.your.domain;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name nextcloud.your.domain;
keepalive_timeout 70;
client_max_body_size 32G;
ssl_certificate /etc/nginx/ssl/ssl.crt;
ssl_certificate_key /etc/nginx/ssl/ssl.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
fastcgi_hide_header X-Powered-By;
location / {
proxy_pass http://127.0.0.1:8080/;
}
}
To allow the web app to work using the DNS name, you’ll have to edit /var/www/html/config/config.php and change/add these values:
'trusted_domains' => array(
0 => '127.0.0.1:8080',
1 => 'nextcloud.your.domain',
// 2 => whatever other addresses you want to use
),
'overwrite.cli.url' => 'https://nextcloud.your.domain/',
'overwriteprotocol' => 'https',
'overwritehost' => 'nextcloud.ng.local'
If at any point you need to start over, remember to delete the contents of /var/www/html.
(edit) Forgot to mention: the web server will accept connections from all addresses, you’ll need to set up a strict firewall to only allow 443 (maybe 80) and 22.
You asked for feedback and that’s what you got. Don’t get pissy when it’s not what you were hoping for. It’s pretty clear that your project is not welcome in this community.
(edit) To be clear, I’m not an expert, and it’s been at least a decade since I’ve had to work with shader programming. My knowledge could be completely outdated.
Important to note that what happens when you skip it is exactly what happens with most games when you run them outside Steam (unless the game itself precompiles its shaders on first launch).
When the graphics library (Vulkan, OpenGL, or DirectX) needs to load a shader, it first checks the shader cache (or pipeline cache in Vulkan’s case) to see if it can find the compiled bytecode. If the bytecode exists (hit), it is loaded directly into VRAM, much like the machine code of an executable. If it doesn’t (miss), the shader first has to be compiled from its source code into bytecode. This is a CPU-bound operation, which can introduce performance issues (stutters, freezes) and spike the CPU usage. After that, the resulting bytecode is stored in the cache.
Steam does the same, but preemptively. It scans the game files and compiles and caches any shaders it can find. The difference is only in the timing.