chrisallenlane

I favorited this post some time ago:

https://news.ycombinator.com/item?id=14233542

The Google Groups page is currently in a redirect loop, but if that gets sorted out, you may find the story that you're remembering.

Thanks for the kind words. I'm glad you're finding it useful :)

A documentation PR for Windows would be welcome. I've been meaning to reorganize and improve the documentation for months now, but it keeps getting line-jumped by other priorities.

I'm the author and maintainer of `cheat`, which started life (and continues life) as a "scratch your own itch" project:

https://github.com/cheat/cheat

I wrote it because I often forgot the shell commands that I needed to use on a daily basis, and realized that I wasted a lot of time Googling the same thing over and over.

> So your code can go as fast as you like

I've been working on an (IMO) sophisticated tactical game with strong AI in Pico-8 for just about two years now, and I can say that this is not true.

> which would require some kind of CPU-cycle accounting tracking

This is pretty much what it does.

Pico-8 tracks an arbitrary "cycle" budget, which is used to calculate how much computation you're allowed to perform per frame. You're absolutely not going to compute at "bare metal" speed.

Here's some info in the (community) docs:

https://pico-8.fandom.com/wiki/CPU

I don't know how this does/does not compare to the 6502, because I unfortunately don't have any experience there. But you're absolutely not going to get bare-metal performance inside of Pico-8.

You're right about limiting code-size, though. For my own project, the code size limits have proven far more difficult to work around than the performance limits.

Tangent now, but these are some of the Pico-8 limitations:

- screen is 128x128 pixels

- only 16 colors are available (sort of... there's a "hidden palette" too)

- cartridge size may not exceed 32 kb

- cartridge may not exceed 65k characters

- Lua AST may not exceed 8192 tokens

That last one has been the hardest constraint for me to manage, by far.

Anyway, Pico-8 is a ton of fun. Try it out if you're inclined :)

I've discovered a workflow I'm happy with.

I run Debian stable on my workstation, and manage most of my packages with `apt`. As such, everything "just works," and flawlessly.

For the handful of packages that I want to upgrade aggressively, I manage them with Nix[1].

I've been doing this for maybe two or three years, and despite a little extra complexity, it feels like a best-of-both worlds scenario. I get the rock-solid stability of Debian stable, but the one or two packages that need to stay cutting-edge are able to do so.

I also don't have trouble with package conflicts, because the entire point of Nix is to prevent those kinds of problems.

This has been great for me. Do recommend.

[1]: https://en.wikipedia.org/wiki/Nix_(package_manager)

This is petty, but I'm also constantly annoyed by the presence of the `snap` directory in my home folder, which (to my knowledge) is hard-coded and not configurable. Now, if I want to back up my home directory, I have to configure my backup tools to exclude `snap`.

I don't know why the default location couldn't have been in `/usr` or `/opt` or something, or ideally simply been configurable.

> $8m isn’t going to get you to 1/20th of Unity or Unreal

The size and complexity of these engines can be a disadvantage, because not every game needs the features they provide. For some use-cases, it can be easier to work with a simpler engine with fewer abstractions, a smaller API, and a shorter learning-curve.

This is the main reason I cancelled my gym membership. I got tired of going to the gym to clear my head, only to leave angrier than when I got there.

I don't know why more gyms don't show sports on the TVs. It seems like a much more natural fit.

> required a lot of hand holding from the devs who had been working on it from the start to teach me how to find/read and debug everything the "Ruby" way.

Yes. And even just _finding_ relevant bits of code is difficult and painful, because you can't simply `grep` for the names of these metaprogrammed methods. They're simply not in the codebase.

I've been running a DIY model for about a year as well. My only complaint was likewise that installing the wifi antenna was _very_ tricky. I briefly thought I had broken it before it finally came together for me. (It sounds like they've mitigated this issue by now, so that's great.)

I also had a few of the Linux issues that others have mentioned, but upgrading to the newest Ubuntu solved them.

Overall a fantastic machine, and probably my favorite laptop I've ever owned.

I'm the author of `cheat`. The two tools are somewhat less similar than they initially appear, due entirely to poor documentation on my part.

If you're interested in a breakdown of the differences, I elaborated on this recently:

https://news.ycombinator.com/item?id=31600605

`cheat` allows you to create cheatsheets on your local machine, so you can trivially create whichever Powershell cheatsheets you need.

I don't believe we have any Powershell cheatsheets in the upstream community repo yet, but if you create some, please share them! They would surely be appreciated.

It is! There's a wonderful community-maintained `brew` package for it:

`brew install cheat`

I didn't link the article, but it's my pleasure. `cheat` was first and foremost a "scratch your own itch" tool. I'm very happy to see that others are finding it useful as well :)

I'm the author of `cheat`.

First of all, `tldr` is a lovely project, and if it's working for you, you should continue to use it.

If there's distinction to draw between the two projects, it's that `tldr` (to my understanding) is primarily a client for serving cheatsheets that are maintained in the upstream Github repository.

By contrast, `cheat` is focused around allowing users to create their own cheatsheets (stored perhaps only on their local filesystem), and is useful for storing cheatsheets in which others may have no interest.

`cheat` also allows you to sort and search these cheatsheets (which are just markdown files) by "cheatpaths", which are named directories in which cheatsheets may be stored. Cheatpaths have specificity rules that are configurable, such that cheatsheets on local cheatpaths may be preferred above those on global cheatpaths.

As a personal example, I run 3 cheatpaths:

- the community cheatsheets (contained on Github)

- personal edits I've made to the above

- cheatsheets for my dayjob

So, as an example, the community `ssh` cheatsheet is on the global cheatpath, and should contain the cheats that everyone should care about.

My personal `ssh` cheatsheet will contain edits I've made to that cheatsheet. Here, I'll store little tricks/tips/whatever relevant to my personal workflow that are useful to me, but will not be useful to others.

The dayjob cheatpath contains cheatsheets regarding how to do various tasks pertaining to my dayjob. How to start an app, or restart the CI server, or whatever.

Another example: I recently moved. I have an `address` cheatsheet that displays my new address, which I have yet to memorize.

So, `cheat` is perhaps better if you're interested in taking personal notes like this, whether of a technical or non-technical nature.

If you're primarily interested in community cheatsheets, you should keep using `tldr`! It's a wonderful project.

This was essentially my primary motivation for writing `cheat`. The `man` pages are thorough, but often lack examples demonstrating the common use-cases.

I eventually tired of Googling "how to extract a tarball" (because I'm too lazy to read the lengthy manpage), and decided to create some supplemental tooling.

I'm the author of `cheat`. Regrettably, I agree with you regarding the lack of `apt` packaging as a major barrier to adoption.

I've looked into creating it previously, but found it to be non-trivial. Like a lot of FOSS maintainers, I'm pretty strapped for time these days, and I simply haven't gotten around to it yet.

The next round of work I want to do on this project is to improve the CI pipeline. My dayjob these days largely involves configuring CI pipelines, and yet the `cheat` workflow for the time being involves me running `make` on my local machine and dragging-and-dropping binaries into the Github UI. It's embarassing.

Once I get the CI squared away, I'll take a look at `apt` packaging.

Seeing this project on Hacker News has given me renewed motivation, however. Perhaps I can free up some time this weekend :)

`cheat` is not a fork of `tldr` (I'm the author of `cheat`), though the latter is a lovely tool.

Oh, weird.

I'm actually the author of the `cheat` tool. Feel free to ask me if you have any questions about it.

> 2. The swappable port system is actually a lot more useful than I expected.

I'll second this. I was momentarily annoyed earlier in the week when I reorganized my desk, and found that the USB C port was on the "wrong" side for my cable-management. It took me a moment to realize that this was (for once) a solvable problem.

I've been running Linux on mine for about a month now and love it. It's easily my favorite laptop I've ever owned.

Perhaps this would align everyone's incentives:

- Only honor PRs against repositories that have opted-in

- Only allow repositories that meet certain "notability" criteria to opt-in (to prevent the creation of "fake" repositories)

- Only honor PRs that are merged within a specified time-period

- If DO has the resources, volunteer some folks to filter/close spammy PRs on the participating repos

I maintain several open-source projects, and the spam would annoy me. That said, if the constraints above were applied to Hacktoberfest, I would opt-in my own projects. I think these constraints would do a reasonable job of disincentivizing people opening spammy PRs (because I simply wouldn't merge them), while bringing my projects to the attention of developers that are looking to make a contribution to open-source in good faith.

> there's also a subreddit called buyitonce iir.

You're thinking of /r/BuyItForLife.

Agreed. Discord is also what got me off of Facebook entirely.

Discord today feels like how Facebook used to feel when it started: I'm actually friends with everyone on there, and we're having real conversations.

There's also 100% less politics, moral panic, virtue-signaling, outrage, ads, "fake news", Farmville invitations, and similar garbage.

It's nice.

> I doubt it is permanent but the next few years will be difficult for media establishments when they need to restablish trust

Why do you doubt it is permanent? I'm personally very pessimistic about this.

There's no server here. This is just an executable written in node, which writes to a SQLite3 (flat-file) database.

I'll throw mine into the pile of other solutions posted here. I hope someone finds it useful:

https://github.com/chrisallenlane/node-did

I don't know why people are giving you a hard time here. The quote is widely-known, and I appreciated your remark about the troubling lack of falsifiability criterion.

If they can, they probably will.

> BTW, with a blockchain solution, these are not at all "impossible to alter". That would only be true for a blockchain that is actually decentralized and heavily mined.

An excellent point.

I wonder if a market will emerge from the need to secure (and thus mine) these private blockchains. IE, perhaps Walmart could secure its logistical blockchain by compensating miners in "WalmartCoin", which is redeemable at the store.

This is sometimes referred to as "analysis paralysis."