For me it’s the Mac Finder. It’s always running so (unless it crashes) there’s no delay in opening a file manager window and, more importantly, it has built in Quicklook and Miller columns. Haven’t managed to find a good-enough implementation of either of those in Linux, so I just work around it.
Linux runs fine on Intel Macs. There are a couple peculiarities you’ll want to be aware of, though.
Other than those initial hiccups, everything works pretty flawlessly.
To amplify RedWeasel’s very good answer, fstab runs as root and unless you specify otherwise, the share will mount with root as the owner on the local machine. From the perspective of the Samba server, it’s the Jellyfin user accessing the files, but on the local machine, but local permissions come into play as well. That’s why you can get at the files when you connect to the share from Dolphin in your KDE system—it’s your own user that’s mounting the share locally.
Kate is really a hidden gem. It’s so light weight and just gets out of the way. I’m now installing it everywhere—Linux, Mac, or Windows.
You could likely use dd or clonezilla to create a duplicate of your boot drive and boot your laptop right from that, but that’s not quite what you’re after.
There are some distros lately that use a declarative config file to set the whole thing up that I think is much more what you have in mind. The big ones that come up a lot are nixOS and Fedora Silverblue. Maybe one of those systems would be to your liking.
That’s awesome, I’ll definitely be interested to see how it all works out.
Yeah, I started working on it once a couple years ago and getting it spun up was a chore. Life got busy and I never finished.
That imapbox looks pretty interesting. Thanks for tracking that one down.
So I think the way I would want to do this is with something like mailpiler (https://www.mailpiler.org/). It’s been on my long list of things to dive into for a while.
It’s managed service provider, which translates more or less to a company that handles IT for other companies.
My experience has been mostly positive. I hit a situation a couple times where a particular app hanging will prevent other flatpaks from launching. That took a while to figure out, but otherwise it’s pretty good. In general things work the way they’re supposed to.
My only experience with homebrew is on macOS and I’ve switched to MacPorts there. Homebrew did some weird permissions things I didn’t care for (chowned all of /usr/local to $USER, if I’m remembering right). It worked fine on a single user system, but seemed like a bad philosophy to me. This was years ago and I don’t know how it behaves on Linux.
I also prefer Firefox, but when I need a Chromium alternative for testing, I opt for the flatpak (or the snap) version personally.
I’ve got one running in a Proxmox cluster. Getting it setup was a bit particular (due to the T2 chip if I remember correctly), but it’s be working flawlessly. I use the quick sync feature of the iGPU for my jellyfin container.
If you were going to buy something new, I think there are more cost effective boxes of about the same size and spec, but if you’ve got it already, you should definitely start playing with it.
This is exactly what I use as well. It’s pretty awesome. Backup and restore work like a charm.
Good catch! I completely misread that bit.
It sounds like you’re seeing a few different issues here and it makes me wonder if there’s some hardware issue that’s causing some of this or if the installation is botched (though it’s be odd for that to hose two different distros.
Last time I looked Debian didn’t include sudo by default, so you’d have to install it first. To add yourself to the sudoers group, log in as root and run usermod -aG sudo mariah (assuming that’s your username). Then reboot (logging out your user should work too, but better be thorough).
Grub sometimes includes a timeout longer than I like and you can edit that in the /etc/default/grub file to something of your liking.
Not sure what you mean about the commands, but maybe it’s an issue with your $PATH.
I keep my dotfiles in a got repo and just do a git pull your update them. That could definitely be a cron job if you needed.
SSH keys are a little trickier. I’d like to tell you I have a unique key for each of my desktop machines since that would be best practice, but that’s not the case. Instead I have a Syncthing shared folder. When I get around to cleaning that up, I’ll probably do just that and keep an authorize_keys and known_hosts file in git so I can pull them to needed hosts and a cron job to keep them updated.
On the crazy low-scale end, I have a no-name dash cam that I found for $5 on a tchotchkes table at my local Chinese takeout place. It works perfectly with my Linux desktop—both reading from the SD card and streaming directly via USB. Not at all what you’re looking for, but it makes me think that if this random junk works, more mainstream devices probably do too.
Oh, gotcha. In that case, maybe a PXE boot server would be worth checking out.
The thing that comes to mind is setting up a block device as an iscsi target on your NAS. That would present the storage to you as though it’s another hard drive that you can format and map in windows. Then you can save vms there as though it were directly connected.
Take this with a grain of salt, the more I re-read, the more I realize I’m making assumptions about your setup that may or may not be true. First, I’m making an assumption that you’re doing ACLs for samba shares (and I know that system better on FreeBSD than Linux). I’m also assuming based on your description you want everyone to have access, but not write access.
I think you could do an
officewidegroup with read-only permissions on all of the shares and then set the unix group to the department.So, for your HR team you’d do
chgrp -R hr /path/to/parent/shares/hrandsetfacl -m d:g:rwx /path/to/parent/shares/hrand add theofficewidegroup’s read-only perms:setfacl -m d:g:officewide:rx /path/to/parent/shares/hr. Rinse and repeat for each share.Not sure if this is what you’re after, but maybe it’ll help lead in a good direction.