HN user

szhu

763 karma

https://github.com/szhu

Posts4
Comments143
View on HN

I think that's actually just an example of either ask culture or guess culture, depending on the context.

If the friend should only say yes if they really want to, then that's ask culture.

If the friend should feel obligated to say yes, then that's guess culture.

The only difference here is that the request is worded differently (as a statement rather than as a question), which is simply close friends adopting their own language conventions, a slightly-related but independent concept.

That's a ceiling for the speed the autopilot is okay with letting the lander descend. There is no ceiling to how much hard it will try to "apply the brakes".

I agree that the target velocity calculation is off though. I was excited that I came up with something reasonably theoretically correct for correcting rotation... and for figuring out when to fire the engines I just gave up and eyeballed it :)

I really wanted to!

But unfortunately none of the lander's stats are exposed as global variables, so the only way I could make the autopilot was by modifying the existing code. (My commits are actually broken down exactly like this: a commit to expose the necessary variables globally, and another to actually add the autopilot.)

I would also love to be able to play it in the original game though, so I made a PR! I think it would be cool for it to be able to be activated as an easter egg.

https://github.com/ehmorris/lunar-lander/pull/7

Similar thing I made recently, but as a Chrome extension:

https://github.com/szhu/pagefreeze

It does the same thing, and in addition also prevents any async JS from running. It also can be easily toggled per-site; just click the extension icon! Unfortunately I didn't have time to put a GIF in the README. OP did a better job of explaining what their project does!

Would love feedback on it + hope it helps someone as well!

This thread has a lot of people arguing for the live visuals use case over protecting privacy or vice versa. Not only are they both important, but I think we can actually have both.

To easily solve both the privacy and the live visuals issue, Apple should make it so that the dot is only shown on a display of it is:

- the primary display (the one notifications appear on, since that's where the user typically checks for system status),

- the built-in display, if any,

- the display the cursor is on, or

- the display containing the frontmost window.

These are the only kinds of displays that make sense to have a persistent privacy indicator on. Anyone who's sitting at a computer is looking at at least one of these displays.

The secondary displays that artists use to show fullscreened live visuals always fit none of these criteria.

This used to be the default option! I still remember the WWDC keynote where the feature (called Resume) was introduced. Having it on by default made for a really cool demo, where all the windows were restored after a restart:

https://youtu.be/LPMjUtfQPks?t=19m16s

Not only was it on by default, there actually wasn't an easy way to turn it off, leading to tips like this:

https://osxdaily.com/2011/07/18/disable-mac-os-x-lion-resume...

I'm not sure when the option was added or when it stopped being on by default.

It still works in Big Sur! Just hover over the window title and the icon (called the "document proxy icon") will appear.

I think it's fine that they hid it, since even before, the things you can do with it (dragging, cmd/ctrl-clicking) were already hidden.

The only old functionality that is lost with Big Sur is that you could glance at the icon to see if there are unsaved changes (if so, the icon would be dimmed). But you can still tell by looking for the dot in the red close button.

WWDC21 5 years ago

I think that if you get downvoted, it might be because it's not related to the parent comment (which is only talking about the unicode angle). You should make this a top-level comment!

That's true, and because of that reason I am wondering whether it's possible to make people pay for having their issues addressed rather than resolved. The triaging/addressing process is where many people feel like open-source work is thankless, and throwing money in the mix can help make it feel more fair.

Maybe people will be willing to pay if the cost was lower? Maybe when you file a ticket, you can include a $10 fee to make sure it gets 10 minutes of the developer's time. (Or maybe you can attach $10 to any ticket, not just yours.)

To reduce the kinds of disputes that come up, there would be no guaranteed result other than that the developer spends 10 minutes doing their best to address the ticket and that they leave a reply. If people feel like the devs are just wasting their 10 minutes, they can simply not pay next time.

Actually, the more I think about it, the more I think this is a good idea, even just for the sake of optics: simply having the "paid ticket" there, even if no one uses it, might make people more thankful of the non-paid tickets the devs are addressing. And it offers a great retort/actionable step for those who complain that tickets aren't being addressed.

I love reading older material like this for two reasons:

(1) Since people were less familiar with computers back then, the way that things (like the cursor and drag-and-drop) are explained in this guides tends to be more explicit. Being re-introduced to concepts we take for granted is refreshing and helps with coming up with new concepts rather than just being confined to what we already see around us.

(2) Seeing what advice still applies decades later is a great way to figure out which pieces of advice are timeless and universal.

You could require a login after someone has added at least 5 objects and/or spent at least 5 minutes making edits. This makes sure that if data is lost, it's nothing that can't be easily recreated.

After at least 30 seconds of activity, you can display a prominent banner at the top of the page that says "make a free account to ensure your work is saved". Then it's clear that your ability to retrieve their data upon their next visit is a favor and not something they're obligated to. It's not exactly the same, but you can look at CoderPad's sandbox notice as inspiration for how to word this: https://app.coderpad.io/launch-sandbox (Note: you'll only be able to make one sandbox per cookie, so visit this in incognito mode)

To address scaling, you can probably limit the total number of "logged-out users" who are currently editing. If more users visit the site during the same time period, require them to make an account, just like you are now. If you're worried about users expecting a playground and getting confused, you can look at Google Docs's "This is getting a lot of traffic, you're in read only mode" notice that appears when more than 50 people are visiting a doc as an example of how explain the situation in an easily understandable way.

Now that you've properly set user expectations, you can clean house whenever and it should be okay.

btw, I just tried out this tool and I think it's awesome for a lot of the reasons mentioned in the top replies. Hope some of this is helpful + wishing you best of luck!