It also doesn't say that the line on the bottom is straight, so we have no idea if that middle vertex adds up to 180 degrees. I would say it is unsolvable.

Is there anything that really makes their job shittier about this though? Than than dealing with three orders instead of one?

If anything with the focus these days on metrics around how fast they can serve customers these three simple orders probably made their metrics look better so they could slack off on the next few orders.

But yeah just says "I'm a cheapskate."

I always see this argument but I really don't want anything plugged into anything as important as the USB-C port while the phone is in my pocket.

3.5 plugs are rather short outside of the phone (at least for headphones with 90deg plugs) to minimize leverage that you put on the port. Being able to rotate also means less stress on the port as well.

The USB-C adapters are pretty short, but lack the rotation. I have replaced USB-C ports in dozens of Nintendo Switches and other devices, it is pretty clear they aren't designed to take much stress.

Long story short if anything happens I would much rather have the 3.5mm pin stuck in a headphone jack than breaking the USB-C port and making it so my phone is a brick.

If you are accessing your files through dolphin on your Linux device this change has no effect on you. In that case Synology is just sharing files and it doesn't know or care what kind of files they are.

This change is mostly for people who were using the Synology videos app to stream videos. I assume Plex is much more common on Synology and I don't believe anything changed with Plex's h265 support.

If you were using the built in Synology videos app and have objections to Plex give Jellyfin a try. It should handle h265 and doesn't require a purchase like Plex does to unlock features like mobile apps.

Linux isn't dropping any codecs and should be able to handle almost any media you throw at it. Codec support depends on what app you are using, and most Linux apps use ffmpeg to do that decoding. As far as I know Debian hasn't dropped support for h265, but even if they did you could always compile your own ffmpeg libraries with it re-enabled.

How can I most easily search my NAS for files needing the removed codecs

The mediainfo command is one of the easiest ways to do this on the command line. It can tell you what video/audio codecs are used in a file.

With Linux and Synology DSM both dropping codecs, I am considering just taking the storage hit to convert to h.264 or another format. What would you recommend?

To answer this you need to know the least common denominator of supported codecs on everything you want to play back on. If you are only worried about playing this back on your Linux machine with your 1080s then you fully support h265 already and you should not convert anything. Any conversion between codecs is lossy so it is best to leave them as they are or else you will lose quality.

If you have other hardware that can't support h265, h264 is probably the next best. Almost any hardware in the last 15 years should easily handle h264.

When it comes to thumbnails for a remote filesystem like this are they generated and stored on my PC or will the PC save them to the folder on the NAS where other programs could use them.

Yes they are generated locally, and Dolphin stores them in ~/.cache/thumbnails on your local system.

Named volumes are often the default because there is no chance of them conflicting with other services or containers running on the system.

Say you deployed two different docker compose apps each with their own MariaDB. With named volumes there is zero chance of those conflicting (at least from the filesystem perspective).

This also better facilitates easier cleanup. The apps documentation can say "docker compose down -v", and they are done. Instead of listing a bunch of directories that need to be cleaned up.

Those lingering directories can also cause problems for users that might have wanted a clean start when their app is broken, but with a bind mount that broken database schema won't have been deleted for them when they start up the services again.

All that said, I very much agree that when you go to deploy a docker service you should consider changing the named volumes to standard bind mounts for a couple of reasons.

• When running production applications I don't want the volumes to be able to be cleaned up so easily. A little extra protection from accidental deletion is handy.

• The default location for named volumes doesn't work well with any advanced partitioning strategies. i.e. if you want your database volume on a different partition than your static web content.

• Old reason and maybe more user preference at this point but back before the docker overlay2 storage driver had matured we used the btrfs driver instead and occasionally Docker would break and we would need to wipe out the entire /var/lib/docker btrfs filesystem, so I just personally want to keep anything persistent out of that directory.

So basically application writers should use named volumes to simplify the documentation/installation/maintenance/cleanup of their applications.

Systems administrators running those applications should know and understand the docker compose well enough to change those settings to make them production ready for their environment. Reading through it and making those changes ends up being part of learning how the containers are structured in the first place.

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).

We asked our Dell sales guy this question years ago now, when they had been removed one year and quickly added back the next year.

They are there mostly for government builds, and other places with high security requirements. Usually the requirement is that they need to prevent any unauthorized USB devices from being plugged in. With the PS2 m&k ports they can disable the USB ports entirely in the BIOS.

Cisco c3850-12x48u is about $150 on eBay.

• 802.3bt (60watt) PoE on all ports
• 36x 1gig rj45 ports
• 12x 1/2.5/5/10gig rj45 ports
• Has a module slot that you can add 4x or 8x (8x is rare so expensive) 10gig sfp+

The main problem is the idle power consumption. About 150w with nothing plugged in.

I think the better solution is if the company is so important that it needs to be bailed out, then should just get nationalized when it fails.

Our money goes towards bailing them out, but the public owns it after that. The shareholders that ran it into the ground shouldn't get to keep it.

Well if you rephrase it for a normal car it doesn't sound so absurd. "If your hood won't latch the car won't let you drive at highway speeds?"

A failed latch on a front compartment can be very dangerous because it catches the wind if it opens suddenly at 60+mph. At best you are blinded, or it gets torn off to go flying into a car behind you.

As such, highway speeds should be restricted if the latch is malfunctioning. The real problem here is that Tesla doesn't like dealers because they want that middleman money for themselves, so you often have to drive quite the distance to get it repaired. If this were a vehicle from any of the other major manufacturers most people are probably only a few miles from their nearest dealer.

Normal cars have two hood latches. Your primary latch (that you open with the hood pull in the car) and a secondary safety latch (when you reach under the hood to open it fully) so this problem is an extremely uncommon problem for a normal car.

But since this is a frunk it gets opened a lot more for storage and users would probably not be very happy about having to deal with the secondary latch on a regular basis. So they have motorized those latches for ease of use, and motorizing them adds a lot more points of failure.

The biggest question is, are you looking for Dolby Vision support?

There is no open source implementation for Dolby Vision or HDR10+ so if you want to use those formats you are limited to Android/Apple/Amazon streaming boxes.

If you want to avoid the ads from those devices apart from side loading apks to replace home screens or something the only way to get Dolby Vision with Kodi/standard Linux is to buy a CoreELEC supported streaming device and flashing it with CoreELEC.

List of supported devices here

CoreELEC is Kodi based so it limits your player choice, but there are plugins for Plex/Jellyfin if you want to pull from those as back ends.

Personally it is a lot easier to just grab the latest gen Onn 4k Pro from Walmart for $50 and deal with the Google TV ads (never leave my streaming app anyways). Only downside with the Onn is lack of Dolby TrueHD/DTS Master audio output, but it handles AV1, and more Dolby Vision profiles than the Shield does at a much cheaper price. It also handles HDR10+ which the Shield doesn't but that for at isn't nearly as common and many of the big TV brands don't support it anyways.

My prediction is that this is more about banning VPNs than about age verification. Start with this, then when everyone is "using VPNs to break the law" they have an excuse to ban VPNs.

Governments world wide likely see VPNs as incredibly dangerous. Plenty of examples of countries like Iran cutting off the internet entirely to prevent protests from organizing.

I think they want their own great firewall.

Here

H2i® models provide heating, even in outdoor temperatures as low as -13° F, producing up to 100% heating capacity at 5° F. These units offer year-round comfort even in extreme climates

Their technical documents show that they are down to about 20% of their usual heat output at that lowest temperature so they need to be sized up accordingly. The reality for most folks in an area cold enough to require these is they have backup heat sources for the coldest days anyways.

Nope, the switch only keeps saves on the internal storage or synced to their cloud if you pay for it. When doing transfers between devices like this there is no copy option only a move and delete.

There are some legitimate reasons they want to prevent this like preventing users from duplicating items in multiplayer games, etc. Even if you got access to the files they are encrypted so that only your user can use them.

I think the bigger reason they do this is there are occasionally exploits that are done through corrupted saves. So preventing the user from importing their own saves helps protect the switch from getting soft modded.

If you mod your switch you can get access to the save files and since it has full access it can also decrypt them, so that you can back them up. One of several legitimate reasons to mod your switch.

If you are just looking to repurpose an old device for around the house use and it won't ever be leaving your home network, then the simplest method is to set a static IP address on the device and leave the default gateway empty. That will prevent it from reaching anything other than the local subnet.

If you have multiple subnets that the device needs to access you will need a proper firewall. Make sure that the device has a DHCP reservation or a static IP and then block outgoing traffic to the WAN from that IP while still allowing traffic to your local subnets.

If it is a phone who knows what that modem might be doing if there isn't a hardware switch for it. You can't expect much privacy when that modem is active. But like the other poster mentiond a private DNS server that only has records from your local services would at least prevent apps from reaching out as long as they aren't smart enough to fall back to an IP address if DNS fails.

A VPN for your phone with firewall rules on your router that prevent your VPN clients from reaching the WAN would hopefully prevent any sort of fallback like that.

I've got about 30 zwave devices, and at first the idea of the 900mhz mesh network sounded like a really solid solution. After running them for a few years now if I were doing it again I would go with wifi devices instead.

I can see some advantages to the mesh in a house lacking wifi coverage. However I would guess most people implementing zigbee/zwave probably have a pretty robust wifi setup. But if your phone doesn't have great signal across the entire house a lightswitch inside of a metal box in the wall is going to be worse.

Zwave is rather slow because it is designed for reliability not speed. Not that it needs to be fast but when rebooting the controller it can take a while for all of the devices to be discovered, and if a device goes missing things break down quickly, and the entire network becomes unresponsive even if there is another path in the mesh. Nothing worse than hitting one of your automations and everything hangs leaving you in the dark because one outlet three rooms over is acting up.

It does have some advantages, like devices can be tied to each other (i.e. a switch tied to a light) and they will work even without your hub being up and running (zwave controller I think can even be down).

Zwave/Zigbee also guarantee some level of compatibility/standardization. A lightswitch is a lightswitch it doesn't matter which brand you get.

On the security front Zwave has encryption options but it slows down the network considerably. Instead of just sending out a message into the network it has to negotiate the encrypted connection each time it wants to send a message with a couple of back and forth packets. You can turn it on per device and because of the drawbacks the recommendation tends to be, to only encrypt important things like locks and door controls which isn't great for security.

For Zwave 900mhz is an advantage (sometimes). 900mhz can be pretty busy in densely populated areas, but so can 2.4 for zigbee/wifi. If you have an older house with metal boxes for switches/plaster walls the mesh and the 900mhz penetration range may be an advantage.

In reality though I couldn't bridge reliably to my garage about thirty feet away, and doing so made me hit the Zwaves four hop limit so I couldn't use that bridge to connect any additional devices further out. With wifi devices connecting back to the house with a wifi bridge, a buried Ethernet cable, etc can extend the network much more reliably. I haven't tried any of the latest gens of Zwave devices which are supposed to have higher range.

The main problem with wifi devices is that they are often tied to the cloud, but a good number of them can be controlled over just your LAN though. Each brand tends to have their own APIs/protocols though so you need to verify compatibility with your smart hub before investing.

So if you go the wifi route make sure your devices are compatible and specifically check that your devices can be controlled without a cloud connection. Especially good to look for devices like Shelly that allow flashing of your own firmware or have standardized connection methods in their own firmware (Shelly supports MQTT out of the box)

Likely that the browser they were pointed at went missing (executable moved or something), or was crashing at launch, and this is just Windows saying "I can't find the default you wanted so I am falling back to Edge, otherwise a lot of stuff is going to be broken".

https://spotifyshuffler.com/

You can use sites like these to randomize your playlist. You can have it randomize the playlist or create a randomized copy if you want to keep the original.

I usually start the playlist, turn on their crappy shuffle to get me to a random position in the randomized playlist, then disable their profitability maximizer shuffle.

Credit unions use the NCUA instead of FDIC. So if they don't go after that as well there are still some options.

It's presumably to give you legal ground to sue if some corporation scrapes Lemmy content and uses it to train AI, or whatever other commercial purpose.

Hopefully if enough people do it they would consider the dataset too risky to use. They could try and parse out comments that have that license statement but if any get missed somehow they open themselves up to lawsuits.

That would force them to instead pay for content from somewhere that has a EULA forcing the users to hand over copyright regardless of what they put in their posts (i.e. Reddit).