Sounds reasonable. I’d you, like me, need to protect yourself from sabotaging your own system you could even make NAS documents read only to force a manual step in before editing there.
For me the amount of items that should be there are zero following my own concept … But for some (especially shared sheets specifically) I’m too lazy.
Perhaps I should listen to my own advice here zzz
Paperless specifically: yes, shoving everything in it.
But I have honestly no idea what kind of data you have that are suitable for paperless AND have different versions.
I just checked mine, for me it’s… Zero. Not a single item, by definition, is in Paperless that can receive an update.
If it’s updatable personally I have everything version controlled - and I mean EVERYTHING, from CV over tutorials to construction ideas - hosted locally on forgejo.
Hey, Welcome! You’re having a wonderful and sometimes exhausting journey in front of you :)
I’ll just brain dump based on your questions and my associations. Hope something useful is in between!
First the basic setup options because they tie into how to handle your date flow:
basic Most popular I think is docker compose: here I suggest splitting it into one compose file per service though with one file holding your port config. This prevents you yourself getting confused by your port mappings :)
Second in line is a proxmox setup - similar vein and I lack the hands-on experience to talk about the difference.
Then there’s the “everything native” approach where you don’t rely on containers but manage it yourself or via a dedicated OS that makes life easier (after the learning curve) like nixos.
DATA
All this foundational stuff is important because it changes your approach. In general: don’t fear data duplication. Duplicate it until you learn where you want your data to life and only then define your flow.
Specific example: after I got used to paperless I don’t look into my opencloud anymore, at all. I still duplicate them there but as distributed backup, not for consumption.
If a dataset has a clear place ten it’s easy. If not then your options are different depending on your setup: For the *arr stack the official recommendation is to use one shared folder and mount that into each part for example. I personally don’t like that and have hard links for everything - that’s basically a pointer to the file that looks like the file itself everywhere. As long as one pointer exists the file still stays on your drive but when the last pointer is gone, the file is effectively deleted. On Linux, you can think of every file this way but by default only one pointer exists (which often people test as synonymous to “the file”. Drawdown: this only works really well if you manually keep either track of which tool links where or you don’t containerize everything.
Again a specific example: My downloaded torrents never get moved - instead hard links are created into whichever path and naming scheme I defined for each consumer - this way, out of murdrrbot_07.mp3 a new author/series/booktitle.mp3 was created, both pointing to the same data and seeing it as a proper file.
But then there is one more thing: I suggest you split your thinking into data consumption and manipulation - because for the first, data duplication doesn’t matter. Especially for documents you’re talking about a ridiculous small amount of disk space and if it’s only reading/watching/hearing you as manager have no problem that data might exist multiple times.
If you want to keep it clean by design then you’re leaving the starter mode self holster - welcome to system design and infrastructure architecture! Here your approach could be to define lifecycles for each data type that you have. What a “data type” is in this context btw is a user term, NOT the underlying tech stack. You need to understand and document how an invoice should be treated and consumed by you differently than an invitation or a informal letter. Only then do you map file types, incoming channels, transformation steps, etc etc.
In my opinion: huge overkill to this upfront.
In short: spin everything up, observe how you use it and only then decide where things need to stay unique and cleaned up. Don’t break your head over something that’s actually quite easy to repair!
That’s sich a Mac answer it’s unbelievable.
Describing “A project aimed to be agnostic of it’s environment” as a design mistake and not a inherent flaw of the OS is… Just wow.
Remember in this thread it’s about the pro and con of Macos as interference hardware. This is a major flaw which comes baked into the hardware. I tested it and find it an unacceptable limitation. It’s important for others to know.
To state “containerization is the issue” though… Just wow.
Depends what you want to do… For example I didn’t get python whisper in a container to run on Mac in any way that can be called “performance” and I don’t want my dev workflow to optimize for an OS I despise :D
Hey,
Person here who despises electron apps in part because of the memory footprint and in part because I don’t like neither chromium nor node.js - personal preference mainly.
From your description I have the feeling that it’s unclear to your user base if electron is set or up to debate. There is only a thin line between “explaining” and “defending”.
In terms of communication: “We’re using electron as foundation because it allows us to focus on development. We’ve considered alternatives like Tauri and XYZ and opted in favor of electron.”
If there are situations that might make you rethink state those as well (“if someone provides a proof of concept via XYZ that an alternative is faster by y% while enabling us to still use (your core libraries and languages) we might consider a refactor.”
If you’d engage with me after an electron rant on your codebase you’d just raise my hope that I might change your mind! Don’t give people hope, don’t feed the trolls and do your thing!
Just please be honest with yourself: your app doesn’t use “50 to 60 MB”, it uses 500MBish on idle because of your choice. And that’s okay as long as you as developer say that it is.
Opencloud is the was to go from the established systems in my opinion. https://github.com/opencloud-eu
File sharing and -management for me has a higher level of trust and stability requirements. Syncin with four developers and “doing everything” while based on typescript makes me suspicious - but I haven’t tried it hands-on.
Traefik and caddy were mentioned, the third in the game is usually nginxproxymanager.
I’m using both traefik and nginx in two different setups. The nginxproxymanager can be configured via UI natively which makes checking configurations a bit easier.
Traefik on the other hand is configured easily within the compose itself and you have everything in one place.
This turned out to be tiresome though if you don’t have a monolithic compose file - that’s actually even hr history why I switched to npm in the first place.
I don’t have any experience with caddy so can’t provide anecdotal insights there.
I really like it already so take this as an alternative, not as improvement:l. I don’t have a good eye for aesthetics anyway don’t his is more about structure.
Personally I switched from a single dashboard to purpose driven hubs - I can’t imagine a situation where I need my infrastructure and my calendar at the same time regularly for example.
Another point is context typing: your release checker is quite far away from your appointments and calendar. It looks to me to be sorted by content rather then function (i.e. it’s entertainment so it’s next to YouTube). The same is true for your interaction patterns. There is a lot of visual information which I’m sure you’ll rarely interact with but instead consume. And then there are clearly external links, both bottom left (opencloud, tooling) and top right (external media) in addition to your own self hosted content.
My suggestion is therefore a process instead of a change: Note down when you consume which features of this awesome dashboard together for a few days. Then restructure the content of the whole dashboard based on your usage patterns - either as a new Monolith or even experimenting with splitting it.
I even suggest using a different medium then your usage device (if it’s a desktop PC mainly use pen and paper, if it’s your laptop use your phone, if it’s your phone you use this dashboard on then you might have different problems :D)
I’m not talking about usability, just about the foundation. Besides what others already said about why it’s not a good idea to answer your specific question regarij moderation tooling is:
Your requirements are incompatible with decentralization. Every moderation tool will have to use the network itself which means a moderation event has a significant delay in which the content has a “head start”.
There is no way to have an instant kill switch for content or a centralized gated release of content.
And at the end everyone can spin up an instance and decide on moderation, after all - and decide on the moderation rules there. This will cause an even bigger delay until the malicious instance is blacklisted by others.
If you do don’t trust em then don’t update syncthing - it’ll work for quite a while I assume.
And in addition the keepass safe default encryption of AES-256 and is even secure against theoretically existing quantum computer attacks to our current knowledge. It is designed to be not trusted by the storage owner :)
Fully understandable :D
To be honest for me the only reason to not go wired anymore is the firmware… I spent waaaay to much time figuring out the quirks of zmk and don’t want to repeat the same with qmk :D
Hey,
Good luck with your project and product!
Two informations I’m missing are firmware and shipping. You have a counter ticking down but I couldn’t figure what would happen then, really.
Overall it looks quite nice, but personally I’ll wait for a wireless version to start considering it. :)
As you have one opinion of corne too small I’ll join in to the opposite!
First off, yes, layers are something to get used to. As I came from the neo2 layout that was easier but I still recall the utter pain in the beginning.
But once the layers click … So does the board.
I think I spent more one than I’d like to admit building my zmk config but now I’m … Way slower than with a full board but it’s more fun and I feel getting better :D
You got a lot of relevant answers so I want to point out something else:
You’re hosting your own services. By yourself. Fuck everyone with a broom who tries to gatekeep that. And I don’t mean wooden side first.
Seriously, your question is on point here from my perspective and as long as it has a connection to running services by your own I personally would love more diversity in hosting solutions.
Personally, I’d love to see people share more about their provider agnostic opentofu deployment or someone who went all in on AWS lambdas for weird stuff.
And check for each music service their offered music. I’ve checked out tidal actually today with one of those export playlist tools and about 10% of my (honestly: niche) music wasn’t available.
Does that mean that an “all” view is "onl"y all of the subscriptions/places people from my server have?
That’s quite interesting.
And thanks!
No one forces unattended updates. And containerd is already living in the userspace.
If every dev would live on a kernel level stability approach we’d will not have a containerd release at all.
One thing that was only mentioned briefly by someone else is the physical button turning on the computer.
Similar to the paperclip test figure out where the power button goes into the mainboardw and bridge that with a short cable. Is possible that by moving the case the old button lost a cable.
This is just one more thing to test though, it’s really trial and error as you know :)
“not enough space in the used server for a standard power unit”
I wanted to put a dedicated graphics card in there for interference experiments - but the server is, well, a server - and those high availability PUs are expensive and a hell to cable manage
But a Dremel I had at hand … And a second PU as well. Now my server has a second power unit which is only powering the graphics card and is short circuited to be always-on.
self-made problems require self-made solutions.