Hacker Newsnew | past | comments | ask | show | jobs | submit | apex_sloth's commentslogin

I played with this extensively on hobby projects (music visualizer Wayland widget for example) and I like the idea. I like coming up with cool stuff and solutions. The problem is I'm just not disciplined enough, it makes me lazy. The longer I uses it, the less code I read myself and just fire quick /implement loops and go do something else, thinking it should be straight forward. As other have pointed out, AI still needs a lot of hand holding and there are a lot of necessary decisions to make that one usually only realizes while actually building it.


That looks awesome! Do you have any metrics on storage space and query/insert performance for large amounts of data? Building something that has couple of million rows.


We used to do that with device that where in difficult to reach places with harsh uptime requirement! Think industrial routers and protocol converters. I think it pays for itself very quickly. Sending someone for such a device can get expensive.


Only half a data point: I played around with it for a private project. It works but the documentation is far from good enough for production. I was even considering getting the book, but it's not out yet. In my humble opinion, normal documentation should be enough to understand a framework, otherwise you can't expect anyone beyond hobbyist and enthusiast to pick it up. "Break out" is definitively part of the design goals, so I always felt like they put a hatch.


When I was first getting started with Ash I also found the documentation to be frustrating at times. It's less of an issue for me now that I'm more familiar with it. I asked a lot of questions in the discord and found them to be super responsive.

Also, the book is out now.


I wouldn't let the fact that the book is in beta dissuade you from getting it. It's mostly feature complete and is a _fantastic_ resource - it really helped get Ash to click for me, and I've found it a joy to work with after getting that initial ah-ha moment.

I know the Ash team is aware of the documentation challenge, and they are working on it. I feel like the book is an answer to that, and hopefully a lot of the greatness of the book is able to make its way back to the docs.


With the caveat that I’m still learning elixir+ash and just building a small private project, I’ve bought the beta book and it really helped get my head around the concepts even though it’s not finished. I’d recommend it, it’s even on sale at pragprog this week.

Ash itself is fantastic so far. I haven’t worked with anything so productive before. Loving it.


There seems to be the notion in a lot of comments that Stoicism is about acting against one's nature or surpressing ones emotions.

For me, on the other hand, it was very freeing to encounter Stoicism, because I felt like it was okay that I didn't feel or react as strongly as people around me expected me to.


An interesting side effect of that is one can use the grid frequency to coordinate emergency power response - individual nodes (batteries, peaker plants, etc.) can react directly to the frequency measurement with generation or load, thus stabilizing the grid. Too much energy is equally an issue. Usually it's called fast frequency response these days.


Good point... oversupply lightens the load on the generator meaning not as much angular momentum is converted to magnetic flux then to an electric field. Unopposed the torque is able to increase the rotor's speed which directly determines grid frequency.

My grid tie solar system does exactly what you say. It monitors the frequency of grid power and matches it dynamically. There are defined parameters for how out of spec it can get and for how long. I don't recall the exact numbers but imagine 0.2Hz for 100ms, 0.5Hz for 1ms, 1Hz for 500ns. Same thing for voltage though that allows a much wider range.

In CA all grid tie solar also requires communication with the utility (through the manufacturer) with a backup connection source (Internet and LTE in my case). This is so if the grid is nearing capacity or going unstable the utility can command the inverters to allow a wider band of voltage and frequency. The last thing the grid needs in an unstable scenario is everyone's solar panels tripping off at the same time.

Technically the utility can also command the panels to stop production if there is an excess supply but they are limited in how long and how often they can do that.

Fun fact: The interconnect operators used to keep track of the average frequency over time and would run the grid slightly fast or slow to ensure the grid averaged 60Hz over time. This allowed clocks and such to maintain time by relying on the grid. That is no longer the case though. I think they still roughly aim for a 60Hz average but if they're behind by 0.01Hz over the past week they no longer run the grid at 60.05Hz for a while to "catch up".

Fun fact number 2 I just learned recently: Southern California used to be on 50Hz! That's right, the USA had split cycle just like Japan. Most of the country on 60Hz, SoCal on 50Hz. Right after WW2 they made the switch apparently. I guess a lot of stuff was dual frequency capable at the time but the utility provided assistance where required.

Fun fact number 3: Ever wonder why we have 110/220 or 115/230 or 120/240? Because every local utility picked their own standard: 110 (from Edison's DC system carried over into AC world), 115, or 120. It was not until relatively recently that we really standardized on 120/240 (+/- 5% which is 114 - 126 but with brief excursions allowed). That's why some old appliances might say 110 or 115 on them.

Fun fact number 4: 120/240 is a backwards compatibility hack. It was too late to change to 240 and 120 is (for physical reasons) better for electric lighting applications (thicker less fragile filament for same light output). How to solve this? Change your MV-LV transformers to 240 but center tap them. Instead of Line-Neutral you provide customers Line 1 - Neutral - Line 2. Connections across L1/L2 give you 240 volts, connections across L1-N or L2-N give you 120 volts! Everyone's happy! There is a NEMA plug standard for low-amp 240V. It has both blades horizontal (looks like the unimpressed smiley face). I wish it were more popular in kitchens for boiling water and such.


Could you elaborate on that? How come it requires being an insider? What constitutes an insider?


Someone who does things not because he read about them on the Internet, but because they were invented or co-invented, or owned by people he went to school with, or family connections. When "system" is not something you fight with, but it's YOU and people who are your family or treat you as a family. Elizabeth Holmes is a prime example but only because she was caught.


Restic over termux triggered by Tasker to s3 (backblaze) . Addionally syncthing to my laptop. Sounds unnecessary complicated, because it it's.


One. Letter. At. A. Time.


The author says the learning curve is steep but it pays off at the end. Somehow I don't really see that claim well supported. Don't get me wrong, I absolutely love the idea of managing my system declarative (aconfmgr gets me somewhat there). I replicate my system on an external SSD for on the go for example. I hate a messy home but resigned myself to it. I come from a functional background, so the learning curve should be less steep for me.

But overall it always seems the amount of work and time for the result is not a reasonable tradeoff. Tried Nix as a package manager a few times, always stopped when simple things took immense amount of time (Emacs with broken fonts?). Have colleagues running NixOS, never heard an argument for it that wasn't half a straw man. Yeah other systems break and it sucks but fixing that takes less time than figuring out how to write your own packages in Nix. Adding to that that I run around and install every second neat thing I see on HN, I struggle to see Nix as more than a Rubik's cube.

What am I missing?


I use home manager for my personal setup. It's just files in a git repo. At my latest job I had to switch from linux to macos. Even with having never been confronted with macos the config barely needed any changes. I was able to get a HIGHLY customized setup working almost identically to my linux setup in less than a day.

If you are someone that says "I just use defaults so I don't waste time getting things set up" good for you. I'm a diva and I have a really custom setup with aliases and scripts I've developed over 10+ years and it would take me weeks to get it all back if I was starting from scratch.

I've tried using ansible and custom bash scripts. Nothing comes close to how effective home manager / nix is at maintaining my diva setup.

You are not wrong though about making your own package being a pain. If nix doesn't have a package (which almost never happens) I just give up and install it with some other package manager manually. I don't have time for that. I used to use nixos but not having an escape hatch was too much.


I’ve been using the same dotfiles git repo for 16 years across Linux, macOS, FreeBSD, OpenBSD. Config files all go in the same place on all those systems: a bunch of symlinks in ~ like ~/.ssh/config -> ~/.dotfiles/ssh/config, ~/.config -> ~/.dotfiles/config

The contents of dotfiles are all versioned controlled so “rollback” etc is all `git checkout …`.

That’s the same as home manager gives you right?

The difference between systems is how to obtain software, but it’s usually pretty similar across OSs, something like INSTALL_COMMAND[os] (PACKAGE_NAME[os][pkg] || package). Probably my setup is not as diva as yours but that difference seems quite small and easy to maintain to me in an install/$os.sh script and the problems between systems come up so infrequently for me that I’m fine not having declarative management.

The dotfiles cross-os scripts are all POSIX sh + git, both are available everywhere.

The only real annoyance I have is if macOS brew installed tmux v9001, but my OpenBSD system has only tmux v1.2, and the config is mutually incompatible. But in these cases would Nix help? The OpenBSD system would need a bunch of upgrades to install Nix, but then I can probably just install tmux 8009 or something directly.

The main advantage to “just git and posix sh” is that I can often use 80% of my dotfiles without root on arbitrary systems over ssh, since I don’t need any software to bootstrap the setup. If I used GNU stow or HomeManager I can’t easily have my setup on random EC2 jump boxes, university servers, borrowed netbooks, mobile phones, etc. I’m not using default configs but ideally I don’t need root to live a happy life.


I recently switched from using a basic git repo to home-manager.

You’re correct that the setup you describe gets you a lot of what Nix can provide. The main thing it is missing is Nix will also manage installing your software for you. I find managing both what my software is and how it is configured with a single tool to be very convenient.


I think a lot of the nix people are overly puritan when it comes to using Nix. Everything must be reproducible, etc. I have found my perfect sweetspot by abandoning NixOS and instead using home-manager + PopOS. That way, if something doesn't work on Nix, I'll just look up the ubuntu guide, BUT i still get by far most of the reproducibility of Nix and the massive package set.

I wrote a longer blog post about it some time ago, if you're interested: https://rasmuskirk.com/articles/2024-07-24_dont-use-nixos/


Agreed. I've been using NixOS on several machines for a few years now, and it has never "clicked" for me either. It's not that the learning curve is steep; it's that the ecosystem is actively hostile to the user, with confusing failures and error messages, poor/missing/outdated documentation, alien syntax and concepts unique to Nix, etc. Maybe all of this makes perfect sense to the creators of the project, and to hardcore users that dedicate a lot of time to it, but, frankly, I don't have that kind of patience.

So recently I decided to give up on it and look into Guix instead more seriously. I played around with it a bit when the project was young, but it was barely usable back then. I'm hoping that it has matured enough to be usable for everyday computing, since it's now relatively simple to install non-GNU-approved packages. It borrows many concepts from Nix (including home management), and Guile at least seems like a sensible language with solid fundamentals.

I do think that the concepts Nix pioneered will eventually trickle down to mainstream distros and other operating systems. They're too powerful to ignore. But Nix itself will not be the tool that drives this adoption.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: