BoySka
BoySka
Here it is: - https://www.radio-browser.info/history/ce63c422-128b-4f5b-a1e9-d6ee49f2b9a3 - http://s.streampunk.cc/ondarossa.ogg - http://www.ondarossa.info/ - http://www.ondarossa.info/streaminfo.json thanks!
Hello! is there any news about it? Is there any wayy I can help?
I find `-t` perfectly fine for specifying filesystem. I don't think there's any need for saving this informations; linux should autodetect how to mount filesystems. I think FAT is great...
On a computer, my UID is 1001. On another one, my UID is 1002. Sharing a tomb between these two computers is a pain. FAT would solve these problems.
> any other reason you like to put forward to advocate use of FAT? > > nope. That is the only one. I'll doublecheck the chown you pointed me
I agree that the cases for multiple owner are not much; I can not say the same thing for the mode; therefore, I propose ``` sh chown -R ${_uid}:${_gid} ${tombmount}...
can we remove the multiple slots functionality? how? however: to add a slot, a key must be provided.
hellekin: yes, I thought about that, too (but is not a solution for the passwd problem). However, maybe is just easier to use the same luksKey, but encrypted with a...
No, I think that removing the header won't make it harder IF all the valid keys to open the tomb are on your control. IIRC, the header is an asymmetrically-encrypted...
the "backup" scenario is indeed very useful