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

As I understand it, "to be trespassed" is a term of art that basically means "the cops were called, told that person was trespassing, the cops duly informed that person they are trespassing & had to leave the property, and the person left, but was not charged". It's basically establishing a legal trail so that if the person refuses to leave or continues to trespass at that location in the future they have a better basis for charging them.

I also use pass. Any forge you feel like is fine (I use gitlab). I backup my gpg key with `gpg —export-owner-trust` and store that backup elsewhere.

Pass has a pretty good ecosystem of plugins/other clients, as well. There are open source iOS/Android clients and browser extensions so once you’re setup the day-to-day experience is not far off from any of the popular hosted password managers.

My only real issue is the dependency on gpg, as it’s pretty long in the tooth and a hassle to operate. (If you are not comfortable using gpg, spend some time learning that before you go all-in on pass!) There’s a fork[1] which swaps gpg for age, but it hasn’t attracted enough attention to get a similar ecosystem of mobile clients/browser extensions, so it’s not a very practical choice IMHO.

[1]: https://github.com/FiloSottile/passage


It's next-to-impossible to implement pass on every device everywhere and have all the same features on each client without reimplementing all of GnuPG. It pushes a lot on to GnuPG.

God help you if you want to use the PGP applet on a Yubikey or smartcard. The pieces all exist, but wiring them all up in a mobile app is hard and the result is janky.


I don't think Age will catch on as a replacement until it has a gpg-agent equivalent to facilitate access.

Not a blowout?


I just quoted two jokes! You cannot in any reasonably way infer I missed anything. Maybe I just do that!


Stores, no, but there are meetups of keyboard nerds where people bring a bunch of them. There’s one in NYC run by a former coworker of mine: https://nyckeyboardmeetup.com/. Schedule is somewhat sporadic, and unfortunately you just missed the most recent one, but you might enjoy checking out their next event.


I'm with you, but I do think the situation can be characterized differently in a couple important ways:

1. IE was the default browser for many users (i.e. anybody using Windows who didn't know better).

2. IE had a lot of bugs and and was often non-compliant with standards.

Those two things combined meant that supporting IE required additional work, and if you didn't put in that work you were going to get users from IE anyway they'd just get frustrated and confused when things broke. So "detect IE and tell them use something else" was at least a reasonable fixed-cost approach to not having users get totally stuck. (And IE went down to 2-3% at least in part because devs revolted against IE earlier and started serving those "don't use IE" messages when its usage was still higher.)

Neither factor is really true of FF. It's not the default for any major platform, its user-base at this point is largely power users who won't be easily confused, and outside of some non-standard APIs most sites don't need and some fairly edge-casey stuff, most sites that work on Chrome will work fine on FF as well without alteration. If anything, IME Safari is more likely to need special attention than FF (but of course Safari has much higher market share so it merits that effort).

So I totally get not wanting to spend QA budget on FF, and I could understand showing a small banner suggesting you use a different browser, but erroring/completely blocking usage of the site does feel excessive to me, and even a bit mean-spirited since it takes extra effort to detect FF to show the message and prevent using the site! I don't think these sites are going out of their way to block usage of other low-usage browsers (some of which can alter behavior that could break some sites even if they are Chromium-based).


You left out the important and main reason, support for ie wasn't dropped - support for IE6 was dropped. At a point in time when it was already long since deprecated by it's maintainer, Microsoft


There is also a JS pkg with similar behavior: https://github.com/mattdiamond/fuckitjs


For folks who have never seen it, these are the referenced Top Gear segments:

- part 1: https://youtu.be/xnWKz7Cthkk

- part 2: https://youtu.be/xnWKz7Cthkk

- part 3: https://youtu.be/kFnVZXQD5_k


Second link is wrong (links to part 1 again). Corrected: https://youtu.be/xTPnIpjodA8


Remarkable how by the end of the third video it really starts to resemble the Cybertruck.


You should watch the Hammerhead Eagle i-Thrust episode.


We’re in very nitpicky terminology weeds here (and I’m not the person you’re replying to), but my understanding is “commutative” is specifically about reordering operands of one binary op (4+3 == 3+4), while “associative” is about reordering a longer chain of the same operation (1+2+3 == 1+3+2).

Edit: Wikipedia actually says associativity is definitionally about changing parens[0]. Mostly amounts to the same thing for standard arithmetic operators, but it’s an interesting distinction.

[0]: https://en.wikipedia.org/wiki/Associative_property


It is not a nit it is fundamental, a•b•c is associativity, specifically operator associativity.

Rounding and eventual underflow in IEEE means an expression X•Y for any algebraic operation • produces, if finite, a result (X•Y)·( 1 + ß ) + µ where |µ| cannot exceed half the smallest gap between numbers in the destination’s format, and |ß| < 2^-N , and ß·µ = 0 . ( µ ≠ 0 only when Underflow occurs.)

And yes that is a binary relation only

a•b•c is really (a•b)•c assuming left operator associativity, one of the properties that IEEE doesn't have.


If a therapist helped 99/100 patients but tacitly encouraged the 100th to commit suicide* they would still lose their license.

* ignoring the case of ethical assisted suicide for reasons of terminal illness and such, which doesn’t seem relevant to the case discussed here.


What kind of mobile functionality were you looking for? The (unofficial) iOS app is pretty good IMHO and integrates with iOS’s OS-level password filling, and also supports the pass-otp plugin’s format for 2fa codes if you use that plugin. There was a decent Android client I used a while back as well, though I don’t recall the name.

[1]: https://apps.apple.com/us/app/pass-password-store/id12058205...


Not the parent, but dwindling yubikey support (for gpg key storage) is an issue, had to pull out a legacy version on Android for it to keep working (they changed the underlying crypto library and lost the support there)

No ipad version I've found supports yubikey either


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

Search: