HN user

yumiris

173 karma

For long-winded responses (that are written from the heart!), pour your heart and soul at me@miris.design

Posts4
Comments24
View on HN
What Is Unraid? 4 years ago

I used unRAID a while back for nearly two years. It's delightfully convenient for managing Docker containers, multiple disks w/ data parity, network file sharing, and even VMs with passthroughs. The last feature, especially, is absolutely killer with how easy it is to accomplish in unRAID.

Whilst a lot of unRAID's functionality can be achieved with a bit of tinkering and reading, its UI does save a lot of time and keeps things very simple. For example, I have yet to figure out a way of achieving GPU passthrough on an Optimus laptop without my hair going grey -- a part of me feels like unRAID might simplify it, despite it being an OS for servers rather than laptops.

One thing I'd absolutely wish for is ZFS support. I haven't looked into how ZFS's licence might interfere with its integration, but if integration is possible, it would be magnificent.

Nevertheless, unRAID is splendid at what it strives to do and buying a pro licence for it was absolutely worth it!

Absolutely, it's sadly a compromise. Although there's one thing that's much harder to forget and won't be prone to distortion: how we felt!

If we immerse and let our feelings of wonder and awe prevail, it will be difficult to forget such feelings even if the visual memories change over time.

When possible, I first visit the place without a camera and strive to immerse completely. I then visit it again and take pictures. Not using the camera the first time - and having to think about how I'll take the pictures when revisiting - provides a lot of opportunity to appreciate and reflect on the sight in question. With places I can only visit once, I try to take as little pictures as possible, and instead embrace living in the moment to let my mind and heart preserve the memories.

I've learnt this one from my other half: she rarely takes pictures because focusing on pictures detracts from actually living in the place. She takes pictures as a sort of "index" for where we've been: a quick of us together with the location in the background, maybe one or two snaps of beautiful sights, and so on. It's pretty rudimentary, because ultimately, the vivid memories are preserved within us rather than the photographs.

Though I won't deny that the fear of not capturing everything can get to me at times, thus I end up taking one too many snaps. I think that's a fear many people deal with when they take an inexplicable amount of photographs of the same thing!

KeePassXC 2.7.0 4 years ago

Love KeePassXC - it's a beautiful and speedy program which simply just works without ever causing any problems. The original KeePass always struck me as a tad heavy due to its somewhat archaic aesthetic and dependency on Mono, whereas KeePassXC looks modern and requires minimal resources and dependencies.

I combine it with KeePassium on iOS and Resilio Sync for synchronising across my main and mobile devices. (Syncthing doesn't offer an iOS client, sadly, hence the choice of using Resilio)

Literate programming has been particularly useful for my "dotfile" configurations, such as .emacs, .vimrc, .zshrc and even the .gitconfig file.

I use one .org file to declare all of my configurations, and tangle them together into the aforementioned files. This keeps things pretty portable, and makes up for the unintuitive readability of many dotfiles.

It can also work for rudimentary shell scripts and other single-file goodies; however, scaling it to proper multi-file programs proves to be difficult, especially when multiple developers are involved.

You are absolutely right! We expect all information to be given to us, instead of us seeking the specific information we need.

The solution is to - like your maxim implies - reverse the paradigm, by treating technology like it was initially designed: a tool for us to use with intent.

Even the apps and websites which have been optimised for engagement can be valuable. The value is what we make of it, just like how the websites make value out of us.

Advocating for quitting technology unfortunately becomes more and more of an impractical advice, as technology is further ingrained into our lifestyle.

What matters the most is being mindful and honest with ourselves. The moment we lose sight of how we use something, it starts using us.

It seems like your book focuses on a similar mindset. I've stumbled upon it before, but now I'll definitely be giving it a read! :)

Most derivatives generally just add packages and customisation to make a more convenient and specialised derivative.

At the top of the "family tree" of distributions, you've got "root" distributions such as Slackware and Debian. They branch out into specialised distributions such as Ubuntu Server for servers, Kali Linux for pentesting, and so on.

With this in mind, it's probably easiest to start with choosing a "root" distribution, and optionally choosing a derivative as necessary if a root distribution isn't specialised or convenient enough for your needs.

For example, if one wants stability and hardware compatibility, one can go straight with Debian. If they want a layer of user-friendliness and official support from many applications, then they could pick Ubuntu instead of plain Debian. (This is a subjective example!)

Considering there's hundreds of distributions, having some criteria such as high popularity and thorough documentation might be necessary to narrow down the list of choices.

DistroWatch is good enough for giving you an idea of each distribution's purpose without opening dozens of search tabs.

Of course, one could also choose the option to perpetually hop from distro to distro every other day, if feeling adventurous (or anxious to make a choice) :P

One of the very few things I miss about social media is seeing HONY posts appear in the newsfeed. They were always a delightful and authentic highlight amidst a sea of forgettable posts filled with superficial drama, misery and cynicism.

Brandon's passion and dedication deserves all the respect and appreciation - it's wonderful to see the endeavour reaching such new heights!

Complexity of storage/presentation formats can indeed compromise accessibility and longevity. However, trying to enforce plain text on everything can be detrimental to the quality and fidelity of information.

Of course, it very much depends on the context - technical documents may not need images as much as a travelling blog would. That's why it's important to use plain text as necessary, rather than always. The same applies to any format, including images and even videos. It's about balancing the usage of different formats, plain text included.

With this in mind, it's certainly recommended to start with plain text, but if plain text doesn't cut it, it's much more practical (and beneficial for the information) to just add an image. Ideally, one should always diversify how they store and present a piece of information, if they can afford to do so.

There is a tragic irony in sacrificing the potential fidelity of information in hopes of making it universally accessible.

Absolutely beautiful little OS - I love that it manages to balance well between being light, secure and rather versatile for server environments. I run it as a WireGuard & Docker server on a low-end VPS, and it just works without any problems at all thus far.

Its wiki does a fine job at being a pretty good resource for documentation, too, and both ArchWiki & Gentoo Wiki work well as fallbacks.

By separating who we are from what we do. Our jobs are our jobs, not us. Our projects are our projects, not us. Our perfectionism exists because we've been taught to define our worth according to how perfect something we create is. As such, separating ourselves from our creations is a step towards overcoming that perfectionism.

There are other things to consider: our attachment to other people's opinions, perceiving failure as a lesson and investment towards our success, knowing that perfect is the enemy of good, and so on. But that will naturally come when we remove our ego from our work and not give it power.

I see it as our minds being impressioned into a) needing new information and b) fearing a lack of information. This fear manifests as a habit of continuously craving novelty, to the point where we are used by technology.

A step towards overcoming it is to realise this fear and begin using technology as tools, like they were originally intended. This is, of course, easier said than done; however, with time, we can overcome this habit by using our technology with intent.

The biggest obstacle is not the technology, but ourselves. We often find reasons and justifications to continue this habit. Fundamentally, it's a case of self-victimisation and illusion of necessity. "It's too hard to quit", "I will learn new things", "I need to catch up with people", and so on.

I'm still exploring this topic and there's a lot to learn! What I've written above is likely just a (possibly misguided!) part of the whole equation. I'm happy to discuss this with anyone and understand the nuances of this problem, and hopefully a more effective solution.

Coincidentally, I've written about this topic in more detail a few days ago: https://blog.miris.design/attention-atrophy

You're absolutely right -- it can definitely become difficult to achieve that ideal with certain clients, and as you've also said, "simple" and "maintainable" can be a very subjective thing. I admit that it's tacit knowledge in my case, and also a gamble that the next developer will preserve their sanity. There's no formal yet practical way of gauging simplicity and maintainability.

Your point on mental comfort is also spot on -- ideally, there should be a satisfaction between developer comfort and fulfilled clients. Sadly, that could also come with its own compromises. Heh, development is fundamentally a game of figuring out the sacrifices with the least impact for all parties involed.

This also served as a way of mitigating the impostor syndrome, which I'm sure many of us have dealt (or are currently dealing) with. Do you have any other approaches? I'm interested to read your thoughts!

Cheers for the heads-up on the typo. The diagram's an SVG, with the labels being in plain ASCII. One keystroke is all it took indeed! :P

On the serious side, ASCII art diagrams are splendid and I very often use them myself, though they can get quite complex and thus messy to maintain. There comes a certain point where they lose their simplicity, sadly.

Must admit, the article and comments have completely changed my impression of the Souls series.

The "git gud" mantra has been drilled into my numbskull to the point where I would restart a boss fight even if I got hit once.

I got a wee bit too persuaded into rushing and mastering (which, of course, can't be done at the same time), because anything less meant that I ain't doing it right.

In the end, I gave up on the Souls series and classified it as not being for me, but now I'm considering returning to Bloodborne and Sekiro again.

Cheers for the new perspective everyone!

Current journalism optimises for fear (especially after how lucrative COVID-19 reporting has proven to be). The more fearful and angry people feel, the more news they'll continue to consume.

It's best to take a break from reading too much about the current Ukraine situation. This doesn't mean being completely blind to it; however, balancing between your mental health and knowledge of current affairs will help you cope with the ongoing situation more than anything.

I'm exactly in the same boat as you regarding both the mentality and approach.

Just a curious question about the index notes: don't you feel they're cluttering up the graph and result in superficial relationships between the notes?

In my personal case: I used to create index notes to make navigation easier, but then I've found myself wondering "where should this note be indexed?" and also not getting much value out of the relationship graph.

Once I've discarded the index notes, the relationships became much more organic and authentic. Surprisingly, finding notes hasn't become more difficult after eliminating the index notes -- queries and lists are a beautiful thing.

What are your thoughts on this? Do you encounter any challenges with indexing?

The post ultimately seems to boil down to "be more empathetic and considerate of your users", and building reliable software is of course one of the ways to accomplish that.

Unfortunately, the OP's points stem from various biases, and the idealism is harder to accomplish in practice than the OP makes it out to be.

Almost all software that users encounter in $CURRENTYEAR is straight-up broken, and often badly.

Always been the case, whether now or decades ago. Many issues have been resolved; however, new ones will inevitably continue to appear. This is because the complexity of software will always increase, primarily as a result of market demands.

My web browser has been perfectly competent at submitting HTML forms for the past 28 years, but for some stupid reason some ~~asshole~~ developer decided to reimplement all of the form semantics in JavaScript

Repeatedly unprofessional tone aside, HTML forms in their simplest form come still come with their own limitations and quirks.

Case in point, I've recently had to build a rudimentary form for uploading multiple files. By default, a file input field requires the user to select their desired files in one go, either by using Ctrl/Command or by selecting the files.

But, how do you allow users to drag and drop files from their file manager into the form? How do you allow users to select some files in one folder, then other files in another folder? What about an even simpler scenario: how do you let the user click on the "Browse..." button to select files, without overriding the previous selection? JavaScript is the answer to this.

Luckily, this specific problem doesn't require drastic solutions, though it hopefully does bring light to the fact that HTML forms aren't as perfect as they could be.

Finally, stop letting economics decide everything you do. Yes, developers have finite time, and that time costs. Yes, users with annoying needs like accessibility and internationalization are more expensive to support than the returns they produce. You need to pay for it anyway. It’s the right thing to do. We can be profitable and empathetic.

Although I agree with the principle, the practical circumstances make it difficult to make this a reality. Many developers aren't full-time OSS developers like the OP is; instead, they work under an employer with demands, deadlines and restrictions in place.

This includes having to implement aggravating things like ads and abysmally re-invented forms, or having to sacrifice empathetic features for profitable features. In an ideal world, this shouldn't even be a problem, or at the very least a developer should speak up or change jobs when users' rights are compromised. Unfortunately, locations and opportunities can make this difficult, never mind having to keep the family fed.

There are of course many scenarios where it's the developers making incompetent decisions and being architect astronauts. But the problems the OP mentions are not caused by that; like they said, they are caused by economics. Economics shouldn't be the dictator of technical decisions, but unfortunately for most developers, it is.

This is why I believe that most of the user-hostility & brittle complexity is a result of a deeper problem, which is the developers not having enough liberty and resources. I'm confident that most developers didn't implement user-hostile features - including intrusive ads and awful forms - because they wanted to. It's easy to blame the developer for building the things, but in most practical cases, they built based on what they've been requested, not on what they've decided. I'm sure a developer will dedicate much more time and resources into robustness and friendliness if they were given the opportunity to.

Luckily, I have full control over all the technical decisions on the software I build for my employer, so I do strive for simplicity and robustness as much as I can, but I'm all too aware that not every developer has that luxury. I hope the OP will realise this, too. This isn't to spare developers from responsibility and accountability, but to bring to light that the problem the OP poses is much more nuanced, both in its causes and in its details.