metaphor

Sigma Chi...unsurprising[1].

[1] https://en.wikipedia.org/wiki/Sigma_Chi#Controversies_and_me...

> Since there are really many companies and people using AWS, the effect would be noticeable if everyone managed such a decrease.

Your condition is predicated on "everyone" at Pinterest revenue scale justifying the business case of throwing away their existing tech stack and adopting Elixir with an equivalent architecture---never mind that the article is coming from a company that sells Elixir consulting services---while major CSPs voluntarily bend over to notionally substantial revenue decline...and I'm bordering on bad faith??

At least I bothered to put a supporting numerical estimate on the hypothetical; you're just handwaving greenwashed bullshit with improbable, unsupported outcomes.

An even less significant rounding error; on the order of ~0.002% relative to AWS carbon footprint at best using FY23 forward net sales as a rough proxy.

For context, $2MM ~= 0.3% of FY22 cost of revenue[1].

[1] https://www.sec.gov/Archives/edgar/data/1506293/000150629323...

The ones that have never let me down in the field are these[1]. Works well from the low drone of lab server racks to high squeals of running jet engines with double hearing protection.

[1] https://www.3m.com/3M/en_US/p/d/v000153443/

Sounds like a personal issue.

Tell you what, just keep it on that side of the Atlantic and continue buying our natural gas, and since we're so biased to a fault towards "we've always done it this way", we'll keep buying your most excellent products that conform to Reinheitsgebot.

Not all 3M earplugs are created equal. These[1][2][3], for example, are steaming piles of hot garbage. I carry a pair of 3M compact 21 dB NRR earmuffs because they're superior to these earplugs that are way too common in our production environment. The skull screws and corded variant are particularly egregious because they have a plastic stem embedded in the foam that can make insertion really uncomfortable and potentially hazardous if you slip or get smacked on the ear.

[1] https://www.3m.com/3M/en_US/p/d/v000153037/

[2] https://www.3m.com/3M/en_US/p/d/v000181515/

[3] https://www.3m.com/3M/en_US/p/d/b00037662/

> ...mixed numbers are decidedly inferior to decimals. They're not harder, strictly speaking, but are more tedious, and this additional tedium introduces steps that people can make mistakes in.

A counterpoint to this is the fact that there are close to a million employed carpenter tradesmen in the US whose average level of education is a high school diploma[1], and yet their trade operates almost exclusively on fractional arithmetic, most of which occurs mentally on the jobsite.

The point being that tedium is a relative measure of training and experience, and it goes without saying that those trained in only decimal form are liable to struggle with unfamiliar systems.

And if you think that's bad, try purchasing lumber from any lumber yard in Canada or the US; the trade's board-foot system[2] will really tickle your metric attachment.

> it is a waste of time and effort to use non-SI units and convert back and forth.

It seems the story is more like it's a waste of time to those who find value in what Americans have to say but are unaccustomed and insistently resistant to performing conversions. I don't disagree that there's certainly value in having a globally common measurement framework, and indeed an American who conveys imperial units in a European setting is liable to be chastised. But old habits die hard and last time I checked, we're not having this discussion on a .eu gTLD.

Now try imagining how the typical American feels when engaging with the rest of the world: SI units, (,) and (.) symbols reversed, left-lane driving, etc. We tend to just adapt.

[1] https://www.bls.gov/ooh/construction-and-extraction/carpente...

[2] https://en.wikipedia.org/wiki/Board_foot

> This is a terrible indictment of the American schooling system if your only defence against metrication is 'I can't do decimals'. It is you lot who have to catch up.

To the contrary, if you read into the full context of this thread, the underlying contention isn't that we're incompetent at decimal arithmetic, but that the rest of the world (and apparently some Americans too) believes our common fractional arithmetic is too much of a mental burden, and I don't blame those individuals either.

Indeed decimal arithmetic is trivial to most grown adults, but that wasn't the point; the example was merely to highlight how just slightly changing a few numbers in the same sequence of operations serves as an effective counterpoint to the grandparent's assertion that "even children can do in their head reliably".

Americans are taught and handle metric units in compulsory school just fine, but most of us also practice imperial units on a daily basis as well. We're just not culturally predisposed to complain when everyone else conveys measure in the SI mks/cgs framework.

The goalposts set by the grandparent was reliable mental arithmetic by a notional child:

> ...which probably even children can do in their head reliably.

You're moving the goalposts.

An indefinite number of applications exist where we can make meaningful decisions all day without ever needing to write results down.

Unsure with the 48g; trained myself since engineering undergrad days to not lean into graphing calculators. The feature existed since at least the 32sii, so it makes sense that successor 33s and 35s models also got it. Easily one of the most useful features that I've found for woodworking and converting arcmin/sec to decimal as the most common usecases.

The child would clearly have to mentally carry four times all the way down the chain:

    11 11
    14.446
  +  6.789
  --------
    21.235

I think what the parent means is a hat that's an indispensible article of formal dress. They certainly still have their place, but it's not like there's an expectation to see everyone in cowboy hats at a Texas wedding.

The only place I'm aware of where hat use as a matter of dress and appearance is still strictly adhered to is in the US military.

Now change that first number from 6.112 to 6.789 and watch that same child stumble.

I've always found it curious how Europeans pride themselves in speaking their native tongue + English...except its always a cultural flame war-inciting impediment when the communication barrier involves a mere arithmetic unit conversion. Doubly ironic when most of the world is consciously aware of what the prevailing USD exchange rate with their native currency is without complaint, whereas the average American simply doesn't have a clue how many Euros a US dollar gets them.

Similarly, if the Brits want to reference weight in stone, or Canadians want to sell me lumber in board-foot, I don't find that offensive in the least; I'm of the position that the impetus is on me to understand their measure, not for the one communicating to conform to my norms.

> It’s not trivial to add up 2’13/32” + 5’11/16”, there’s too much carrying over and doubling to equalize the denominators to do easily in your head.

Seems like straight forward arithmetic, but if using a calculator is a must, the HP 35s (RPN daily driver) handles fractional calculations elegantly without being a "very specific carpenters calculator":

  2.13.32 [Enter] 5.11.16 [+]

  8.09375

...and if you wanted that decimal as fractional display instead:

  [-->] [FDISP]

  8 3/32

What's to stop another maintainer from actively dismissing[1] your requested change and merging anyways, and how is this scenario materially different than the same maintainer consciously disrespecting my unresolved thread while overriding my required approval?

Even more adversarial, why not just exploit the implied race condition of your process by having a new PR submitted for another maintainer to merge before you get a chance to block it?

If we're still in fact talking about a scenario involving a group of maintainers with equal authority over a protected branch, all I see is the inescapably human dilemma of collaborative communication and network of trust.

But if one "maintainer" has the asymmetric capacity to immutably block all others, then the goalposts have moved and we're not really talking about just maintainers with equal pull.

On an opinionated note, if there's anything I learned about embracing Microsoft, it's that you can't judge true TCO by merely comparing superficial sticker prices.

[1] https://docs.github.com/en/pull-requests/collaborating-with-...

...but if a junior incorrectly marks a thread resolved, then the senior gets traceability and an indirect feedback signal that tells you someone isn't naturally tracking and there may be room for communication improvement.

In any case, setting unresolved threads as blocking is just a safeguard layer. The scenario you describe is a routine encounter for me. Really sounds like the technical control you want is required approval(s)...of course, GitLab sales recognized that's what enterprise managers also highly value, so it's bucketed as a pay-to-play Premium/Ultimate feature.

> With that setting there's no native way to distinguish between threads that are intended to be blockers and threads that are just comments. They all must be closed regardless of intention before merging can happen, and because there's no way for the commenter to signal their intent that process is error prone.

This may have merit if your default workflow mindset was all threads are non-blocking unless an explicit "request change" action is invoked.

GitLab's unresolved threads simply comes at it from the inverse perspective of all threads are blocking unless intent to move forward is explicitly conveyed by positively marking threads resolved. If the objective is to avoid unintended merges that manifest from inattentiveness and/or poor communication, then this is clearly the safer approach that preserves accountability.

In the case of just a comment, I see any friction created there as a direct result of poor communication between collaborators; if you can't unambiguously decide whether an in-thread comment is non-blocking/unactionable, then clarity of intent wasn't clearly conveyed to begin with.

Another thing that I thought was presumptive with this "requested changes" flag is that it signals that you want to see code change, but maybe your intent is to block a merge until the PR submitter is given an opportunity to more clearly defend an implementation decision, which may or may not result in a change.

Between draft marking, unresolved threads, and approval rules[1] to safeguard against unintended merges, I struggle to see how GitLab could possibly help me more.

There's a part of me that feels like differences in value perspective are driven by what's generally effective for open distributed collaborations v. the needs of closed enterprise teams.

[1] https://docs.gitlab.com/ee/user/project/merge_requests/appro...

Thanks for clarifying. That just looks like the functional equivalent of setting GitLab unresolved MR threads as blocking[1] though.

[1] https://docs.gitlab.com/ee/user/project/merge_requests/index...

> Gitea and Forgejo have this functionality [0].

I must be missing something...how is what you linked to relevant to the feature(s) that the parent is alluding to again? Surely you're not referring to Gitea WIP marking, which sounds functionally equivalent to GitLab Draft marking[1].

[1] https://docs.gitlab.com/ee/user/project/merge_requests/draft...

> The most obvious failure is linearly polarized light output.

That's not a failure of the display module per se, but a dealer handwaving "suitable substitute" without authority while failing to satisfy a performance requirement that's observable but not abundantly obvious.

In other words, third parties without privileged design knowledge tend to operate on a naive "it's a suitable substitute because it fits" paradigm, which is good enough in many cases, but the risk of a repair based on this model being met with dissatisfaction tends to increase with the character/complexity of a replaceable component and/or sub-assembly, which may not be independently discoverable or even documented.

As a trivial example, you may independently observe a simple 470-ohm 0805 SMT resistor in my design, and you could certainly purchase a quality replacement on the market that "fits"...but the unacknowledged risk in doing so is not knowing with certainty whether my design intent surrounding that component depends on other salient characteristics, e.g. composition, power rating, tempco, operating range, endurance, etc.

2012.

Title asserts "research suggests" yet neither cites nor mentions any actual research while quoting commentary from a social magazine article.

This is low quality fodder for gossip.

More precisely[1]:

  - all households, all ages
    - 1950 = 3.37
    - 2022 = 2.50
  - family households, all ages
    - 1950 = 3.54
    - 2022 = 3.13

[1] https://www2.census.gov/programs-surveys/demo/tables/familie...

> I don't know anywhere else one can get a risk free return equivalent to a 10y bond.

How about equivalent risk-free return, even better yield, upside potential, optionality...and you don't need to be a federal employee to play?

It's been hiding in plain sight[1][2] for over a year now, but I'm not a financial advisor and certainly not your financial advisor...just an interwebs rando with a hobby positing food for critical thought.

[1] https://fred.stlouisfed.org/graph/?g=17THg

[2] https://fred.stlouisfed.org/graph/?g=17THh

That's nice but entirely irrelevant.

If you were 100% allocated in TSP G Fund and Treasury yields spiked across the curve, your account balance never goes down and you could withdrawal the entire amount at any time without losing a single penny.

If you were 100% allocated in 10-yr T-notes and Treasury yields spiked across the curve, well...you'd be swallowing a substantial loss proportional to your unhedged duration exposure if you were either to liquidate your position before maturity or before yields normalize.

This[1] is what you don't understand.

[1] https://www.investopedia.com/terms/b/bond-yield.asp

> Most of my bonds were in the TSP G fund (zero risk, 10y treasury yields) with a little in short term bonds.

You're clearly confused. The TSP G Fund[1] is comprised of 100% nonmarketable short-term Treasuries specially issued to the TSP; 10-year T-notes don't exist in its composition whatsoever. and its nominal return over any arbitrary period has never been negative...in other words, bond duration risk simply isn't applicable to the fund. Furthermore:

>> The G Fund rate is calculated by the U.S. Treasury as the weighted average yield of approximately 183 U.S. Treasury securities on the last day of the previous month.

[1] https://www.tsp.gov/funds-individual/g-fund/

How'd you figure?

Looking at the S&P 500[1] over the past two years relative to today's close:

  Aug 15, 2023 Close = $4,437.86
  Aug 15, 2022 Close = $4,297.14
  Aug 13, 2021 Close = $4,468.00
         1-yr Return = +3.3%
         2-yr Return = -0.7%

...and using the latest CPI-U data[2] over roughly the same period:

      Jul 2023 Index = 305.691
      Jul 2022 Index = 296.276
      Jul 2021 Index = 273.003
      1-yr Inflation = +3.2%
      2-yr Inflation = +12.0%

...I get real returns of +0.1% and -12.7% over 1- and 2-yr periods, respectively.

Same exercise looking at Vanguard VTI ETF[3]:

  Aug 15, 2023 Close = $220.37
  Aug 15, 2022 Close = $215.78
  Aug 13, 2021 Close = $230.05
         1-yr Return = +2.1%
         2-yr Return = -4.2%

...I get real returns of -1.1% and -16.2% over 1- and 2-yr periods, respectively.

[1] https://fred.stlouisfed.org/series/SP500

[2] https://fred.stlouisfed.org/series/CPIAUCNS

[3] https://advisors.vanguard.com/investments/products/vti/vangu...

That's a hard sell for those who work in companies that prohibit dependencies on free 3rd-party web services to discuss business confidential ideas in an unsecure way.

Imagine the UX of 1 in 20 characters typed being incorrectly inferred though. The P_failure*Cost impact would strike me as insufferable even if error rate were to improve by an order of magnitude.