draw .io is closed source.
draw .io is closed source.
Sounds like what you’re looking for is an ATX12V plug. It’s a 2x2 connector that normally has two yellow and two black wires. It normally goes into the 2x2 receptacle on the motherboard to power the processor. In this case, the eGPU enclosure needs it for some reason, maybe for more power.
The good news is that the 2x4 breakaway connector (called EPS12V I believe) that splits into two 2x2 connectors is probably compatible with this receptacle. One of the two 2x2 pieces of the connector should fit into the eGPU’s power receptacle, and the other won’t. If it fits, it is probably the right connector. If two of the wires going to that connector are yellow, and two are black, then it’s almost certainly the right connector.
You may have multiple of these 2x4 breakaway connectors. If so, they should behave identically, and you can break up any of them and try to fit the pieces into the ATX12V receptacle.
List of ATX power supply connectors: https://en.wikipedia.org/wiki/Power_supply_unit_(computer)#Connectors (without images, unfortunately.)
Don’t forget about the big 20-pin or 24-pin main ATX motherboard power connector. Your second power supply, since it is non-modular, will need something to simulate the motherboard’s power button. That’s can be as simple as a switch between the PS-ON wire (green) and any ground wire (black). But hopefully your eGPU has a place to plug in the ATX motherboard power connector, and handles that on-off switching for you.
I suppose mine would be Proton/Steam/Mate Desktop/Gnu/Linux
This is false. X is not less secure than Wayland. It does have a different security model, which can become insecure if you misuse it. I don’t think people really care about situations where multiple user accounts access the same display.
In my opinion, the benefits of xdotool far outweigh any benefits gained by Wayland’s security model. It’s impossible to make xdotool in Wayland, because of its security model.
Why is the antivirus software detecting my Cortex-M3 binaries as dangerous to an amd64 computer? Happens on Windows 7 through Windows 10, across 3 different employers.
And how do I submit my builds to Virus Total if they’re getting deleted as soon as they come out of the linker?
I never got Proton working on my main distro (Debian), so I probably fall into this category. I did use Wine, but Wine is a lot harder to set up, and never ran games as well as Proton did.
Here is my major gaming history, since I started on Linux in 2007. Yes, I really could focus on a single game for years back then.
Today, I still prefer native Linux games. I mostly only use Proton when peer pressure for a multiplayer game required it. But I never use Wine any more.
Some of those games sound like Simon Tatham’s Portable Puzzle Collection
Available for Linux, Windows, web browser (javascript or java applet), Android, IOS, and… uh, Palm OS apparently.
The thing with coloured bubbles could be several things here. The network thing is probably net or netslide. The thing with the lasers and the grid is probably blackbox
A couple months ago, I made a Palworld server box out of a spare motherboard assembly (mobo, processor, ram) from a computer I had recently upgraded.
I didn’t have any spare drives lying around, so I plugged in 7 USB flash drives and made them into a RAID array. Not a true RAID array, but a BTRFS filesystem with volumes spread onto each flash drive, with the data redundancy set to raid1, and the metadata redundancy set to raid1c3.
It worked… in the sense that I never lost any data. It certainly didn’t work in the sense of having good uptime.
The first problem was getting it to boot right. The boot line in GRUB had “root=UUID=…” instead of a specific drive named. That is normal. However, in BTRFS multi-volume filesystems, all the volumes have the same UUID. So the initrd was only waiting for a single drive matching that UUID, then trying to mount it as the root filesystem. This failed, because the kernel had not yet set up the other 6 USB drives, and this BTRFS filesystem needs all 7 volumes present. Maybe 6, if you used the “degraded” mount option.
The workaround was to wait for this boot process to fail, at which point you get dropped into an initrd shell. Then, you look at all the drives and make sure they’re all there. And then… I don’t exactly remember what happened next. I think it was some black magic that erases your mind in the process. I somehow got it booted from the initrd shell.
Installing Steam and the Palworld server worked ok, and it even ran for a few hours before crashing overnight.
The next morning, I tried rebooting it. Unfortunately, the USB drives weren’t all appearing. Turns out the motherboard had some bad USB ports, some sometimes-bad USB ports, and a maybe-bad PCIe bus, because the PCIe USB expansion card I plugged in had weird problem that it had never had before.
I found the most reliable ports and plugged the drives in there. But you can’t just replug them in the initrd. It doesn’t have USB hotplug support. So each time it tried to boot with not all the drives there, I restarted it again until one time I finally had all the drives.
I changed the GRUB boot line to “root=/dev/sdg1” . This made it wait for all the drives to load, in any order, and whichever one was last would be mounted as the root filesystem (but the kernel would automatically include all the others too, since they were successfully initialized).
The bad USB ports kept bringing down the server every day or two. I bought a cheap NVMe drive and added it to the BTRFS filesystem, and then removed all the USB drives except the largest. That fixed the reliability. It’s been like that since.
Now, to boot the server, all I have to do is change the GRUB boot line to “root=/dev/sdb1” . Since the NVMe drive is much faster than the USB drive, it always initializes first. If the initrd waits for sdb2, then it will always have both drives initialized when it tries to mount the root filesystem.
I could add that to the grub.cfg, or come up with some other more permanent solution, but I’m not planning on rebooting this server ever again. My friends fell off Palworld, and I gave a shutdown date that’s about a week away. And the electricity is pretty reliable here.
Using a VPN (like Tailscale or Netbird) will make setup very easy, but probably a bit slower, because they probably connect through the VPN service’s infrastructure.
My recommended approach would be to use a directly connected VPN, like OpenVPN, that just has two nodes on it – your VPS, and your home server. This will bypass the potentially slow infrastructure of a commercial VPN service. Then, use iptables rules to have the VPS forward the relevant connections (TCP port 80/443 for the web apps, TCP/UDP port 25565 for Minecraft, etc.) to the home server’s OpenVPN IP address.
My second recommended approach would be to use a program like openbsd-inetd on your VPS to forward all relevant connections to your real IP address. Then, open those ports on your home connection, but only for the VPS’s IP address. If some random person tries to portscan you, they will see closed ports.
I’m not using your phone app unless you pay for the cost of a burner phone.
I’ll just stick a hotdog in the fingerprint scanner.
I showed him the thread, and he agreed. He was surprised by how strongly people felt about distros.
Personally, I think I never would have gotten as many comments as I did if not for mentioning the distro!
Yeah, Windows 7 is very old. It’s definitely a concern. I keep him highly firewalled on the network so that hopefully he won’t get hacked.
I usually play on Debian, but when I contacted Steam for support regarding Proton, they said they only supported Ubuntu or Steam OS. Since Steam OS isn’t currently available for PC, that means Ubuntu.
The easiest way to disable unnecessary services is to uninstall them with aptitude, or whichever package manager you like. Try terminating services one by one, and see if anything bad happens. If nothing bad happens, you can probably uninstall it. On the other hand, if the system does get wonky a reboot should fix it. Or, you can research the services by name and decide whether to uninstall them. (avahi-daemon for example is a good idea to uninstall.)
To make the GUI not run, uninstall your display manager (gdm, xdm, nodm, or whatever) and uninstall your xorg server or wayland server. There may be GUI programs remaining after that, but they will only be consuming disk space, not RAM or CPU.
If the battery is old and holds little charge, you may save a few watts by removing it and throwing it away, instead of letting the system keep it topped off.
Get a power meter, such as a Kill-a-watt device. Then, experiment with different settings. If it’s consuming less than 30 watts, you’re probably fine. If you live in the US, one watt-year is about one US dollar (or a little more), so for every watt it consumes, that’s about how much you will pay per year for its electricity.