Almost none of them had Dropbox accounts.

I found out later from someone that 90% of them couldn’t access the files. The link didn’t require a login but they made it look to the unsophisticated observer that you need an account to get the files. So these folks (most of them were elderly), just gave up.

The basic setup has more or less stayed the same, but there's some more extra components around it you have to know now (spam filtering and SPF/DKIM/DMARC come readily to mind).

To quote Michael Lucas: "everything complicated about emails revolves around spam and not getting it". I highly recommend his book, "Run Your Own Mail Server".[1]

In short, hosting your own email is not that bad at all. I strongly suspect, like many other skills, since it has atrophied with the advent of the cloud and people readily giving up to the large carriers, it has gotten the reputation of being hard, or as you said, a full time job. I don't think either of those things are true.

[1] - https://mwl.link/run-your-own-mail-server.html

Purchased this last month and really regret not buying it years earlier (we got the 5L CV-DCC50 model).

It's amazing how we never worry about boiling water anymore (apart from large pots of water for cooking pasta or something).

Our electric water kettle sees very little use now.

I also use vim, and I use it a bit to edit my beancount files, but I mostly use fava, a most excellent web interface for beancount. In addition to having a built in editor (which does formatting and can catch errors and show you exactly where they are), it allows you to quickly add new transactions based on old ones — the dialog box allows you to choose from previously used accounts to speed up input. It’s a lifesaver. I don’t think I would have continued using beancount long term if it wasn’t for fava.

Just about the only negative thing I can say about fava is that it does formatting slightly differently from bean-format. I actually prefer it to beancount, but there are some cases where I prefer the native formatting (like when declaring/opening accounts). So for some months, I will switch from one to another. A minor nitpick, but it’s slightly annoying.

Unless someone buys them out in the future and platform decay[1] happens, you can trust them.

[1] https://en.wikipedia.org/wiki/Enshittification

I was there two weeks ago. The tour guide took us through a route that bypassed the longer lines and through some underground areas—culminating in an entrance that completely blew my mind. I never realized how huge the interior was until I stepped in and saw it firsthand. There are few things in my life that completely took my breath away, this ranks in the top 5 for sure.

I attended his tutorial and talk at BSDCan[3] this year and both were excellent. I highly recommend buying the book when it comes out (or supporting the Kickstarter), it will go through all the gory details of setting up and running a mail server, and best practices, including a ton of material on SPF/DKIM/DMARC.

(P.S. I have no affiliation with the author or the book in any way.)

[1] - https://mwl.io/

[2] - https://www.kickstarter.com/projects/mwlucas/run-your-own-ma...

[3] - https://www.bsdcan.org/2024/

They were very useful when you were looking at a source file, to see what version of that file you had.

Git had something similar with Git Attributes[3], but AFAIK, they were just references to blob ids, so they never really took off.

For git, I now use tags (and versioning based on tags), that more or less replaced svn/cvs keyword substitution in the git ecosystem.

[1] - https://svnbook.red-bean.com/en/1.7/svn.advanced.props.speci...

[2] - https://www.gnu.org/software/trans-coord/manual/cvs/html_nod...

[3] - https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...

Here's the blog entry[1] where he talks about the rationale for writing the tool.

The page mentions that it is inspired by Markdown, but is not actually Markdown because it was designed for HTML.

I'm glad to see more projects in this space.

[1] https://drewdevault.com/2018/05/13/scdoc.html

Comments URL: https://news.ycombinator.com/item?id=38481392

Points: 4

# Comments: 0

Not saying your summary of that thread is wrong, I just wanted to expand a bit to maybe clarify:

    - someone posted to NANOG about issues with their (European) servers reaching 0.freebsd.pool.ntp.org
    - they noticed they were being routed through Tata (AS6453)
    - they mentioned that their other servers (e.g. in Africa) had no issues
    - they posted to NANOG to ask about this
    - they thought it was a routing or FreeBSD issue (they later posted about the issue to a FreeBSD list as well)

    - the NTP pool uses GeoDNS to map clients to servers
    - the OP's server IP address was incorrectly geolocated to Mauritius
    - the Mauritius zone in the pool has only one server
    - so the OP would only ever get that IP as an answer

Full thread here:

    https://mailman.nanog.org/pipermail/nanog/2023-August/222706.html

From there, that sub-thread was mostly about NTP attacks and GPS security and mounting receivers on top of datacenter buildings and such.

Counting up the messages (if my mail client's threading capabilities are to be trusted), of the 94 or so total messages in the thread, 79 (84%) of the messages were in that GPS-related subthread, and only 15 messages responded to the OPs issue directly.

I didn't really see this as a failing of NANOG per-se, it's just a public mailing list and some folks went on a nerd sniping tangent (cf. XKCD #356).

In the past, I would update the OS and ports religiously, sometimes rebuilding world and packages on a weekly basis. I've never once experienced any bumpiness between v5.x and v8.x (or any other version, but see my comments on v13 below). The OS has always been rock solid.

I have occasionally experienced some package issues, usually when upgrading a port that had lagging dependencies -- some packages written in PHP come readily to mind. The number of times this has happened is more than 2 and less than 6, and in each of those cases, using portdowngrade and waiting it out a few weeks did the trick.

Apart from OS-independent hardware issues, the only real FreeBSD issue that I've ever encountered was in the v12->v13 upgrade. If you were running ZFS, there was a gpart bootcode command you needed to run as part of the upgrade process, which I sometimes forgot to do, which caused the post-upgrade reboot to hang. Normally this wouldn't be a big deal, you just insert the rescue CD and run the command and be on your way 2 minutes later; but at that time I had a number of my servers running on a VPS provider that didn't allow you to mount your own ISO, so I had to wipe the machine and reinstall the OS from scratch and restore stuff from backups. I don't really count this as a FreeBSD issue per se, just an obtuse service provider. (I've since moved most of my digital properties oceans away from that company.)

Nowadays I upgrade the OS and packages far less frequently. I upgrade the OS with every minor release and also if there are any security issues that affect me. I upgrade the packages every couple of months, or if there is a bugfix that affects me, or if I need a new feature only available in a newer release.

Since I started using it, there have been a number of developments that have made my FreeBSD life so much better: cperciva's portsnap and freebsd-update, pkg-ng, and of course the biggest one: ZFS. All of these allow me to maintain and upgrade the systems very easily.

I stick with FreeBSD because of its consistency and ease of use, so I'd be curious to know what you mean by "bumpy"?

https://bsd.slashdot.org/story/02/05/14/0015234/freebsd-perl...

And this was the right move. It meant that the version of Perl was decoupled from FreeBSD releases, allowed you to choose which version to install, and allowed you to install multiple versions if needed.

Probably my favorite is the built in TUI interface, that feature rocks.

I don’t recommend it for larger projects where you have lots of committers, the in-built feature of GitHub/GitLab probably works better for those types of setups. Where I think this tool really shines, and the perfect use case for it is with the dozens (or in my case, hundreds) of little repos you have where A) either you are the only committer, or B) the project is small (for some definition of that term), or C) if you want something setup quickly to track issues/features/milestones, you can always switch to something else later.

They had to take him to the vet where they fed him charcoal and pumped his stomach. =-/

I had initially been turned off when I first encountered it, because it seemed overkill for (what appeared to me) a simple task.

But the problem of managing a relatively small number of dotfiles across a relatively small number of machines with small differences between them and keeping them up to date proved to be MUCH more complex than I imagined. Copy things around by hand, and then later distributing them via source control got hairy very quickly.

I finally realized all those features were absolutely necessary to manage things sanely, and once I took some time to learn how to do things with chezmoi, I have never looked back.

In addition to its docs, I found the authors dotfiles repo on Github to be a great help on how to set things up: https://github.com/twpayne/dotfiles

(FWIW: I have never used NixOS/Home Manager, so I can't really speak to how it compares to chezmoi.)

I’ve long awaited more stuff from Ron Gilbert since then.

Decades later I am still professionally and personally using and benefiting from the tools and lessons he encouraged and helped everyone out with back in the day.

My only regret was that I never got a chance to meet him and thank him in person. The closest I came was at Usenix LISA '11 in Boston when I was speaking at a config management BoF: after the session I was engaged in discussion with a German chap who I later found out was from FU Berlin. It turns out he knew Sven quite well, so I gave him $20 and asked him to give it to Sven to buy some beer on me. A small gesture for the considerable help and advice he had given to people like me.

Rest in peace my friend. You made the world a better place with your kind words and deeds.

Thanks for sharing this, I'd been doing this on my own for my own stuff (eg. foo.txt-xxh32-ea79e094), but it's good to know someone else has thought it through.

I ran into the problem once where someone had named some files foo-fb490c or something similar without any annotation, and when there was a problem, it took a file to figure out they were using truncated sha256 hashes.

(You don't have to use all the listed cities if it slows down the hTime web app, just pick some minimum population threshhold (eg. every city larger than 100k people) and use those.)