Well, you are better off using Google Photos for securely accessing your photos over Internet. It is not a matter of securing it once, but one of keeping it secure all the time.
If cheap is what you are looking for, then yes, a wireguard running on your home server is the way to go. Instead of exposing your home-server directly to Internet, I would put it behind a cloudflare zero trust network access product (costs free).
Interesting blast from the past. We built an oblivious p2p mesh network that did this in 2010. Back then, nobody cared about security as much as we thought they should. Since then, nobody still cares about security as much as they should. Devices have increased and their value has increased, and still, they are quite insecure. Truly secure endpoints with hardware root-of-trust and secure chains of trust for authn/authz and minimal temporary privileges is still hard, and network perimeter security theater is still ongoing in home networks, corp networks and even large production datacenter networks. Only reason we don't find these to be the primary root-cause for security breaches is because more easier attack chains are still easily available!
Find Zen in mundane daily repetitive tasks. Avoid all screens for first hour after you wake up (and the hour before you sleep). Stay focused in the moment – focus on your body and mind. First/last thing everyday, do these activities with mindfulness – personal hygiene, exercise, gratitude/prayer, set positive realistic intentions for the day, set intention to act, prepare, eat/pack fresh healthy food.
Then start your materialistic business end of your day. Learn to breathe and keep your mind calm and present throughout the day. Watch/catch yourself if your mind runs wild with background threads – try and disable background jobs in your mind for a few weeks.
If you have a spouse/partner, discuss these goals with them and ask for their cooperation while you are trying to change your habits. Have realistic expectations, and be generous towards others.
Coming to materialistic business hours of your day, focus on problem-solving and living in reality.
Work through your own personal Maslov's hierarchy of needs. Be strategic, be realistic, and try to build a reasonable position of confidence. Then, launch yourself further from there. Don't overextend yourself.
I appreciate how you phrased this - I struggle most with 'mundane, daily, repetitive tasks.' Approaching them with intentionality and presence of mind seems good, if not difficult.
The most common lock and key ergonomics that everyone is familiar with is the following:
1. You have a lock, you have a corresponding physical key. You can have more identical physical keys. All of them will unlock the lock. If you lose the physical key, you can call the locksmith to change the lock. Physical key is anonymous. Only you know which key unlocks which lock. If a random person finds your physical key on the street, they shouldn't be able to find their way to your lock to try and unlock it.
2. That's all well and good. Now, comes a magic key. That's your personal magic key. Any lock you are permitted to unlock, your magic key can unlock it. Any key you are not permitted to unlock, your magic key cannot unlock. Now, you can more than one magic key – where only some of the locks you are allowed to unlock can be unlocked by one magic key vs another.
And if you happen to lose your magic key, you can call your locksmith to cancel your magic key – actually, that's a keysmith than a locksmith!
3. Your magic key is still anonymous. Only you know which magic key can open which locks. A random person who finds your magic key shouldn't be able to find their way to all the locks it can unlock.
4. When you see a lock, you are prompted to insert a key. The prompt doesn't say which key. You try one of the magic keys have that you think should unlock it. If it happens to the wrong key, not a big deal. You just try another magic key you have, and if that's the correct key it will unlock it.
5. When you buy a new lock (sign-up), you decide which magic key you have that should be the one to unlock it. This pairing of the key to the lock is done simply by asking pair a key to the lock. You are not being told to use a specific vendor of magic keys. You are not being peddled only magic key vendor over another!
6. If you want to change the magic key paired to a lock, you can do so at anytime on your own as long as you are in possession of the current magic key.
7. And of course, you can have multiple magic keys paired to the lock, so that you can unlock with any of the keys.
8. When you use a key to unlock a lock, the lock can tell which paired key was used – you can give nicknames to the paired keys that the lock remembers. The lock will tell you which nicknamed keys were used to unlock it previously and when.
-----
Here's where I think passkeys went awry. They became yet another platform war. The OSes and browsers are supposed to be neutral and provide an unobtrusive prompt for user to pair a key or use a key, that's it. And the user should invoke a keyring against that prompt. If the keyring provider has features – like portability or non-portability of keys etc that's unique to each key ring provider and as long as the user is comfortable with it, everyone should be good with it. The prompt needs to be unassuming. Today it is very assuming and that's the problem!
When someone puts a significant and useful software under an open license (like BSD) and nurtures a vibrant open-source community around it, sure, everyone else can definitely take it and use it for free. But nobody serious will use it just because it is free. They will consider other intangible but critical aspects like risks to themselves w.r.t future viability of the project, ability to get custom work done to it or around it, keeping up with hardware and software ecosystem trends etc. These things have second order implications – how healthy the broader developer ecosystem is, is there a broad base of core committers we can hire, how easy it is to upstream our changes, who else is using it at similar scale, criticality, cost efficiency; is commercial support available (sometimes 3rd party commercial business support ecosystem is essential due to regulatory/compliance reasons), do hardware vendors actively participate in the open-source community and ensure it runs well on their hardware etc.
Apart from free users, even the contributors have very similar considerations for their participation.
But the starting point is the license – it has to be a clear and unambiguous open-source license that is widely well-understood – especially w.r.t the blast-radius or infection radius of the license. Does it infect the library code that is linked/loaded into it? Does it infect the independent binary/processes that scaffold around it (say, control-plane, orchestrator, proxy etc)? What are the obligations if it does?
If we have to get lawyers involved to answer these questions because it is a custom license that is vaguely written or it has never been challenged in a court or the license holder is of unknown reputation, these are huge red flags.
Another equally important consideration is the motivations of the stewards of the project. While this isn't explicitly stated, one cannot be naive about it. Contributors and users will have to consider a gamut of scenarios – best/base/worst scenarios and make their judgement. With smaller steward organizations, there are one kind of risks while with larger organizations open-sourcing there are other kinds of risks. If they are competitors in some way that's another challenge. If there is no natural alignment of use-cases functionally or non-functionally, that's another issue etc.
With recent changes in Redis, all these things have become less clear and straightforward.
Any modern software design has to meet these 3-4 key aspects:
1. Make the software scalable w.r.t machines.
2. Make the software scalable w.r.t humans.
3. Make the software maintainable over time.
4. Make the software reusable to reduce startup costs.
Motivated by these, we make a lot of choices:
1. decompose a large complex problem into smaller, isolated, modular problems that can be worked on by different small teams, and run on different servers with inter-server communication.
2. organize code along with its documentation for easy understanding, readability and modifiability over time by same developers and different developers.
3. organize reusable and independently upgradable parts of the code for ease of upgrade with stable interfaces and stable test suites.
4. maintain the build/package/deploy toolchains for ease of underlying hardware and operating systems upgrades without affecting all of the code.
5. reuse is the only way to reduce costs – both time and effort – for anything. thinking carefully and setting up for reuse of services, systems, libraries, toolchains, processes, practices etc are critical to any large successful software project.
These are general rules for normal times. But there are inflection points when it is profitable to violate these rules.
Things that distort the cost/benefit tradeoffs and make it profitable to violate these rules:
1. When tech ecosystem is rapidly evolving and toolchains and libraries ecosystem isn't mature.
2. When time to market is super critical and if successful we will have more than enough money to deal with these problems later, and if we are late even with good software we would have failed and shut shop.
3. When we can't hire talented skilled engineers and still it is worthwhile to win in the short-term.
With these rules and violations, you can get stuck in an early local optima. A culture of continuous safe refactors is a super-power that can make you immune to it. Ossification of any kind is bad.
More than hormonal physiological effects, isn't psychological conditioning a much more dominant factor in consciously self-aware/acknowledged sexual desire? (Especially when it is being measured through self-reporting).
Until we invent some sort of non-obtrusive brain observability system (like a no-op continuous observability implant) that can take precise and accurate measurements with timestamps that can be correlated with other measurements taken across the boday of a person living their normal life, it is going to be difficult to form an effective study for this.
Performance characteristics of the underlying hardware dictate the software abstractions that make sense. In today's machines, we still have differential cost for sequential, aligned, rightly sized block io operations vs random io operations of random sizes. And we have a hierarchy of storages with different latency, performance and costs – cpu caches, ram – and ram, ssd, spinning disks – and these via local attached vs in disaggregated and distributed clusters.
So, if you want absolutely optimal performance, you still have to care about your column sizes and order of columns in your records and how your records are keyed and how your tables involved in join operations are organized and what kinds of new queries are likely in your application. This matters for both very small scale (embedded devices) and very large scale systems. For mid-scale systems with plenty of latency and cost margins, it matters a lot less than it used. Hence, we have the emergence of nosql in the last decade and distributed sql in this decade.
Couple of important lessons that will keep you in good stead for a long time:
1. Learn how to learn well, continuously, and sustainably. Tech changes rapidly. And you will want to hop from one domain to another, just for keeping things interesting and to move with markets. This is both a blessing and a curse. It is a blessing because you can start late and still be in the top percentile if you have the brains and work hard for it. It is a curse because you will be doing this no matter how many years of experience you have.
2. Hone your non-technical skills– caution: these are compounding over time (both good and bad habits) – being disciplined, thinking clearly, articulating clearly, being professional, being trustworthy, managing your physical and mental health, being dependable/reliable, having a growth mindset, thriving in ambiguity and uncertainty etc. then, honing your communication skills – effectively collaborating with people, give/receive effective feedback, do/get mentoring/coaching, working with cross-functional people, working with very seniors, very juniors, peers etc. read a lot, develop mental models, deeply craft your personal approach to first principles problem solving, to making tradeoffs/bets etc.
You can do the above all by yourself, through reading, and observing people from afar, and engaging with people (even strangers on forum like this one) in dialog.
I've been in a similar position of having to learn solo for 10+ years and lesson #2 above has been FAR more important than #1 in my experience. Clients and bosses care much more about communication, dependability, etc. than whether a product has been coded elegantly via best practices.
I can see some differences, but none of them seem "big".
In code you don't have all the extra communication avenues that we have when speaking, like body language, intonation, sarcasm and so on.
On the other hand, when writing code we are not speaking in real time. We can think about a problem for a while, consider the best possible way to solve a problem and how to explain it.
1) Coding clearing in the moment vs (2) coding clearly for future selves is two different mindsets/contexts right there.
(3) Communicating clearly is an orthogonal skill to coding clearly. I think this skill is barely acknowledged in engineering cultures in comparison to the above.
I feel you have to have an engineering culture that values institutional knowledge retention, team education and growth — and not treating engineers as fungible — to get to level (2). Level (3) would be a great place to work.
Ideally, yes. And I agree that there's some correlation of how well clearly people can write prose and write code. But, articulating yourself with your teammates is not only about writing well. It's also about saying the right things. I have seen many engineers that write code well, can write a paragraph in English well, but just don't communicate enough and don't communicate the right things at the right time etc.
For 2, I'll single out the skill of tailoring technical explanations to your counterparty's level of understanding and technical knowledge. The ability to explain to less technical people what your new project/feature does without going into too many unnecessary details and without being too high-level is invaluable. It builds confidence in your work for them (I know what this thing is doing - maybe not all nuts and bolts, but enough to operate with confidence) and in you as a professional (this guy clearly understands what he's working on and does not try to bury me in jargon or oversimplify things).
This exact scenario is one of the best interview questions I’ve been asked and have repeatedly re-used when on panels myself.
Taking a complex domain and effectively communicating it (correctly) at different levels requires having not just rote knowledge but an actual understanding.
I tell myself to not adhd it and instead take time and read through a whole manual, experiment in a local sandbox, grasp the limits of knowledge and features and also where it gets deep.
Then in a regular work I explicitly detect where it pays off and feel “see I told you”. This creates a motivational loop to continue not-adhd-ing through tech.
Sometimes I still fly over the knowledge, but then may note that what I’ve been doing in a complex way could be solved with one parameter, if only I knew about it. This creates negative feedback against flying over.
This is ofc only one facet of learning, but I find this “see I told you” method very effective, cause my main issue with learning is unwillingness to learn for no clear reason.
My issue with this method of learning is… deadlines. During work time, I often feel that I need to solve something “quick”, which then leads me to usually learn and really deep dive outside of regular work hours instead.
Now, I mostly actually enjoy doing this and thus it has not really limited me. But I wish I could just spend some actual work time on more ‘non adhd-ing’ what I learn.
Yeah, deadlines suck. Historically I managed to "manage the management" into a reasonable rush/cook balance most of the time, which allows for healthy exploration, but that is absolutely "ymmw" thing.
I love the manual method and occasionally used it. Basically assuming there is no Internet, just a book and a repo of source code and try to figure out how to do something.
Sadly I'm now so easily burnout that even setting a dev env up can burn me out.
The key is to figure out what your learning process looks like.
For example, I discovered early on that I learn in three phases:
1. I get exposed to something (a concept, a process, etc); basically discover that something exists.
2. I then see how that thing is used whether through mentorship or tutorials or, increasingly, through trial and error.
3. I apply that thing to some novel problem.
Through this cycle of Discovery-Tutelage-Application, I can assess my level of comfort with new material and understand when my struggles are due to trying to short circuit the process.
It's likely that you have some form of learning process that is equally cyclical, yet undefined -- once you identify and codify those steps, you can evaluate your progress when it comes to acquiring new skills.
This is a difficult question to prescribe an answer for that works for everyone, but the best I personally can think of is "practice".
To make that more actionable... My approach in life has generally been to find a project (even something seemingly incredibly dumb, as long as it is fun), then work through it, learning what I need to know as I go along. To learn "well", you must then also constantly question what you have done as you complete various stages of the project to see if you have done them as effectively as possible, and try to incorporate any lessons learned into future projects.
I have found that how individuals do the learning required for this differs significantly from person to person, so it is hard to recommend any particular approach.
You learn to learn with time and imo it's different slightly from field to field. In tech field you just learn by doing, asking questions, making mistakes and gaining experience. Take a sample code in a new language, make it do something slightly different. Then add one more thing on top. Then something slightly more complex, then finally try to make it do what you want. Once ready, deploy, test, and iterate.
At its simplest, rewrite and interface regularly with knowledge. There’s an entire hobby around personal knowledge management, and it‘s all up to you to find what works best, but taking meaningful notes and rewriting those notes, processing them further and further, will help form deeper mental connections regardless of method.
Any recommendations on learning to "think clearly"? I feel like this is something I struggle quite a bit with and haven't found any good resources on improving it other than "sleep" and "exercise", which I'm not lacking in.
Unironically, that's what school is supposed to be for.
There's keeping the engine well maintained (the sleep and exercise part, for example) and there's driving the engine down new paths and honing you driving technique. You work on the latter by exposing yourself to novel and interesting arguments (interesting philosophy or argumentative non-fiction, for example) and then working through the argument again with counter-arguments in mind. I would not recommend pop-sci books for this, because their arguments and writing tends to be quite flabby.
I'd actually recommend something like RG Collingwood's "The Principles of Art" which is a relatively plain English example of well written philosophy:
You will disagree with him. The point is to understand how and why you disagree with him and to explain that clearly, not only to yourself but others as well. Thinking clearly is about responding and communicating clearly while displaying a sure and succinct understanding of the problem at hand.
You can apply that to everything you read or are confronted with, but the key thing to realize is that "thinking clearly" is something you practice. There is no one trick --- it's an approach.
