Just wanted to mention Stow[1] here, which I use to symlink my dotfiles on a new machine on a per app basis for many years now. My set up script just installs basic compiler toolchain and runs a bunch of stow commands based on Linux/Mac OS. I also adhere to XDG base spec[2] so I can keep my ~/ clean.

1: https://www.gnu.org/software/stow/ 2: https://wiki.archlinux.org/title/XDG_Base_Directory

Also, the latest version (>= 2.3.0, released June '19) has a new flag specific to managing dotfiles. When passing `--dotfiles`, stow replaces `dot-` at the beginning of filenames with `.` in the symlinks. The online help does not mention it, but the release notes and man pages do.

Stow is the answer as far as I'm concerned. It's been around forever, it's standard, available in every package manager, the defaults just work.

I use it in combination with a make to automate the setup of a new install.

Yeah, I don't understand why people like reinventing the wheel, Stow works, Make works, both are available everywhere, you don't need 30 layers of JS to manage dotfiles, I'm not against progress, but at least make something better than what's already around.

I really like stow. It handles almost everything for me.

One thing, I didn't split things by apps per se. I split them based on task. In some machines, I do Python work, so I created a 'python' package. In some I do PHP, so I created a 'php' one. I have a 'base' one where it has my .bashrc, .profile, .bash_profile, fish configs and other things.

Everything in the .bashrc. .profile, etc is loaded around conditionals. So, while the files are long, the section only activates if the other package is available. I thought about splitting it onto files, but most editors have a way of collapsing sections, so I decided to keep it on one so it's easy to edit in one place.

How do you manage dotfiles of apps that overwrite symlinks? Eg: Xfce frequently does it.

I do not like comments, which are basically upvotes, but yes, Stow is the answer and this should be the top comment.

Unfortunately Timescale's license is the blocker - https://news.ycombinator.com/item?id=25299128

yes, we'd love to offer Timescale as an extension, but still waiting for buy-in from the Timescale team on this.

If we can't manage we'll eventually do something else for timeseries data - eg, we could do a Foreign Data Wrapper to Clickhouse tables

Why use FDW if you can work with ClickHouse directly? What is the use case?

By the way I can see there are some already but I do not use them https://github.com/Infinidat/infi.clickhouse_fdw/ https://github.com/adjust/clickhouse_fdw

> Why use FDW

It would be beneficial to couple transactional data (Postgres) with OLAP data (CH). There are a few other things coming in PG which might mitigate the need for CH too (pluggable storage, zheap), so we're not going to rush this part.

Would've loved it if it wasn't a JUCE wrapper. Nevertheless, some great work here. The same approach can be applied to any non-JUCE stuff too, which would be kickass! :)

Why do you say that? I've built the core of the engine entirely from scratch, entirely indepenent of juce. The CLI tool does use juce for opening the audio device, but that's about it.

When choosing to apply parallelism, it should never be about the length of the collection but only the computational intensity of the function that's being applied. There's a considerable overhead in spawning processes and collecting the result from them

There's a considerable overhead unless they are _lightweight_ processes.

This made me smile! :)

I've never gotten this drunk.

Thanks Ashwin. So the main thing that differentiates us from other players is the philosophy that we have towards travel planning which we summarised in one of our blog posts: http://blog.planmy.travel/post/65971193858/what-do-instant-c...

Awesome! Excited to check out your new product!

Why the fk is this on the front page of HN?

Evernote. Trello. Google Docs. Three top tools I use / have used for this purpose.