Hacker News new | past | comments | ask | show | jobs | submit | minus7's comments login

Hey,

I found your library a few weeks ago when I was annoyed by nothing like this being built into the standard library. It’s been a breeze to use so far.

A neat trick I found to gauge bottlenecks in pipelines is using Buffers between steps and running a goroutine that periodically prints `len(buffered)/cap(buffered)`


Thank you very much for the feedback. I thought about something similar some time ago. Buffer of size one, then measure the average time each item spends in the buffer. But for debugging your approach is simpler and more practical.


Used to vendor for a bit, but it's messy in git. If anything disappears, it should still be easy enough to recover it from somewhere.


Unfortunately that feature of invidious also seems to depend on the upstream RSS URLs and the feeds are just empty at the moment


The DNS records for that domain are hijacked on two German ISPs' resolvers I tested, yikes. Google and Cloudflare resolvers resolve it just fine however.

  canna.to.  0 IN CNAME notice.cuii.info.
  notice.cuii.info. 34953 IN A 167.233.14.14


`<div />` getting parsed as opening tag instead of self closing is a bug (be it in the browser or in the spec) and should be fixed


It's been fixed. Send Content-Type: application/xhtml+xml and it will be parsed as an empty tag. But nobody brothers to turn that on. Without an opt-in it's unfixable due to backward compatibility.


Why would it be a bug in the spec? “/“ is just a parsing error in html and is ignored.


IIRC there were issues with IPv6 on the hardware, which will be replaced once services move to Europe, and IPv6 will be available.


Best thing about it is that it has support for huge files; I was looking for a hex editor that can do that


I also installed fiber a while ago after being told "this isn't hard" by Michael Stapelberg's post [1]. Luckily I managed to get by with patch cables; a 30m cables really goes a long way! I even managed to get a duplex LC through a 16mm conduit with a pretty tight 90° bend, but just with lube, quite some force and luck.

I can just recommend going for it if you're curious. Cables and tranceivers really aren't expensive from fs.com (though their sales people may start bothering you).

Edit: And old, used network cards from ebay, of course.

[1]: https://michael.stapelberg.ch/posts/2020-08-09-fiber-link-ho...


Kudos for pulling those through these small conduits :)

For anyone trying to emulate this: I would very much NOT recommend using 16mm conduits for LC duplex patch cables. It's doable for some short/straight runs, but the connectors like to get stuck in bends. For me it was the final r=3cm bend in a ~20m conduit. I ended up pulling Cat7 into that conduit and routed the fiber through a tree-like network of wider backup conduits.

Since the backup conduit ends up in the wrong corner of the room, I might one day 1. cut the 30m fiber patch cable, 2. pull it into the original 16mm conduit (w/o connectors), replacing the Cat7 and 3. splice the fiber again. Using a "mechanical splice" that should be doable quite cheaply, but I didn't yet get around to learning/practicing that.


You can also use a pre-polished connector instead of splicing

e.g.: https://www.fs.com/de-en/products/35165.html (there's instructions if you scroll down)


Good joke, there are no $35 pis


I made this telegram bot[1] a while back that uses rpilocator.com and will notify you as soon as one is available from an official reseller. Those resellers should be selling them at the regular price. But yes, if you want to buy one right now, it won't be $35.

[1] https://github.com/sschueller/rpilocatorbot


Meh. It’s (supposedly) a transient situation that’ll resolve in due time.

More importantly, I and many geeks I know but/bought several when a new model first comes out because they are (were) cheap but electronics wholesalers don’t offer free shipping so it makes sense to buy as many as you think you’ll use (until the next one comes out) in one go to minimize the amortized cost.

I miscalculated and ended up using all of mine, but I have friends that still have some of their stock.


>TOTP is almost purpose made to be phished.

Well, that's a tad hyperbolic. While TOTP codes have no protection against phishing, an attacker still requires interaction from the account owner every time they want to make use of it and can't use the compromised account without the owner being able to notice it. Granted, someone getting phished might not notice. Still better than nothing (but not better than a password manager checking which site it's filling the login into)


This is not always true either. If you have limited control over the timestamp fed to a TOTP app you can capture codes that will be valid at any time of your choosing in the future. TOTP codes are just a magic hash of a secret and a timestamp.

Also the TOTP seeds are not stored in secure enclaves on phones but rather in plain text. Secure enclaves on phones do not have native TOTP support. Any application sandbox vulnerability on the TOTP seed containing device can give an attacker the ability to generate unlimited codes. Google Authenticator stores the secrets in an SQLite file.

It gets even worse when you consider TOTP secrets must /also/ be stored in plain text server side, normally sitting in a SQL database to be silently dumped through a pile of backend vulnerabilities most companies do not patch allowing bulk 2FA bypass.

TOTP is a fundamentally broken design that is negligent for any organization to support at this point alongside SMS. Everyone has one or more WebAuthn capable devices now regardless of if they realize it or not.

Today the right call for 2FA is to implement WebAuthn with the verification happening in a Confidential VM, HSM, Nitro Enclave or similar. Support only this.


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

Search: