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 :)
From what I understand: CasaOS is simply an abstraction layer and takes away a lot of the manual work.
I agree with you that this shows down learning quite a bit.
I see three ways forward for you:
a) switch to a Linux base system, Debian, arch, nixos, whatever resonates and set up everything from scratch. High learning curve but no more hidden things.
b) same as a but as a separate setup. This is what I would recommend if you have the time and cash. Replicate what’s already working and compare.
c) figure out how to do things manually within the CasaOS framework. Can’t help you there though :)
The first link goes into amazing detail on that. In short: all your information concerning location as well as current IP and some other metadata gets send to a basically unknown company with no transparency on how that data is handled.
I highly recommend reading the first, linked post though!
Cups
linux printing server - if you want to share a printer over network or just use one locally on a linux machine.
(not OP but same boat) Doesn’t really matter to me because google knows my servers external IP which is a non-issue: I don’t expect google to try to attack me individually but crawl data about me. There is no automatic link between my server and my personal browsing habits.
In terms of attack vector vs ease of use , self hosting searxng is a nobrainer for me - but I do have an external server available for things like that anyway so no additional overhead needed.
A Dockerfile itself is the instruction set. There is a certain minimum requirement expected from a server admin that differs from end-user requirements.
The ease of docker obfuscates that quite a bit but if you want to go full bare metal (or full AWS or GCS, etc etc) then you need to manage the full admin part as well - including custom deployments.
No worries I phrased that quite weird I think.
A NAS is only more power efficient if the additional power of a full server is not used. If for some reason the server is still needed than the NAS will be additional power consumption and not save anything.
(for example I run some quite RAM and compute heavy things on my server which no stock NAS could handle I think).
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.