HN user
We are finally free of friction
Free from friction, constrained by pricing and a massive ladder that can be pulled up by companies that are in no way benevolent.
If you're one of the lucky few who were able to already have hardware that can run some of the open weight models you can be a beneficiary for now - but that won't last forever.
Just as long as you're using a distro that isn't using systemd[0], which is kind of an uphill battle these days
I'm not sure where you get the idea that Linux doesn't have hibernate - there's both userspace systemd-hibernate bindings and also the kernel swsusp which both work equally well (although you may need to make sure you have a large enough swap partition for it to function)
Also the other issues you're describing do sound frustrating but I think it's a byproduct of an entirely different culture. Exposing user-configurable timeouts and you being made aware of it during troubleshooting is something that enables you to deeply understand your system and how it's configured. In Windows, even if there is defaults for things like that it likely is not exposed to the user or configurable at all. If the default settings are bad you're just stuck with it and you aren't expected or intended to modify anything to better suit your needs.
My experience with Arch is mostly due to having been a fairly proficient Linux user prior to switching over and being very comfortable reading the wiki or bbs and tinkering to find solutions to things. A lot of the prior experiences I had with Debian or other "friendly" distros kind of put me through the ringer too and I've found that having the rolling release with Arch fits my preferred workflow much better than something like Ubuntu or Debian or Fedora or the other "batteries included" distros.
I share the same sentiment. I've had the same Arch install running since ~2016 and have been using Arch since about 2013 and the number of times I've needed to chroot from a live image is under 10 and were mostly related to systemd breaking things during an update which is pretty much entirely no longer an issue these days.
Compared to Windows-land where nuking and reinstalling the entire OS is a routine maintenance task, checking arch news to see if there's any manual intervention and running `pacman -Syu` is all I really ever think about.
As an early adopter (signed up for the matrix.org riot instance some time in 2016) and someone who has run a homeserver on and off for nearly a decade, my primary issue with Matrix these days is that it still feels like there largely is stagnation in homeserver development because the spec oftentimes seems to follow features from Synapse instead of the other way around.
It seems like a lot of MSCs are implemented as experimental in Synapse while they are under active development, but sometimes it takes months or years for the MSC to be ratified in a way that is stable for other homeserver implementations to pick it up. One example that immediately comes to mind is sliding sync as well as threading and spaces. And in the case of sliding sync, the proxy deployment helped, I think only Synapse is the only server that actually supported (or maybe currently supports?) it and in terms of threads, that was more of a client-side issue of actually parsing and rendering m.thread events.
My feeling on it maybe isn't backed up by reality or the actual data of development but it makes developing on the ecosystem feel difficult.
The other real blocker to being a Discord-killer imo is the permissions model. Having power levels 0-100 is a lot less flexible than the RBAC-style model that Discord uses. Once Spaces were rolled out, a feature that would have been nice is to restrict access to certain spaces or rooms that are children of that space based on a role, which afaik still is not possible to do with the current permissions implementation.
The book that's really stood out to me is the Kernighan/Pike "The Practice of Programming" as something that steered me in a really good direction when I was first learning to write code.
I really wish they'd do a revised 2nd edition using Golang as the base for the book instead of C; but otherwise it still really holds up well
But with a containerized app image you can reduce the blast radius of the poorly maintained app compared to running it bare metal on a host with other services. Also you can still maintain base images to patch/try to reduce vulnerability surfaces
Rootkit anti-cheats can still often be bypassed using DMA and external hardware cheats, which are becoming much cheaper and increasingly common. There's still cheaters in Valorant and in Cs2 on faceit, both of which have extremely intrusive ACs that only run on Windows.
At the level of privilege you're granting to play a video game, you'd need to have a dedicated gaming PC that is isolated from the rest of your home network, lest that another crowdstrike level issue takes place from a bad update to the ring 0 code these systems are running
The big publishers already have their own launcher and platforms and are increasingly moving back onto Steam because they see higher PC player counts and sales when their games are there
I view it as Valve is doing me a favor by adding friction towards me installing a rootkit to play video games.
There's also been numerous userspace ACs that work well and also run in userspace (EAC, Battleye, etc.) that have been enabled for Linux/Proton users (including by EA with Apex Legends at one point). A lot of the support for Linux mostly comes down to the developer/publishers not wanting to and not because of technical reasons.
You can buy a mini pc for >$200 USD that is capable of running most desktop tasks and can also handle server tasks. Good quality integrated graphics APUs are also plentiful and fairly easy to come by these days.
Sorry to hijack this thread to ask - but what is the current state of sliding sync? Does it still require a separate proxy service to enable sliding sync if you're self-hosting a homeserver; or is it upstreamed into synapse? Also is there a list of clients that are sliding sync aware?
what happened to just having a single device and having it run the code directly and show you the result directly?
Having access to multiple computers/devices as a single user became cheap and more common. If it was still the 2000s (or maybe early 2010s) and somebody only used a single PC for most of their tasks that'd make sense, but that's just not the reality most people live anymore
Looking through the commit graph for Omarchy is wild. It has 2000+ commits, most of which contain the type of intermediary work pushed into the trunk that you'd see from a jr who doesn't squash their local work
Also some gems like: https://github.com/basecamp/omarchy/commit/af72a45dbd4358bca...
Remove non-existent vibe-code hallucinated options and clean up theme files
or https://github.com/basecamp/omarchy/commit/4fedfbe9f19303046...
There's also Omakub[0] which was sort of a precursor to Omarchy that gives users the `wget <some url> | bash` as a means of installation where the install script is a thin wrapper around another `eval $(wget <some url>` that then git clones a repository and executes a 3rd script.
That's definitely the kinds of patterns I'd expect some prolific software engineer to use and also encourage complete novices to Linux to be comfortable just piping arbitrary wgets into a shell
"dead simple" really depends on what you're targeting and how. If you're targeting a cloud deployment on hardware you don't control or that's running with multiple instances/replicas, OTEL makes that pretty simple because you get a lot for free in the way of tracking instances/correlation ids, etc.
If you wanted "dead simple" text-based logging in a situation where a service is deployed in multiple places you'd end up writing a lot of fluff to get the same log correlation abilities that most OTEL drivers provide (if you can even ship your logs off the compute to begin with)
Which again comes back to the "maybe the framework isn't for you" if you're building an application that's a monolith deployed on a single VPC somewhere. But situations where you're working on something distributed or replicated, OTEL is pretty simple to use compared to past vendor-specific alternatives
I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all aggregated in one place using OTLP format
That doesn't really mean it's heavyweight though; an extra layer, sure (but I don't even really agree that it's complex - you set it up once and then mostly just log the same way you would with any other).
You can still log to a text file if you want to run locally, but for something like next.js where you're intended to deploy production to some cloud somewhere (probably serverless) the option of _just_ writing to a text file doesn't really exist. So having OTEL as an ootb supported way to do o11y is much better than the alternative of getting sucked into some vendor-specific garbage like datadog or newrelic
What specifically is heavyweight about OTEL? At its core it's a standard for producing structured logs along with some standards for exporting/collection. The heaviness is really implementation-specific and can vary stack to stack
There's even a handler for monolog in PHP - they are not necessarily mutually exclusive
https://github.com/open-telemetry/opentelemetry-php/blob/mai...
Why can’t logger().info() just work in a sensible way?
I think OTEL is pretty sensible for a vendor-free and if you want to have a console logger you can use the console exporter[0] for debug mode during local development. Also if Next is designed as a framework to make it easy to build production-grade apps, having a standardized way to implement o11y with OTEL is a worthwhile tradeoff?
If you view that as being overkill, perhaps you're not the target audience of the framework
[0] https://opentelemetry.io/docs/languages/js/exporters/#consol...
The Bitnami images and helm charts are just convenient repackaging of things that are already freely (gratis) available. There's nothing stopping you from still deploying Kafka or Redis, etc. into your k8s cluster without using the Bitnami helm chart or building your own charts.
I think that's the point of above of "now you have to do your job" There's an evaluation that takes place when choosing to use something as an engineer, and the writing should have been on the wall the moment that Broadcom bought Bitrock to start planning to reduce dependency on those things.
An e-bike that can even do 20mph comfortably is much closer to a moped than a bicycle
There are pedal assist ebikes hitting the market that are nearly indistinguishable from a road bicycle and weigh as much as a kitted out steel touring bike (i.e. ~35-40 lbs) and can comfortably do 20 mph.[0] I don't really think that's treading any sort of line of being close to a moped.
Also there are absolutely people riding analog bikes capable of having an average cadence of 15-20 mph who ride with reckless abandon on crowded mixed-used paths in cities - so maybe you don't do that, but there's a pretty large subset of cyclists who are doing that because biking is more of a sport activity than strictly pragmatic form of transportation. Bad bike path etiquette extends beyond ebikes
[0] ride1up is one brand making such bikes
Isn't it likely that newer projects licensing under GPL are also unlikely to be using GitHub and instead be using a platform like GitLab or Forgejo (or previously Gitea or something)?
This is basically the modern "google-driven" development experience as well. The copy-pasting from SO trope has existed for some time, but it's much worse in the last 5-7 years with the increase of blogspam/LLM generated content on Medium that's SEO'd to the top and effectively just rewriting the "getting started" page of some language/framework/tool/etc. for resume boosting points.
It seems like a lot of the models in ChatGPT and Copilot were trained on that content and in turn tends to produce a lot of dead end solutions for anything that isn't the 90% cases and often leads to more pain than reading documentation and building a solution through iteration/experimentation.
Maybe that's part of the reason why "strider" bikes are becoming a lot more common for toddlers to learn how to ride a bike. They're effectively what the OP describes, a bike with no pedals that you run and then balance on.
What I've found helps me with hobby jumping or not completing tasks/practicing/etc. is to not talk about it. If I'm going to do a task or work on a hobby the act of saying I'm going to do something triggers the same dopamine reward as actually doing the thing. Instead I try to only talk about things that are already done in order to hold myself a little bit more accountable for actually working on stuff.
Wasn't the original benefit of Perl that it was fairly close to a standard tool, i.e. it was available on pretty much any server you would be pushing a script to anyways?
Raku doesn't seem to have the same ubiquity, while Python is generally available on any system, or even Perl5 is still widely available on pretty much any system. I'd love to start using Raku more but it seems like a hard sell over Python or Bash
Some additional anecdata (and actual data) is that Chicago has the highest cyclist increase out of any city in the US as a result of better infrastructure being installed [0]
The anecedata is I see far more people biking year round in Chicago (even in the pretty brutal subzero January/February temps) than I ever can recall.
Granted it's a very flat city without much elevation changes, but there's definitely the spectrum of extreme heat in the summer and extreme cold in winter that doesn't seem to stop anybody
[0] https://chi.streetsblog.org/2024/05/28/cdot-built-it-they-ca...
It might be worth giving another try. The `archinstall` script that's a part of the installation media (even though it's not technically "supported") really makes the process of installing a lot more painless if you know what you want to set up
Out of curiosity, what time investment is required for maintaining an Arch install?
I've been using Arch for the past decade and other than the turbulence when switching over to systemd, I don't do anything other than `pacman -Syu` and can only recall exactly one time where the system broke and it was because mkinitpcio failed to run after updating a kernel and was fixed by chrooting into my system and rerunning it.
I often had more issues with Debian or other distros because of having to fight the system to install packages that were built within the past year.
If you roughly understand *nix and can think about things in terms of the unix philosophy it takes no time at all to grok Go.
It's basically C if it were repackaged for writing http-aware services.