HN user

ZeroConcerns

701 karma
Posts0
Comments160
View on HN
No posts found.

Not really -- any secrets stored using this method should also live in a password manager somewhere. It's about providing more-secure programmatic access to secrets.

Basically, it rebuilds Windows DPAPI from first principles, which is fine (I've done it many times myself!), and something non-Windows platforms sorely need. It changes the impact of malware from "they dumped all our secrets from prod to their C2" to "they got some encrypted values, and now someone will need to figure out our methodology and underlying keys", which is a meaningfully higher bar.

it's probably worth avoiding the resampling of 44.1 to 48 kHz

Ehhm, yeah, duh? You don't resample unless there is a clear need, and even then you don't upsample and only downsample, and you tell anyone that tries to convince you otherwise to go away and find the original (analog) source, so you can do a proper transfer.

Depends on the type of cable assembly. If it's fiber strands inside a soft-ish plastic jacket (and most of the cable is in fact in conduit), a service loop is fine, albeit a bit pointless for most repair scenarios. For armored cables (which are significantly stiffer), you only do these loops in situations where you expect to need to replace significant sections (think 'getting hit by a falling tree' or 'particularly aggressive rodents') and you have the space.

Good conduit and patch panel design is definitely key for a happy life. Leaving some extra space/capacity initially is also a good idea, especially since (unless you're covering truly great distances) there's not exactly a lot of innovation in the single mode fibre space: strands you put in today (even if it's 'the cheapest stuff your vendor sells most of', which is generally my philosophy for selecting cables) will still be viable a few years down the road.

Sharing/in-place-repurposing conduit is not something I'd recommend, but if you must, leave a few dummy cables (a.k.a. 'pieces of string') on the initial install...

Those 10 loops definitely only apply to the single mode fibre itself, not the entire assembly with armor and everything, because that's just... physically impossible.

Cables for direct burial only like to be bent once or twice, and then only gently. Anything else may very well break the armor (whether plastic or metal), after which all bets are off.

Still, for the outer jacket to become brittle to the extent described, something else is required, which may very well turn out to be "shoddy manufacturing"...

There's no link to the data sheet of the actual cable, but, yeah, looks like this should not have happened in such a short timeframe unless there's something really funny going on in that room, like ambient temperatures above 50 degC.

Another thing that should not have happened is installing the cable in loops in this way: any 'building' or 'underground' type cable needs to be of the exact length required at the demarcation point, fastened properly to prevent movement and terminated on a proper patch panel (can be a one-port box-type thingy for small setups), from where you use regular patch cords to connect your equipment.

(Loops are definitely allowed though, but that use case is mostly for aerial fiber to enable repair splices, and there are some very specific bend-radius and strain relief requirements, which, again should be spelled out in the cable data sheet)

Can this be fixed?

For popular senders: sort-of: in your incoming mail server, substring-match the display name of the sender against popular brands, and ensure the actual domain matches.

This works remarkably well for proper brands (FedEx et al), but breaks down when the brand name regularly occurs in "normal" names, the sending brand sends mail from all over the place, or "innocuous" impersonation takes place all the time.

Like, somehow, From: "VODAFONE" <shipping-update@dpd.co.uk> is a 100% legit sender (assuming SPF and DKIM verification pass), despite both Vodafone and DPD being pretty common impersonation targets. You'd think they'd know better, but alas.

So, yeah, room for improvement and such...

Well, I can travel around most of Europe without a passport right now? ID card will do just fine, even though, really, nobody ever asks me for that either.

Meanwhile, my life expectancy is, like at least twice that 'prior to WW1' and my disposable income at least 20 times my take-home pay in 1917.

Bloody EU, innit...

You'd be surprised at how cheap, relatively safe and reliable bus services are in those regions.

Source: me and my wife traveled extensively by public transport in, well, at least Pakistan. The other countries are indeed sort-of hairy, but mostly for job-clearance-related reasons.

Well, these days you can catch a Flixbus from London to Sofia for a mere 150 Europounds, and 48 hours of your time. And from there, Calcutta can't be that far, right?

(But, seriously, you can probably do it in another 48 hours...)

If you want (and only want) a pre-built site

No, I want to be able to @import "tailwindcss" without feeling guilty.

I've rarely found that any template site

Well, meet https://basecoatui.com -- and there's more where that came from.

So, ehhm, no, I'm not ignoring the salient part of your comment: you are ignoring the entire point of my post, which is that if Tailwind had a non-React monetization strategy, things maybe, possibly, might have worked out better.

So, ehhm, yeah, I sort-of question the data in this article. A US$5.50 burrito in Downtown SF in 2014? Nah... even Taco Bell takeout was already more expensive than that at the time.

Also: sure, some places overdo it on the pricing: I distinctly remember walking out of a Rotterdam (somewhere in The Netherlands) establishment due to them charging 25 Euros for a lunch sandwich, like 2 decades ago, despite this not being a fancy place at all. No inflation in sight, just greed and/or an inability to read the target audience...

Well, locals called it propane, but I didn't exactly "send it to trace for analysis."

Generally, you (and your toolbox) only spent a few minutes out of every working hour outside. And your toolbox would definitely be room-temperature initially and not cool down to anywhere near ambient temperature while out.

Interesting choice of tourism destination, but quite cool (no pun intended...) regardless.

One of the most annoying things about working with anything metal at those temperatures, is that your tools will pretty much instantly become stuck to whatever it is you're trying to manipulate, making a propane burner an indispensable addition to your toolbox.

That's not media manipulation (social or otherwise). Even if you don't subscribe to the "if it bleeds, it leads" mantra (first commonly used in... the 1890s!), it's not that hard to understand why reporting on uncommon events is more popular than repeating the same baseline truths every day?

So, yeah, I guess there's much confusion about what a 'managed database' actually is? Because for me, the table stakes are:

-Backups: the provider will push a full generic disaster-recovery backup of my database to an off-provider location at least daily, without the need for a maintenance window

-Optimization: index maintenance and storage optimization are performed automatically and transparently

-Multi-datacenter failover: my database will remain available even if part(s) of my provider are down, with a minimal data loss window (like, 30 seconds, 5 minutes, 15 minutes, depending on SLA and thus plan expenditure)

-Point-in-time backups are performed at an SLA-defined granularity and with a similar retention window, allowing me to access snapshots via a custom DSN, not affecting production access or performance in any way

-Slow-query analysis: notifying me of relevant performance bottlenecks before they bring down production

-Storage analysis: my plan allows for #GB of fast storage, #TB of slow storage: let me know when I'm forecast to run out of either in the next 3 billing cycles or so

Because, well, if anyone provides all of that for a monthly fee, the whole "self-hosting" argument goes out of the window quickly, right? And I say that as someone who absolutely adores self-hosting...

And yet, not much has changed in that decade, right? Well, other than the Steam Deck, which is a well-defined set of hardware for a specific purpose, and which is the main driver for Linux game compatibility...

And that's great! But for a random owner of random hardware. the experience is, well... same as it ever was?