Can you run more cat6? There are plenty of HDMI over cat6 adapters that work well over some fairly long distances.
There are also plenty of extended length HDMI cables that are 50+ feet if you can fish through the HDMI end. They get a bit expensive at that length because they are hybrid fiber optic but no noise concerns.
USB also has adapters to run over cat6. They are usually limited to USB2.0 but that should be plenty to plug a small hub in for mouse and keyboard.
In the US it's just like getting your regular license. A written test first which gets you a permit to ride (restrictions on that depending on the state you are in, like no riding after dark, no highways, no passengers, etc).
Then you take the road test (or take a class) which gets the full endorsement added to your license.
But yeah I would think on private property you should have been safe.
The remote was awesome, when you had a hundred mp3s on a cd it was so easy to navigate. Upgraded to the Rio Volt and then Rio Karma after that, always wished they would use those expansion ports for another remote.
Karma is still one of the best mp3 players ever made. Flac, gapless playback, parametric equalizer, dock, etc. Made the iPhone look like junk except for the control wheel being a bit too easy to break.
I still have the Volt and a couple of Karmas. 128gb compact flash cards are drop in replacements for the HDD so you get even more space and better battery life. Unfortunately the phone is just too convenient to use so they collect dust now.
The point is that you can still treat it like a physical game. So there are upsides in that you can borrow it to your friends or resell it.
If it is a game that gets updated often or requires updates to even play it (multiplayer games) then having the game data on the card is next to worthless anyways and just makes publishing the game more difficult because they can't start manufacturing the cards until the game is 100% ready.
Nintendo's audience goes for physical much more than the other consoles, much easier swapping cards than dealing with family sharing, a lot of their adult users collect games, and generally Nintendo games hold their value much more so being able to resell is important. So this is a compromise between what their users want and what they need for modern game development.
Slippery slope for sure if they start doing the same with single player games but there are valid reasons for them to do this, and the alternative is they just start forcing everyone to download all of their games which is even worse. MIG switch would never have been an issue for them if there just weren't game card slots to begin with.
Of course end users should assume the store is going to get shutdown someday and their games will be inaccessible at that time. Nintendo needs to shutdown those stores so that a couple of generations later they can sell everyone the same games for the second/third/fourth time.
Sales taxes are state/city level taxes, there are no federal sales taxes (yet). But he is essentially using the tariffs as a way to enact sales taxes without really adding a sales tax.
With the tariffs he can add a massive tax on the people which Republicans would normally be very much against, but he can say it is about being pro American and most of them forget about all of the extra money they will be paying.
This shifts the tax burden further onto middle/lower income homes and lets him give more income tax cuts to higher earners without increasing the deficit so much that congress would turn on him.
The Republicans have actually been talking about this for a long time they called it the "fair tax". Their fair tax plan was basically a flat ~23% federal sales tax that would replace income tax, but they could never get their base behind it.
Someone on Trump's team realized that we buy so much from other countries that he could accomplish the same thing the fair tax aimed to do via tariffs while selling them to his party as "buy American". His lower/middle income base eats that up, and his campaign donors see it as killing their overseas competition.
If it weren't for the other countries reciprocating it would have been a good plan for them.
Depending on how you setup your reverse proxy it can reduce random scanning/login attempts to basically zero. The point of a reverse proxy is to act as a proxy, as a sort of web router, and to validate that the http requests are correctly formatted.
For the routing depending on what DNS name/path the request comes in with it can route to different backends. So you can say that app1.yourdomain.com is routed to the internal IP address of your app1, and app2.yourdomain.com goes to app2. You can also do this with paths if the applications can handle it. Like yourdomain.com/app1.
When your client makes a request the reverse proxy uses the "Host" header or the SNI string that is part of the TLS connection to determine what certificate to use and what application to route to.
There is usually a "default" backend for any request that doesn't match any of the names for your backend services (like a scanner blindly trying to access your IP). If you disable the default backend or redirect default requests to something that you know is secure any attacker scanning your IP for vulnerabilities would get their requests rejected. The only way they can even try to hit your service is to know the correct DNS name of your service.
Some reverse proxies (Traefik, HAproxy) have options to reject the requests before the TLS negation has even completed. If the SNI string doesn't match the connection just drops it doesn't even bother to send a 404/5xx error. This can prevent an attacker from doing information gathering about the reverse proxy itself that might be helpful in attacking it.
This is security by obscurity which isn't really security, but it does reduce your risk because it significantly reduces the chances of an attacker being able to find your applications.
Reverse proxies also have a much narrower scope than most applications as well. Your services are running a web server with your application, but is Jellyfin's built in webserver secure? Could an attacker send invalid data in headers/requests to trigger a buffer overflow? A reverse proxy often does a much better job of preventing those kinds of attacks, rejecting invalid requests before they ever get to your application.
If they fire the "individual leaders" (aka supervisors/low level managers) they don't have anyone to police the workers to make sure they are actually working.
So they make them go back to the office to be sure their workers are physically at their computers all day, even if they no longer have any idea if the work is getting done.
As someone with this exact size/model of TV you are absolutely correct. AVR and speakers were just assumed to be part of how it was going to be used. Would have preferred it didn't have built in speakers at all.
Btrfs is a copy on write (COW) filesystem. Which means that whenever you modify a file it can't be modified in place. Instead a new block is written and then a single atomic operation is done to flip that new block to be the location of that data.
This is a really good thing for protecting your data from things like power outages or system crashes because the data is always in a good state on disk. Either the update happened or it didn't there is never any in-between.
While COW is good for data integrity it isn't always good for speed. If you were doing lots of updates that are smaller than a block you first have to read the rest of the block and then seek to the new location and write out the new block. On ssds this isn't a issue but on HDDs it can slow things down and fragment your filesystem considerably.
Btrfs has a defragmentation utility though so fragmentation is a fixable problem. If you were using ZFS there would be no way to reverse that fragmentation.
Other filesystems like ext4/xfs are "journaling" filesystems. Instead of writing new blocks or updating each block immediately they keep the changes in memory and write them to a "journal" on the disk. When there is time those changes from the journal are flushed to the disk to make the actual changes happen. Writing the journal to disk is a sequential operation making it more efficient on HDDs. In the event that the system crashes the filesystem replays the journal to get back to the latest state.
ZFS has a journal equivalent called the ZFS Intent Log (ZIL). You put the ZIL on fast SSDs while the data itself is on your HDDs. This also helps with the fragmentation issues for ZFS because ZFS will write incoming writes to the ZIL and then flush them to disk every few seconds. This means fewer larger writes to the HDDs.
Another downside of COW is that because the filesystem is assumed to be so good at preventing corruption, in some extremely rare cases if corruption gets written to disk you might lose the entire filesystem. There are lots of checks in software to prevent that from happening but occasionally hardware issues may let the corruption past.
This is why anyone running ZFS/btrfs for their NAS is recommended to run ECC memory. A random bit flipping in ram might mean the wrong data gets written out and if that data is part of the metadata of the filesystem itself the entire filesystem may be unrecoverable. This is exceedingly rare, but a risk.
Most traditional filesystems on the other hand were built assuming that they had to cleanup corruption from system crashes, etc. So they have fsck tools that can go through and recover as much as possible when that happens.
Lots of other posts here talking about other features that make btrfs a great choice. If you were running a high performance database a journaling filesystem would likely be faster but maybe not by much especially on SSD. But for a end user system the snapshots/file checksumming/etc are far more important than a tiny bit of performance. For the potential corruption issues if you are lacking ECC backups are the proper mitigation (as of DDR5 ECC is in all ram sticks).
Agreed. The nonstandard port helps too. Most script kiddies aren't going to know your service even exists.
Take it another step further and remove the default backend on your reverse proxy so that requests to anything but the correct DNS name are dropped (bots just are probing IPs) and you basically don't have to worry at all. Just make sure to keep your reverse proxy up to date.
The reverse proxy ends up enabling security through obscurity, which shouldn't be your only line of defence, but it is an effective first line of defence especially for anyone who isn't a target of foreign government level of attacks.
Adding basic auth to your reverse proxy endpoints extends that a whole lot further. Form based logins on your apps might be a lot prettier, but it's a lot harder to probe for what's running behind your proxy when every single URI just returns 401. I trust my reverse proxy doing basic auth a lot more than I trust some php login form.
I always see posters on Lemmy about setting up elaborate VPN setups for as the only way to access internal services, but it seems like awful overkill to me.
VPN still needed for some things that are inherently insecure or just should never be exposed to the outside, but if it is a web service with authentication required a reverse proxy is plenty of security for a home lab.
"The party told you to reject the evidence of your eyes and ears. It was their final, and most essential command." - George Orwell, 1984
Cisco c3850-12x48u is about $150 on eBay.
The main problem is the idle power consumption. About 150w with nothing plugged in.