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

Nobody is interested in AI commentary.


That seems incorrect. This sub-thread is the longest already in this submission, and no other commenter remarked about the parent commenter being an AI.


or 'cascade' ?


Well, I just remembered that in SQL "ON UPDATE CASCADE" is specified on downstream keys (children), not on their target (parent).


I replaced all my Dropbox uses with SyncThing (and love it). I run an instance on my server at all times and on every client.


+1 for SyncThing

I have it installed on my immediate family's devices to ensure all the photos are auto-backed-up to our NAS (which is then backed up to another NAS).

I need to check to make sure it's still working once in a while (every couple of months), but it's usually fine, and even if it's somehow stopped working, getting it running again catches itself up to where it should have been anyway.


If you think about it the spirit of the internet is based on collaboration with other parties. If you want no third parties, there's always file: and localhost.


Yeah I would argue that it's possible to do it well with Backbone, and you end up with something much leaner but it requires a really strong understanding of state/event flow and lot of discipline, whereas with React the correct way to handle this is the 'obvious' path, which dramatically lowers the barrier to entry.


And now everyone has phantom unreads again because it is cyclical and a different team is in charge of every other div


A good engineer is not a perfectionist, but they're not callous either. It's knowing when to make the trade-off, or at least making an informed guess.


that's half of engineering


that's half of a comment


one of many things, but agreed


For me they are weirdly hard to obtain. Don't show up in second hand shops. Ebay shipping is prohibitively expensive.


Interesting. I still have a bunch showing on my local Facebook Marketplace, but who knows what shape they’re in plus it probably varies a lot from city to city.

I can well imagine that it’s gotten expensive finding a quality one (eg trinitron) of reasonable size.


They are truly dying out. Wish I'd kept my color c64 monitor -- it would probably be worth a lot now (or at least would be awesome to use for retro purposes).


They don't show up in second hand shops because their value is essentially negative. If it doesn't sell, you have to pay to dispose it.


There's 2 cases being discussed. A UUIDv7 is a bad secret, but it's fine for many other ids. If I can guess your user id, it shouldn't really matter because your business logic should prevent me from doing anything with that information. If I can guess your password reset token it's a different story because I don't need anything else beyond that token to do damage.


But the random part of a UUIDv7 is 74 bits... larger than a 64-bit integer of random values. Larger than many systems use in total when generating random keys for such things. Likely a larger number of values than the total number of comments here on HN over a couple decades. It's emphatically NOT guessable.


I don't think you'll find many recommendations for key lengths under 128 bits / 16 bytes these days.


Looks great! Curious what the author and others use for local maildir email reading.


I use isync and notmuch! With aerc as my reader.


mu4e, but I suspect that a local maildir is a poor choice anyway.

It's better to have a local cyrus running and connect to it by imap, with, say, gnus.


Well, it says its bidirectional, so perhaps you could run two instances pointed at the same local maildir, but at different IMAP servers?


You can do the same with a local cyrus.


A bit of an alternative take on this, but I talk to a lot of folks at small start-ups (in Toronto, if that matters), but it seems like most people actually get this right and understand not to bring in complexity until later. Things like microservices seems like they are mostly understood as a tool that's not really meant to solve a real scalibility problem and is massive liability early on.

The exceptions are usually just inexperienced people at the helm. My feeling is, hire someone with adequate experience and this is likely not an issue.

I do think architecture astronauts tend to talk a lot more about their houses of cards, which makes it seem like these set ups are more popular than they are.


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

Search: