I moved all my stuff from AWS to a Hetzner VPS recently. I don't have much, and AWS was actually cheaper, but I'm so much happier having everything in one, simple spot.
There's a gap in my knowledge so far, which I think is mirrored in this post: I have been piecing together my server by hand, and I _know_ I will regret this at some point, but I don't know how I want to solve this yet. I don't want to involve Docker in this setup. Perhaps I should go back to Saltstack or Ansible, or maybe there's something in Nix for me, or snap/flatpack maybe, I don't know. There's a good chance I'll just never solve it, but it seems like there's a gap there that's waiting for a great, simple, small solution (or it exists and I just don't know about it).
So after all these years (decades now) of learning and working in linux every, single, day, I still have a lot to learn! :D
You are not wrong. Docker (paired with Kamal in Rails world) would simplify a few bits of the setup. But not all. The reason I haven't switched is:
1. my lack of experience with running docker in production
2. don't fix something if it ain't broken
But I'm planning to revisit it when my current LTS version runs out of support. Also, Kamal defaults change a few core pieces (caddy vs nginx, puma vs passenger) so there's a bit of extra learning curve). Oh and you'd still need to harden the server and keep it up to date.
I initially reached for Docker actually, but when I started researching how to run it securely, I just thought "I don't need this. Systemd is already there and does all of this in an easier and more direct way".
We believe that apps should never crash. They should be free of bugs. They should be fast — they should feel lighter-than-air.
We believe that quality is more important than just piling on features; we believe that quality is the most important feature. And we believe that high quality is transformative — it makes for an app you never hesitate to reach for. You can rely on it, and you do, again and again.
This makes us slow to add features. We are adding features — but never at the expense of how it feels. Never at the expense of reliability and speed.
Their new version 7 implements the lower quality design of liquid glass while also blocking all ios versions below the latest (so you can't get bug fixes and slow features with the better design). How does that fit the philosophy?
I think it looks better (on Mac and iOS) than any other Liquid Glass app. And I can’t blame Brent for adopting it. One of the standout features of the app is just being native, not trying to re-invent the wheel with custom GUI, and taking advantage of built-in platform features.
My favorite NNW feature is iCloud syncing: Not needing a separate RSS back-end (but of course you can use one if you want to sync with other clients).
> think it looks better (on Mac and iOS) than any other Liquid Glass app
what a weird comparison, the baseline is the previous version of the app
> standout features of the app is just being native, not trying to re-invent the wheel with custom GUI, and taking advantage of built-in platform features
Since the previous GUI isn't custom you don't lose your standout features
Yes, because it means that as Liquid Glass improves with Alan Dye out the door, NNW will automatically benefit from the improvements. Having an app that just follows the current standard native platform conventions is better for users and leads to apps that behave in a predicable way.
Doesn't make sense, the improvements can still be worse than pre-glass, and it's not guaranteed they will be better. Also, what's the rush, why not implement it after it's improved?
The predictability is the opposite - you've changed design, breaking predictable patterns. Also, cutting off users can't be better for users
That's a tough one, but considering it's only the 7th major version to come out in 23 years, I'd say that's a fairly safe place to demarcate backwards compatibility, considering that it's (probably) a fairly major UI overhaul on both iOS and Mac. Despite the poor quality of the OSes themselves, it's just a small studio, gotta pick your battles carefully. You can still use the version you're using, and if you ever upgrade to the new OS you can get the new version, seems reasonable enough to me
Ok, and how is wasting time making the design worse to follow the OS instead of spending that time implementing missing features a carefully picked battle? I thought the philosophy was prioritizing quality
> You can still use the version you're using
Which would be missing bug fixes and those slow features the may be added next year
The app has always followed the masOS design language, because the app is built using the native macOS tools. It makes sense for it to match the OS it's on, apps built with stand UI components migrated to 'Liquid glass' much easier.
It doesn't make sense because the previous version also matches the OS it's on, liquid glass degradation isn't mandatory and "much easier" is still harder than doing the better nothing.
Your suggestion is just as senseless: among the many things wrong with such a "write the app yourself" approach, you forgot about iOS, even though it's mentioned in the original comment, where you can't freely backport anything due to distribution being locked down
It makes sense. Like you said, previous versions used the macOS design language at the time, and the current version does the same. The developer has chosen to no longer support older versions of macOS, they aren't required to. The old app still works, and anyone else can work on it if they want.
> you forgot about iOS, even though it's mentioned in the original comment, where you can't freely backport anything due to distribution being locked down
Yes you can. You can create an app today that is compatible with iOS 15.
You create a backport just for yourself for your own device without needing the store, no distribution/App Store is needed.
You don't like some of the Liquid Glass stuff... fine, make something else. The old versions still work, I don't really know what you are complaining about. This level of support and polish in a free app is amazing.
> You create a backport just for yourself for your own device without needing the store, no distribution/App Store is needed.
It is needed, you can't install a custom app permanently on iOS. By the way, what if you only have iOS and not a Mac? How would you compile your backport?
> The old versions still work
I've already addressed it, come back with something meaningful rather than repeat
> I don't really know what you are complaining about.
I've explained it to you several times, maybe you can get that knowledge by reading the conversation carefully?
Sooner or later, they needed to adopt the Liquid Glass design. While Apple allows developers to temporarily add the UIDesignRequiresCompatibility flag to disable Liquid Glass in current iOS version, they are very clear that that flag is temporary and will go away next version. So they had to adopt it either now or next year even if they didn't want it.
Or don't use the latest SDK and don't be forced "next year", but continue for many more years. Also "later" is definitely better in such cases because there is some change the design will be improved.
Either way, there is no good reason to rush to be worse and cut off users if you proclaim you're into quality
Many homelab users are actually building things out in an effort to learn tooling that they will then use at work. Or just out of intellectual interest.
A lot of tech debt I've seen stems from people tacking things onto a loose foundation – adding API endpoints when there's no clear pattern, adding validation or defaults in different ways, organizing layers of code in various ways, multiple implementations of the same business need.
This is compounded when people come and go. The software/tech industry, in my experience, does not encourage long tenure – layoffs, reorgs, and the general trend of people hopping between employers every 2-3 years.
Startups also love the idea of building things fast and ugly, and 5 years later that leaves the company with a successful product (hopefully), a team that's grown fast (and turned over multiple times), and a shaky foundation.
Engineering generally seems open to paying down tech debt, but there's an overwhelming amount of it sometimes, and someone needs to deeply understand the problem and lay out a clear plan for taking care of it, and that takes serious effort.
I haven't written about it much yet, but atlas9.dev has an infrastructure component to it. I actually spent most of today researching and experimenting with infrastructure and I plan to write about it soon.
atlas9 is about setting up a foundation/framework for building and deploying apps that takes care of more of the common issues. Infrastructure (build, deploy, monitor, config, secrets, etc etc) is a big part of that. I've been focused on the application code lately, but I suspect infrastructure is where the meat of the problem lies.
I can relate to that. I have a ton of bookmarks and open tabs that I've been meaning to read for weeks or months now. I guess that's why I'm hoping a daily reading list might give me a bite-sized chunk to work through.
That problem I found is that each day brings more potential things to read. The slow news days where one can dip into their backlog of articles seems to be a thing of the past.
The key would be having something that could surface what is worth your time, and finding a way for those items to take priority over the new things coming at you… which would also need to be evaluated for whats worth your time.
In my experience, archived objects are almost never accessed, and if they are, it's within a few hours or days of deletion, which leaves a fairly small chance that schema changes will have a significant impact on restoring any archived object. If you pair that with "best-effort" tooling that restores objects by calling standard "create" APIs, perhaps it's fairly safe to _not_ deal with schema changes.
Of course, as always, it depends on the system and how the archive is used. That's just my experience. I can imagine that if there are more tools or features built around the archive, the situation might be different.
I think maintaining schema changes and migrations on archived objects can be tricky in its own ways, even kept in the live tables with an 'archived_at' column, especially when objects span multiple tables with relationships. I've worked on migrations where really old archived objects just didn't make sense anymore in the new data model, and figuring out a safe migration became a difficult, error-prone project.
https://helmtk.dev is a toolkit for helm chart maintainers, including a structured template language than can compile into helm templates, and a test suite tool for writing tests in javascript. Super handy I think.
https://blog.atlas9.design is about building a better software experience by solving more of the common stuff from the start: IAM, builds, API design, etc. I'm currently designing and building a Go-based framework to start.
There's a gap in my knowledge so far, which I think is mirrored in this post: I have been piecing together my server by hand, and I _know_ I will regret this at some point, but I don't know how I want to solve this yet. I don't want to involve Docker in this setup. Perhaps I should go back to Saltstack or Ansible, or maybe there's something in Nix for me, or snap/flatpack maybe, I don't know. There's a good chance I'll just never solve it, but it seems like there's a gap there that's waiting for a great, simple, small solution (or it exists and I just don't know about it).
So after all these years (decades now) of learning and working in linux every, single, day, I still have a lot to learn! :D