Unless you're already an expert in the topic a literature search is literally step 1 since you have to check if your idea has already been done before.
That's where your supervisor comes in. In most cases, they should be an expert in the field, and guide you towards a useful and novel problem.
Moreover, I am not suggesting you don't look at other papers at all. But google scholar and some quick skimming of abstracts and papers you find should suffice to check if someone has already done the work. If you start fully reading more than a handful of papers, your ideas are already locked in by what others have done, and it becomes way harder to produce something novel.
It's not that hard. You can literally use any old computer. I was home labbing long before I became a SWE. Something like Ansible can make deterministic bare metal config that could be accessible to more people.
I find home IT / tech support questions are a fantastic use of AI. AI helps me mess with all these different configs and figure out what the source of a problem is, when I give it the symptoms I am seeing in my network.
So, I hope someday that people can buy a box with a local AI tech support assistent which can make it even more accessible to set up a personal cloud. This will happen gradually, first with people on the high-end margins of technical capability, then moving downwards until a curious high schooler can set it up for themselves and keep it with them, letting them stay out of the corporate cloud for most of their life more and more.
RustFS is the poster child in my mind for the worst kind of vibe-coded slop. it might be "simple" but it's not something I would ever trust with persistent data.
last year they had a security vulnerability where they allowed a hardcoded "rustfs rpc" token to bypass all authentication [0]
and even worse, if you read the resulting reddit thread [1] someone tracked down the culprit commits - it was introduced in July [2] and not even reviewed by another human before being merged.
then the fix 6 months later [3] mentions fixing a different security vulnerability, and seemingly only fixed the hardcoded token vulnerability by accident. that PR was also only reviewed by an LLM, not a human.
I am building an S3 client [1] where I have a test matrix that tests against common S3 implementations, including RustFS.
That test matrix uncovered that post policies were only checked for exsitence and a valid signature, not if the request actually conforms to the signed policy. That was an arbitrary object write resulting in CVE-2026-27607 [2].
In the very first issue for this bug [3], it seemed that the authors of the S3 implementation didn't know the difference between the content-length of GetObject and content-length-range of a PostObject. That was kind of a bummer and leads me to advise all my friends not to use rustfs, though I like what they are doing in principal (building a Minio alternative).
I am writing an s3 server, just checked, have detailed tests for content-length-range. I found that Ceph was the only open source implementation with decent tests, and I ported these as my first stages of implementation, although I have since added a lot more. Notionally rustfs say they use the ceph test suite, but not sure how often and completely, they certainly had big conformance gaps.
Consumerism is the problem. If fossil fuels were used on necessities sure. Single use plastics, individually packaged consumables, planned obsolescence are examples of things that are not necessary. These examples have all to do with shareholder value.
Consumerism is not the problem. Human beings don't stop wanting to improve their lives once they have the bare necessities and there is nothing wrong with this.
We can have our cake and eat it, we just need to transition to cleaner forms of energy. Which we are doing.
