I use systemd mount files instead of fstab, that way I can specify a network dependency in the off chance there’s no network connection. Plus I can have other services like jellyfin depend on that mount file so it starts after the share is available.
Those instructions are from the official docs, and install.sh comes from the source repo. It’s an annoying script (it basically runs apt, npm, make, on your behalf…thanks, I can do that myself), but if you’re trusting the repo source to begin with, I don’t think it’s any less secure.
As of next month, I’ve been using Chromebooks for 10 years however I also came to the same conclusion re: Google/ChromeOS over the summer.
Initially, I bought a Windows laptop but the keyboard layout (specifically the function keys) felt absolutely foreign, even after I wiped it and installed Debian. In retrospect, my theory is that a $500 Chromebook has worse internals but a much better keyboard/trackpad than a Windows equivalent, and that the keyboard layout is more user-friendly in a browser-first world. Eventually, I went back to my Chromebook but with a twist.
I’m biased, but since you seem like you know your way around Linux and tinkering, one suggestion that hasn’t been mentioned is that you buy a new Chromebook and turn it into a Chrultrabook (aka a Chromebook w/ ChromeOS completely wiped & replaced w/ Linux).
I’ve been running one of the last few months and it’s been an overall pleasant experience. Perhaps most important for me is that the tutorial includes keyd to reprogram the keyboard shortcuts to mirror the Chromebook layout. The community is growing and responsive, especially on the Linux side.
Thanks for the resources. I think this could be the way forward. I’ll do some research first, as I need something super stable, since I won’t be the final user. So if it breaks, I’m on the hook.
Do you have any suggestions on possible candidate Chromebooks?
I just did some digging on Best Buy and Amazon for sales, but mostly came across larger models or models that were MediaTek/Snapdragon (the chrultrabook team almost exclusively works on intel devices).
I’d say your best bet is to go to the supported devices list, and Ctrl + F for ‘13’ or ‘11’ to highlight the smaller-sized chromebooks and then check to see what’s available, or to jump in the Discord and pose the question to those in the linux channel
Nice. That’s the move. I am finding it more and more difficult to find smaller laptops/chromebooks these days. If I want a big screen, I’ll sit down at my desktop!
I’m using docker packages for Doom Emacs. The main one is docker.el. On top of being faster and easier to use than the cli, you can also do some pretty neat stuff like use dired+tramp to browse files and open them in Emacs.
Dell inspiron 15, unfortunately. Going for about $300 the last time I checked, add in another stick of RAM and an SSD, perfect linux machine right there
How about a used Thinkpad? Like the X280. 12.5". Touch. Depending on your region you can get a pretty good deal if you are OK with some scratches or other faults
Ah I gotcha. Another option im considering is using a separate pc for windows and using a kvm to switch between them. That may be a good option for you as well if you can swing it.
Would’ve been nice of them to compile the kernel with a fix applied to see how much of an impact it has (though even in the post they seem to suggest that it’s not that impactful unless you run massive clusters)
I’m curious, what file system do you use to mount your share? (SMB, SSHFS, WebDAV, NFS…?) I’ve never managed to get decent performance on a remote-mounted directory because of the latency, even on a local network, and this becomes an issue with large directories
Like iSCSI, it exposes a disk image file, or a raw partition if you’d like (by using something like /dev/sda3 or /dev/mapper/foo as the file name). Unlike iSCSI, it’s a fairly basic protocol (the API is literally only 9 commands). iSCSI is essentially just regular SCSI over the network.
NFS and SMB have to deal with file locks, multiple readers and writers concurrently accessing the same file, permissions, etc. That can add a little bit of overhead. With iSCSI and NBD, it assumes only one client is using the file (because it’s impossible for two clients to use the same disk image at the same time - it’ll get corrupted) and it’s just reading and writing raw data.
main thing to note is that NFS is an object based storage (acts like a share) where iSCSI is block based (acts like a disk). You’d really only use iSCSI for things like VM disks, 1:1 storage, etc. For home use cases unless you’re selfhosting (and probably even then) you’re likely gonna be better off with NFS.
if you were to do iSCSI I would recommend its own VLAN. NFS technically should be isolated too, but I currently run NFS over my main VLAN, so do what ya gotta do
Yeah, there are a few limitations to each. NFS, for example, doesn’t play nicely with certain options if you’re using a filesystem overlay (overlays), which can be annoying when using it for PXE environments. It does however allow you to mount in several remote machines simultaneously, which I don’t think iSCSI would play nicely with.
SMB though has user-based authentication built in, watch can be quite handy esp if you’re not into setting up a whole Kerberos stack in order to use that functionality with NFS.
I’ve found that NFS gives me the best performance and the least issues. For my use cases, single user where throughput is more important than latency, it’s indistinguishable from a local disk. It basically goes as fast as my gigabit NIC allows, which is more or less the maximum throughput of the hard disks as well.
A benefit of NFS over SMB is that you can just use Unix ownerships and permissions. I do make sure to synchronize UIDs and GIDs across my devices because I could never get idmapping to work with my NAS.
idmap only works with Kerberos auth, but iirc I didn’t have to set anything up specifically for it. Though I’ve also never really had to test it since my UIDs match coincidentally, I just tested with the nfsidmap command.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.