H@nickname lets continue the discussion here, maybe get to brainstorm one day when i dont need to focus on the other tasks i put on myself :p
Tloool if you ever feel like you want to procrastinate on other tasks, then this exists. like i said i am wiling to help you on this any way i can
Ti love this idea
Hmy idea would be to to ignore any devices in /etc/fstab
all other devices can be found from probing /dev/disk/by-id/
this will show the disk and serial number so it will help people identify the right disks too
all other devices can be found from probing /dev/disk/by-id/
this will show the disk and serial number so it will help people identify the right disks too
Tthat's a good plan actually
Twanna add this here too:
Tso we have everything in 1 place
Hyeah but it is going to be hell to implement since i need to check fstab then check all the /dev/disk nodes for which disk is what and exclude them then probe again 
NSo to clarify, what is the goal here?
Thave any secondary drives automount at startup
Ha simplified way for normal people to just get automounting secondary drives working
Hsince the kde partition ui is kinda trash for it and normal users just need common options
Ttelling users to edit fstab, use systemd.mount, or messing around with kde partition manager hasn't been too successful
Tgnome disks works well but that only comes preinstalled on gnome, so when a kde user asks it seems a little bizarre to go: 'yeah layer
gnome-disk-utility'Tbut that GUI is the most simplified way of doing that out of the other 3 choices
Hyeah so i figured i might look into making something in golang that lets you add systemd mount units for disks that you have not added to /etc/fstab
Hand it will have tailored options that are generic and the most commonly needed like compression for btrfs and the ssd flags and such (and subvolume)
Hfor ext4 i need to remember what the normal options are 
Hand for ntfs just make sure stuff will be readable and executable and such
Hand that should cover like 80% of the usecases
Toh this might be a monster of a project
Ti forgot about different filesystems 
NAlso you will need packages for NTFS
Hntfs is supported out of the box
NProbably why no one has done it
Toh yeah wait is this only going to be for bazzite or upstream ublue
Hperfect that the guy that tries to generalize and automate vfio for normal people is the one that will torture himself through it
NIdeally I would see this as an upstream project that any distro could use.
Hbazzite since it seems to be a bazzite "problem" mostly since we might not be allowed to add it to kinoite
Hoh deffinitively
Hbut its in golang and some people are iffy about that
Hi rather not make it in python and have to deal with those dependencies 
Tok yeah i get it now. i only asked because of the NTFS packages that may have to be added and i dont think upstream wanted to add those dependencies
Hespecially since i know the qt framework meaning it would be pyqt or something
Tbut yeah any project can use it
Hi rather so golang so i can learn something new 
Hand have it portable with minimum dependencies
Halso these are the different things i need to test for ontop of /dev/nvme and /dev/sdX
Hand the various ways to write it out in the fstab file
Hjoy
Hit is a definitive not soon
Tit's not a priority. i might complain a lot but im not contributing much. ping me here for anything since i am interested in the project whenever you have anything new 
Hyeah it is not a priority but it is something i want to look into
NThe docs you've been contributing have been excellent. Don't sell yourself short. It's really important
Hdocumentation is important
Hit is so important that i document most of my code inside my programs and i am verbose with it
Hmainly so that i can return to it way later and go oh yes thats how it worked
NWho wrote this? Oh no, it was me wasn't it?
Hi mean you can look at my first big project
HGitHub
A git repository for the RuneScape Linux/Unix Client Project - rsu-client/rsu-client
