"And then one day you find
  Ten years have got behind you
  no one told you when to run
  you missed the starting gun"

And while it's pretty absurd, in the story, such tiny mistakes having such outsized consequences, the story reminds us that such severe consequences are well within the realm of possibility. People do lose limbs off of little, careless mistakes. Doubly so with all the incredibly concentrated sources of energy we have in the modern world - power tools, automobiles, explosives.

Would one really lose ten years trying to pick out a single Netflix show? No. But could one wake up one day and realize that they'd accomplished nothing of note for a decade, that all their free time was dumped into Netflix shows that weren't even that good?

So, what do you do with all that? Memento Mori, I guess.

I captured a video on a smartphone camera, using the OpenCamera app. Specifically, this video was captured with exposure locked, framerate locked, focus locked, fairly high framerate and resolution. I walked slowly and carefully around an outdoor scene, trying to get fairly good coverage from multiple angles. I took roughly 20 minutes of video, weighing 19GB.

This video was sampled into individual image frames at about 5fps using ffmpeg. There's room for experimentation and improvement here, an adaptive, coverage-aware sampling strategy would be better. But fixed 5fps was Good Enough (tm). This resulted in roughly 8,000 images at 4k. This was a pretty hefty dataset for my limited 1080, but I made it work.

I then generated masks for these images, to ignore transient objects during the splat training. (i.e. to cut out people who transiently walked through the scene). For this I used Cutie (https://github.com/hkchengrex/Cutie). For outdoor scenes, it can also make sense to mask out low-parallax areas like faraway mountains or especially the sky, as these are difficult to train correctly. If masks are generated for some images, you'll need at least placeholder masks for the all of them. In the end I've got about 8,000 PNGs that are monochrome black/white masks.

Then the images are handed to COLMAP (https://github.com/colmap/colmap), using the 'global mapper' option. This registers the camera positions in 3D space, and generates a crude point cloud that's good for sanity-checking. This step required a fair bit of iteration to get right. The full reconstructed output from COLMAP is not necessary, only the pose-estimate .bin files. The output directory here was about 500MB for this step for me.

With COLMAP registration done, the next step is the actual training. I found two useful pieces of software for this, with different tradeoffs.

Brush (https://github.com/ArthurBrussee/brush). Was very straightforward to install and use, requiring very little in external dependencies and setup. It was also pretty speedy on training, and gave good results. Minor modifications to the training process were possible by editing source, though I didn't get too wild here. Brush takes the *.bin files from COLMAP, plus the original images directory, and the masks directory if it exists. Run on its own, this could produce gaussian splat .ply files, 500-800MB in size, containing 1-10M splats. More than that and my poor little 8GB of VRAM OOM'd.

nerfstudio (https://github.com/nerfstudio-project/nerfstudio) Was also useful, as many research papers get implemented in its framework. In particular, for this outdoor scene, I used wild-gaussians (https://github.com/jkulhanek/wild-gaussians/) to generate just a sky sphere (to help seed low-parallax areas in my particular dataset), stopped training, and used this as an init.ply to pass to brush.

I then set up a very simple viewer website, using SuperSplat (https://github.com/playcanvas/supersplat). I used supersplat's editor to align the splat's coordinate system with the rotation and scaling that I wanted, and then exported an optimized .sog file, roughly 1/10th the size. .sog is nominally open-standards, though I'm not aware of any other projects using the format. This gave fairly good framerates and adequate controls across a variety of platforms.

As a little bit extra, supersplat's splat-transform CLI tool was used to generate a crude collision mesh for the scene, enabling a walking mode that respected object boundaries.

If there's interest I can post my results, I got a bit sidetracked with other projects and other splats, and this particular one I got fiddling with some more cleanup. I can get it up with a few more hours work. But hopefully that's a good start, all of these are fully FOSS, and resulted in a good-looking splat.

For all the other differences in culture, the attribute of "People Actually Care" seems to have a huge impact on how pleasant a place it is to visit or live.

I don't know why it seems to be the case there. I don't know how to replicate it. I don't think it's magic. I've heard people bandy about the theory of cultural homogeneity. That might be a _factor_, but I doubt it's the full story.

I suspect if you dig into it, differences in economics are a major factor. In the US, it feels like caring is actively punished, economically. Caring is nice, but someone can only _afford_ to care if their other needs are met.

I also wonder if density is a major factor - not so much for the difference in economy of scale, but the difference of "if my physical space is incredibly constrained, I'm both more incentivized to keep it looking nice, and there's less of it to keep looking nice."

And, of course, it's not like Japan is some kind of otherworldly utopia. There's serious tradeoffs and differences, there's negatives compared to other countries. But it does seem like almost everyone, everywhere, just... puts in a bit more effort. Takes a little bit more time.

I don't know why there was a branding change, but the capabilities seem pretty similar to the RCX I had as a child. Though programming over bluetooth is likely to be more reliable than the IR adapter.

You can often do this pretty easily, with keyboard shortcuts or hardware buttons, and it does a lot to limit your temptation to re-read your draft while you're still writing, and makes editing (temporarily) impossible.

Are there legitimately multiple good examples of "Criticized on HN pre-launch, yet became surprisingly successful"? I'm curious if the lesson to learn from Dropbox & iPod is more of "believe in a product, despite the criticism" or "sometimes, even accurate predictions are wrong"

In general, home values have consistently increased, year-over-year, in California. This means that many people pay less property taxes than they would if California didn't have its unique Prop 13.

Many people feel that this is an unfair law, as it largely benefits people who are _already_ financially established.

This article satirizes the situation, by framing the law as an intentional 'welfare program', rather than a tax break with unintended consequences. Part of the humor is that this 'welfare program' benefits the wealthy at the expense of the poor, contrary to how we typically think of philanthropy.

Worst they can say is "no can do".

The one time I asked, it turned out that our server was ~30 years sober himself, and asked their bartender what they could do.

What they could do was, a variety of alcohol-substitute drinks, mixes of spices that didn't replace wine, but achieved the same culinary role, and custom dry cocktails. Drinks that, given the description, I never would have ordered. Drinks that, by themselves, didn't do what I thought a beverage did. It was amazing.

I don't think this is accurate. https://english.stackexchange.com/questions/160026/does-the-...

* These languages prefer to operate on structured data. If it parses from json, you have a much easier time. But, most commands you'd invoke from the shell emit unstructured text by default. You can deal with this, but it's a pain point, and it means any serious scripting starts off with a "here's how you parse the output of ", and several rounds of debugging.

* The shell's first and foremost usage is a user-facing interactive interface to the computer. Most of what you do is invoking other programs and seeing their output, and doing this is very easy. While python & ruby have REPLs, these are mostly focused on trying out language features or testing code, not invoking other programs, nor navigating a file tree. A lot of shell scripts start as 1-liners that grow and grow.

* Invoking other programs: In sh, invoking other programs is the primary activity, and it's relatively straightforward - you type the name of that program, press enter, and hope that it's on your path. In Python or Ruby, it requires importing the proper library, choosing the correct command, wrapping it and arguments, and ensuring everything escaped correctly. [Ruby _does_ have the backticks operator, which does actually make a lot of 1-off scripts easy, but this is not a panacea]

* In sh, a lot of the 'utility' programs like cut, sed, awk, grep, head, tail, etc., are standing in for the capabilities of the language itself. In pure Python or Ruby, you'd do these kinds of things with language built-ins. But, that's a learning curve, and perhaps a bit more error-prone than "| head".

* On top of all that, yes, momentum. If tomorrow you showed me a shell replacement for nix that was unambiguously* improved in every way, had excellent documentation, community support, and was actually pre-installed on every machine, it would still take a decade or more before it was really a default.

-----

I want it to happen, so I'd never discourage anyone from taking a swing. IMO, some of the top-level considerations that are necessary for making a successful sh alternative are:

* minimize the additional # of characters required to invoke a program with arguments, compared to bash.

* Decide which suite of typical utilities should actually be built-ins (i.e., things like cd, ls, cp, grep, curl), and make those standard library, built-in, without additional import or namespacing.

* Focus on an append-style workflow. Functional programing styles can kind of help here. Wrapping things in loops or blocks is a point of friction.

* An additional highly-desired feature which just isn't in sh by default, to overcome momentum. I have no idea what this would be. More reliability and better workflow are _nice_, but sh is sticky.

Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out.

If the commit subject rather, is "bugfix flaky builds", followed by a message that explains what the flakiness was, why you think the change will fix it, what other bugs or limitations you were working around, and what upstream changes you might be waiting on that prevented further work, you're in a much better position. Suddenly you have a lot more context on what you were doing, why you were doing it, why you didn't do it better at the time, and in some cases it can even catch you from making an obvious but subtly-wrong mis-step.

Similarly, if someone's confused by your code during code review, that's a great opportunity for either in-line comments, or commit messages, as appropriate.

Unlike PR discussions, tickets, emails, slack threads, wiki pages, or photos of whiteboards, commit messages + git blame has an uncanny ability to be exactly the documentation you need exactly when you need it. Good git history practice can be one of the highest returning investments.

I've got a gtx 1070, which at this point is pretty far from top-of-the-line VR-capable card. I'd probably get significantly better performance improvement per effort spent by upgrading my card than I would by tweaking the OS.

I can pretty consistently enjoy VR games. I haven't tried vr web browsing in a while; I remember it being pretty finicky on Windows several years ago.

The June Oven does this, and it works pretty darn well IMO. It's using just a video camera to do food recognition, but it's fairly high-accuracy for recognizing supported foods. The first few times you do it, frankly, it feels kinda magical.

But, actually, a lot of my usage doesn't lean on the pre-set programs. Rather, I do a lot of 'reheat leftovers' by sticking a temperature probe into the food, hooking it in to the oven, and having the oven automatically reheat until the internal temperature is warmed.

For our rehearsal dinner, we had maybe ~30 people, and did a 4-course meal.

For each course, everyone was assigned different tables, such that over the evening, everyone would get at least one course with everyone else

I helped set them up with an SSH tunnel, and appropriate browser settings, for bypassing the Great Firewall.

I wanted to teach them how to play Magic: The Gathering, and MTGO at the time did not seem like a good option. I built a very basic 2-player game which allowed for specifying a decklist as a set of image URLs, and had the basic motion primitives of shuffling a deck, drawing, tapping cards, and such.

One particularly nice UI thing it had, which I wish I'd see more often, is that it showed you each others cursor positions in real time, so you could virtually "point" as part of discussion or communication. [The source for this has likely been lost to the bitrot of time, but it might be buried somewhere in a backup]

Finally, we liked to watch TV shows or movies together. This was initially done as "download the same file, get on VOIP, and count-down to start", but this was fiddly, especially if someone had to pause or rewind. I built a very simple utility to synchronize playback of the file between two VLC instances. It looks like this is actually my oldest github repo! https://github.com/YenTheFirst/VLCSync

More than a decade later, they're no longer in China and thus don't need to bypass the firewall, and we lost interest in M:tG, but we married, and the video synchronization problem became remarkably simpler. :)

Personally, I'm kind of enamored with the idea of a phone or tablet for media selection & control.

On touchscreen based devices, I'm a big fan of https://en.wikipedia.org/wiki/MessagEase.

When I started looking into alternative text entry for a phone, the big thing I was looking for was the ability to completely disable predictive text entry. Messagease allows for that - I'm able to input text quickly, accurately, and without the use of predictive input.

I've used it while holding my phone in either hand and using the thumb of that same hand (though it works better in my dominant hand). I've also used while holding the phone in my non-dominant hand and using the index finger of my dominant hand.

I can almost, but not quite, use it without looking.

So, if you're thinking of a custom remote project to scratch that itch, that layout may provide inspiration.

That said, I have this same pianist's album of Well-Tempered Clavier, and I think it's quite nice. (https://music.kimiko-piano.com/track/prelude-no-1-in-c-major..., for example)