From julian at precisium.com.au Thu Jun 23 20:32:13 2022 From: julian at precisium.com.au (Julian Noble) Date: Thu, 23 Jun 2022 20:32:13 +1000 Subject: [BUGS] An ideal filesystem, as seen on my FreeBSD/ZFS NAS. In-Reply-To: References: Message-ID: Hi All After 20+ years of part time freebsd adminery in a vacuum (no colleagues as far as admin/IT) I still don't feel qualified to have an opinion on ideal. I used to have various folders at the root level - and have more recently kept nearly all customisations that don't relate to me as a user in a single folder under /usr/local/ Syncing non-system specific things to a single area and linking from home sounds reasonable. Now that we have mature zfs support in FreeBSD - with fantastic things like boot environments for rollback, zfs on root with mirrors etc? and zfs send & receive - I feel much more comfortable in the longevity of particular vms. For example, before, I tended to backup the minimum necessary and if the worst came; it was time to rebuild a whole system with a newer release. Now - I have most things in jails (iocage) or bhyve vms synchronised between a few main hosts by syncoid - which uses zfs send receive. With a bit of scripting (famous last words!) I expect to be able to 'migrate' a vm/jail to another physical machine - or to a 3rd party cloud system without manual tweaking Freebsd/opnsense support for vxlans is great for migrating whilst keeping the same IP address even on systems spread across a few different subnets in the underlying fabric. (Not that DNS updates/ip changes aren't scriptable - but it's nice to have the option to keep that significantly simpler ) Anyway.. all that goes to say I'm not sure what I'd be syncing on a broad basis to these machines. If I used multiple freebsd *desktop* systems it'd make sense I guess - but my intention for most common things I need (generally scripts) is to put them in gitlab and pull/push them as I need. I think this is the sort of thing that would be easier for me to digest/consider as a chat at a meetup. Without the casual talking to people about different ways they do things - I don't really get why certain things I do might be clumsy or better solved in completely different ways. There are so many (usually outdated) how-tos on the net, which are often short on the 'why' you'd want to do it that way. I'm left a little that way here regarding an 'ideal' filesystem too - probably because I'm missing various bits of understanding about the way people do things. I would think that the ideal system is mainly something that doesn't get in the way of upgrades and makes sense to the individual/admin especially when something goes wrong - so that compounding errors aren't made in a panic. Another ideal might be one that's intuitive, say in a corporate environment, for others to navigate their way? around and understand what should live where and why. Presumably mindshare with others is a desirable feature ... hence I guess trying not to violate the guidelines too much in 'man hier (7)' makes some sense - even though I've never managed to understand its logic fully. I have a vm running nextcloud with which I sync various folders to workstations for myself and others - and some generally-work-related samba shares which I intend also to sync with nextcloud to make easy use of some features such as OCR etc. I'm probably just not yet using 'home' folders correctly in windows or freebsd - so It's not immediately obvious to me what the scheme below might do for me... and how one would create/maintain these symlinks for other users. Do they get a standard set of symlinks and that's it?? What's to stop users from just creating folders straight in home and making it a mess because they're surprised something's not synced when one day they needed it to be? Ideally for me - the folders Documents, Pictures etc would be under a subfolder, the name of which clearly indicates it's synchronised - but I'm guessing that idea collides with the way most desktop systems work. I just have a completely separate folder for people outside of home; the entirety of which they know is synced... but that's probably only passably ok because my users currently log in at dedicated workstations... I guess I'll learn more about it when they need to have hot desks :P As always.. trying to see the bigger picture going forward is hard, and it's sometimes easier to get stuck into building something that just works reasonably for now. I still don't know if that's entirely good or bad...? perfect is the enemy of the good and all that! Cheers, Julian On 2022-05-26 5:46 pm, Mr Andrew Sinclair wrote: > Given that the fate of this mailing list has come into question, I offer > for debate, a map of an ideal file system. > > The gist of it is, (1) we start by adding a folder named /sole/ to the > system root. This folder is always kept in sync between all hosts under > your control via unison or syncthing. It will never be touched by the > operating system. The /sole/ folder should contain no vendor > interpretations of what should be in the user folder by default; Melodies, > Pictures, .config, .local; that kind of thing. If it does contain any files > influencing system activity, they would be symbolic links to files the > operator is comfortable to synchronise in a heterogeneous environment. I > keep my rclone configuration in such a folder. > > The /home/ folder retains its original purpose for system generated files > deemed impractical for synchronisation; that is to say, application > configuration and cache folders specific to one host. > > (2) We can then speculate on four root-level folders that ought to be seen > on a NAS, running FreeBSD with a ZFS root ideally. > > YYYY,WW:2022,21; > ________________ > /internet/ > ./file// > ./archived// > ./sqlite-autoconf-3380500.tar.gz -> > ../../https/www.sqlite.org/2022/sqlite-autoconf-3380500.tar.gz > ./backup// > ./cygwin--setup-x86_64.exe -> > ../../https/cygwin.com/setup-x86_64.exe > ./curate// > ./00, The Global Menu// > ./10, Resource 1// > ./cygwin--setup-x86_64.exe -> > ../../https/cygwin.com/setup-x86_64.exe > ./20, Resource 2// > ./sqlite-autoconf-3380500.tar.gz -> > ../../https/www.sqlite.org/2022/sqlite-autoconf-3380500.tar.gz > ./99, your choice please// > ./database// > ./internet.sql > ./internet.sqlite > ./revision// > ./github.com// > ./git// > ./git// > ./svn.freebsd.org// > ./base// > ./stable// > ./software// > ./java// > ./netbeans// > ./eclipse// > ./libreoffice// > ./ftp// > ./ftp.freebsd.org// > ./pub// > ./http// > ./www.w3.org// > ./standards// > ./https// > ./cygwin.com// > ./setup-x86_64.exe > ./www.sqlite.org// > ./2022// > ./sqlite-autoconf-3380500.tar.gz > > /intranet/ > ./0,common// > ./file// > ./archived// > ./2000-00-00--00-00-00--mywork.txz > ./backup// > ./mywork.txz > ./curate// > ./00, The Regional Menu// > ./10, Option 1// > ./mywork.txz -> ../../backup/mywork.txz > ./20, Option 2// > ./2000-00-00--00-00-00--mywork.txz -> > ../../archived/2000-00-00--00-00-00--mywork.txz > ./99, your choice please// > ./database// > ./common.sql > ./common.sqlite > ./revision// > ./myrepo// > ./software// > ./mysource// > ./ftp// > ./http// > ./https// > ./1,personal// > ./2,professional// > ./3,public// > ./file// > ./curate// > ./00, The Public Menu// > ./99, your choice please// > ./database// > ./public.sql > ./public.sqlite > ./ftp// > ./http// > ./https// > ./afs// > ./nfs// > > /host/ > ./$(hostname --domain)// > ./$(hostname --short)// > ./etc// > ./var// > ./home// > ./cccc// > ./.config// > ./.local// > ./tttt// > ./.unison// > ./____// -> ./cccc// > ./@@@@// -> ./tttt// > /user/ > ./home// > ./cccc// > ./.config// > ./.local// > ./Audios// -> ../../sole/cccc/common/Audios// > ./Documents// -> ../../sole/cccc/document// > ./Downloads// -> ../../sole/cccc/download// > ./Music// -> ../../sole/cccc/common/Music// > ./Pictures// -> ../../sole/cccc/common/Pictures// > ./Videos// -> ../../sole/cccc/common/Videos// > ./tttt// > ./.unison// > ./____// -> ./cccc// > ./@@@@// -> ./tttt// > ./sole// > ./cccc// > ./common// > ./Audios// > ./Melodies// > ./MultiMedia// > ./Pictures// > ./Videos// > ./config// > ./dot// > ./.config// > ./.local// > ./etc// > ./zsh// > ./document// > ./ATO// > ./IRS// > ./download// > ./file// > ./paid-app// > ./paid-pdf// > ./ftp// > ./http// > ./https// > ./tttt// > ./dot// > ./.emacs// > ./.vim// > ./etc// > ./zfs// > ./____// -> ./cccc// > ./@@@@// -> ./tttt// > ________________ > _______________________________________________ > BUGS mailing list > BUGS at bugs.au.freebsd.org > https://www.rulingia.com/mailman/listinfo/bugs From julian at precisium.com.au Fri Jun 24 03:34:30 2022 From: julian at precisium.com.au (Julian Noble) Date: Fri, 24 Jun 2022 03:34:30 +1000 Subject: [BUGS] Hello In-Reply-To: References: <20211231002949.21f2cefc@ws1.wobblyboot.net> <4436350.kJ8LgFSmm2@direwolf.home.arpa.> <20211231235100.GI75481@eureka.lemis.com> <20220101112520.6a837e64@ws1.wobblyboot.net> Message-ID: I loved usenet...? a long time ago. I have vague hopes that advancements in AI spam detection will solve this..? but suspect that to get the nuances right requires sentience. That's not a task I'd wish on any sentient being ;) Open source alternatives such as discourse or jitsi might be worth looking into. I'm inclined to steer well clear of discord. (professionally I'm required to avoid it. If you have any clients in the defence industry then the tencent ownership is a showstopper) The 'reds under the bed' thing aside - my nephew tried to get me to use discord, and the politest thing I can say about the UI is that it's an ill-considered mess of sheer derangement! Cheers, Julian On 2022-05-22 1:48 pm, Andrew Reilly wrote: > Usenet is still going, kind of. I really liked it as a format and mechanism, but haven't actually run a client, and pointed it at a server for many years. > It never recovered from the Endless September, and the last vestiges of signal-to-noise ratio disappeared under a tsunami of spam and machine-generated messages. Turns out that free (as in lacking an identity mechanism or login process) access combined with no mechanism to filter spam or moderate conversations is not a good match to the modern age (well, there is a moderation mechanism, but it relies entirely on human volunteers). We can't have nice things. > > Just like email, dragging the thread context around as quoted text seems ever-more archaic: that's something that the messaging system ought to be handling for us, and what forums and chat servers do now handle. Discord seems to fill the usenet niche now, although it's another of the socials that I haven't bothered trying out. Currently gaining some mass-media fame as the discussion forum of choice for right-wing terrorists and mass murderers. I guess discord doesn't have its moderation story entirely sorted yet either. > > Cheers, > > Andrew > > >> On 22 May 2022, at 13:08 , Mr Andrew Sinclair wrote: >> >> While on this subject, if the issue is hosting fees, I have two business >> hosting accounts with VentraIP prepaid for the next two years; each with >> 4GB ram and 5GB disk minimum. I have them for development purposes and a >> not-for-profit mailing list or two is most certainly welcome there. Perhaps >> it might be an opportunity for me to lessen my dependency on Google/Outlook >> as I figure out how mail servers actually work? >> >> On the subject of the more popular medium, I wouldn't mind seeing a return >> of the USENET style newsgroups which to me were the ideal platform for this >> mailing list. What happened to this news protocol? >> >> >> On Sat, 1 Jan 2022 at 11:25, matti k wrote: >> >>> Oops I sent using an off list email account (not sure how it got >>> approved, some nice moderator i guess) so may have missed replies ... >>> >>> On Sat, 1 Jan 2022 10:51:00 +1100 >>> Greg 'groggy' Lehey wrote: >>> >>>> On Friday, 31 December 2021 at 13:11:51 +0800, Alastair Hogge wrote: >>>>> On Thursday, 30 December 2021 9:29:49 PM AWST matti k wrote: >>>>>> Hi all, >>>>> Hey Matti and *, >>>>> >>>>>> We are thinking about closing this down due to, well lack of >>>>>> interest. >>>>> Closing the mailing list? >>>>> >>>>>> Is it a good idea? >>>>> Due to a lack of interest, perhaps. If it has become a burden, then >>>>> kill it with fire :-D Maintaining something of no use is rather >>>>> pointless tho. >>>> I think this is more a case of "if it ain't broke, don't fix it". >>>> Unless I'm missing something, maintaining a list costs effectively >>>> nothing. Maybe people might find us by it. >>>> >>> I think the issue is with mailman-2.x which requires work to migrate >>> from >>> >>> >>> >>> _______________________________________________ >>> BUGS mailing list >>> BUGS at bugs.au.freebsd.org >>> https://www.rulingia.com/mailman/listinfo/bugs >>> >> _______________________________________________ >> BUGS mailing list >> BUGS at bugs.au.freebsd.org >> https://www.rulingia.com/mailman/listinfo/bugs > > _______________________________________________ > BUGS mailing list > BUGS at bugs.au.freebsd.org > https://www.rulingia.com/mailman/listinfo/bugs