sugar_in_your_tea

joined 2 years ago
MODERATOR OF
[–] sugar_in_your_tea@sh.itjust.works 1 points 10 hours ago (1 children)

Yes, it's not the same since you get a stacktrace (if enabled) and a message, but it's the closest thing you get in safe rust (outside compiler bugs). I compare it to a segfault because it's almost as unhandleble.

Basically, you don't want a panic to crash your program in most cases. If you do, make it explicit (i.e. with expect()). unwrap() tells me the value is absolutely there or the dev is lazy, and I always assume the latter unless there's an explanation (or it's obvious from context) otherwise.

Nah, if there's one thing they thoroughly test, it's the spying.

[–] sugar_in_your_tea@sh.itjust.works 1 points 23 hours ago* (last edited 23 hours ago) (3 children)

No, it's a panic, so it's more similar to a segfault, but with some amount of unwinding. It can be "caught" but only at a thread boundary.

It is unwrap's fault. If they did it properly, they would've had to explicitly deal with the problem, which could clarify exactly what the problem is. In this case, I'd probably use expect() to add context. Also, when doing anything with strict size requirements, I would also explicitly check the size to make sure it'll fit, again, for better error reporting.

Proper error reporting could've made this a 5-min investigation.

Also, the problem in the first place should've been caught with unit tests and a test deploy. Our process here is:

  1. Any significant change to queries is tested with a copy of production data
  2. All changes are tested in a staging environment similar to production
  3. All hotfixes are tested with a copy of production data

And we're not a massive software shop, we have a few dozen devs in a company of thousands of people. If I worked at Cloudflare, I'd have more rigorous standards given the global impact of a bug (we have a few hundred users, not billions like Cloudflare).

Ift is precious and beyond compare. It has tools that most other languages lack to prove certain classes of bugs are impossible.

You can still introduce bugs, especially when you use certain features that "standard" linter (clippy) catches by default and no team would silence globally. .unwrap() is very controversial in Rust and should never be used without clear justification in production code. Even in my pet projects, it's the first thing I clear out once basic functionality is there.

This issue should've been caught at three separate stages:

  1. git pre-commit or pre-push should run the linter on the devs machine
  2. Static analysis checks should catch this both before getting reviews and when deploying the change
  3. Human code review

The fact that it made it past all three makes me very concerned about how they do development over there. We're a much smaller company and we're not even a software company (software dev is <1% of the total company), and we do this. We don't even use Rust, we're a Python shop, yet we have robust static analysis for every change. It's standard, and any company doing anything more than a small in-house tool used by 3 people should have these standards in place.

Man, my friends riffed on that song so much.

It's Steam Deck verified, no need to check ProtonDB.

[–] sugar_in_your_tea@sh.itjust.works 1 points 1 day ago (1 children)

Yeah, TP is renewable by design, since it comes from trees. Being from a grass like bamboo doesn't change that, and bamboo isn't absorbent, so I'm very concerned about the process they're using to produce something that's supposed to be somewhat absorbent.

I wanna know how many square cubits it is.

 

We're behind on our Python release updates, so I was reviewing older Python releases and found this gem at the bottom of the 3.12 notes:

They have no need of our help

So do not tell me

These haggard faces could belong to you or me

Should life have dealt a different hand

We need to see them for who they really are

Chancers and scroungers

Layabouts and loungers

With bombs up their sleeves

Cut-throats and thieves

They are not

Welcome here

We should make them

Go back to where they came from

They cannot

Share our food

Share our homes

Share our countries

Instead let us

Build a wall to keep them out

It is not okay to say

These are people just like us

A place should only belong to those who are born there

Do not be so stupid to think that

The world can be looked at another way

(now read from bottom to top)

Refugees, by Brian Bilston

[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago (1 children)

Use something like Backblaze or Hetzner storage boxes for off-site backups. There are a number of tools for making this painless, so pick your favorite. If you have the means, I recommend doing a disaster recovery scenario every so often (i.e. disconnect existing drives, reinstall the OS, and load everything from remote backup).

Generally speaking, follow the 3-2-1 rule:

  • 3 copies of everything on
  • 2 different types of media with
  • 1 copy off site (at least)

For your situation, this could be:

  • 3 copies - your computer (NVMe?), TrueNas (HDD?), off-site backup; ideally have a third local device (second computer?)
  • 2 media - NVMe and HDD
  • 1 copy off site - Backblaze, Hetzner, etc

You could rent a cloud server, but it'll be a lot more expensive vs just renting storage.

[–] sugar_in_your_tea@sh.itjust.works 2 points 1 day ago* (last edited 1 day ago) (1 children)

Glad you got it fixed. 🙂

Almost every reply is also explaining what the runtime is.

I boosted it up a bit for other people who come along w/ a similar concern. You seemed mistaken at first until a few threads deep, so there's likely someone else who is just as, if not more, confused.

22
openSUSE Leap 16 Enters Beta (news.opensuse.org)
submitted 6 months ago* (last edited 2 months ago) by sugar_in_your_tea@sh.itjust.works to c/opensuse@lemmy.world
 

I didn't notice this until the other post about them potentially deprecating YaST (at least putting in on maintenance mode). I figured we could use a thread to discuss other changes coming in Leap 16.

 

Current setup:

  • one giant docker compose file
  • Caddy TLS trunking
  • only exposed port is Caddy

I've been trying out podman, and I got a new service running (seafile), and I did it via podman generate kube so I can run it w/ podman kube play. My understanding is that the "podman way" is to use quadlets, which means container, network, etc files managed by systemd, so I tried out podlet podman kube play to generate a systemd-compatible file, but it just spat out a .kube file.

Since I'm just starting out, it wouldn't be a ton of work to convert to separate unit files, or I can continue with the .kube file way. I'm just not sure which to do.

At the end of this process, here's what I'd like in the end:

  • Caddy is the only exposed port - could block w/ firewall, but it would be nice if they worked over a hidden network
  • each service works as its own unit, so I can reuse ports and whatnot - I may move services across devices eventually, and I'd rather not have to remember custom ports and instead use host names
  • automatically update images - shouldn't change the tag, just grab the latest from that tag

Is there a good reason to prefer .kube over .container et al or vice versa? Which is the "preferred" way to do this? Both are documented on the same "quadlet" doc page, which just describes the acceptable formats. I don't think I want kubernetes anytime soon, so the only reason I went that way is because it looked similar to compose.yml and I saw a guide for it, but I'm willing to put in some work to port from that if needed (and the docs for the kube yaml file kinda sucks). I just want a way to ship around a few files so moving a service to a new device is easy. I'll only really have like 3-4 devices (NAS, VPS, and maybe an RPi or two), and I currently only have one (NAS).

Also, is there a customary place to stick stuff like config files? I'm currently using my user's home directory, but that's not great long-term. I'll rarely need to touch these, so I guess I could stick them on my NAS mount (currently /srv/nas/) next to the data (/srv/nas//). But if there's a standard place to stick this, I'd prefer to do that.

Anyway, just looking for an opinionated workflow to follow here. I could keep going with the kube yaml file route, or I could switch to the .container route, I don't mind either way since I'm still early in the process. I'm currently thinking of porting to the .container method to try it out, but I don't know if that's the "right" way or if ".kube` with a yaml config is the "right" way.

 

Apparently US bandwidth was reduced to 1TB for their base plan, though they have 20TB for the same plan in Europe. I don't use much bandwidth right now, but I could need more in the future depending on how I do backups and whatnot.

So I'm shopping around in case I need to make a switch. Here's what I use it for:

  • VPN to get around CGNAT - so all traffic for my internal services goes through it
  • HAProxy - forwards traffic to my various services
  • small test servers - very low requirements, basically just STUN servers
  • low traffic blog

Hard requirements:

  • custom ISO, or at least openSUSE support
  • inexpensive - shooting for ~$5/month, I don't need much
  • decent bandwidth (bare minimum 50mbps, ideally 1gbps+), with high-ish caps - I won't use much data most of the time (handful of GB), but occasionally might use 2-5TB

Nice to have:

  • unmetered/generous bandwidth - would like to run a Tor relay
  • inexpensive storage - need to put my offsite backups somewhere
  • API - I'm a nerd and like automating things :)
  • location near me - I'm in the US, so anywhere in NA works

Not needed:

  • fast processors
  • lots of RAM
  • loose policies around torrenting and processing (no crypto or piracy here)
  • support features, recipes, etc - I can figure stuff out on my own

I'll probably stick with Hetzner for now because:

  • pricing is still fair (transfer is in line with competitors)
  • can probably move my server to Germany w/o major issues for more bandwidth
  • they hit all of the other requirements, nice to haves, and many unneeded features

Anyway, thoughts? The bandwidth change pisses me off, so let me know if there's a better alternative.

 

I know Mitt Romney is part of the two-party system, but he also stood up against his party by voting for Trump's impeachment and not once endorsing Trump for President.

This is his closing speech since he's retiring, and I think the message is worth listening to, especially since it seems to be an end of a moderate era for the GOP.

Anyway, perhaps this can open a discussion about the value of centrist politicians. Or whatever other thoughts you may have.

 

I thought this was an interesting video and I think it does a good job explaining at least part of why Trump won. Here's the original paper if you're interested.

I think the economy was a major factor in deciding this election, but obviously there are a lot of other factors to consider, such as the DNC not having a primary, Biden having a poor approval rating, and concerns around China and Russia, among a host of others. However, this seems to do a fantastic job explaining the results as well.

What do you think? Do you think public perception of the economy and political party influence on the economy was a significant factor in this election? Do you think that indicates a decent likelihood of either an economic correction or at least reduced returns at some point in Trump's presidency?

 

With Thanksgiving in the US right around the corner, I found this article about gratitude from a FI perspective. This is from a few years ago, but the message is evergreen.

 

Link is to the Bogleheads forum post where someone posted a link back in August. Before now, you had to call in to request the change, and it could take a few days, but now it's online and allegedly is done the next day.

I don't know when they added this, but I think it was sometime this year because I remember considering it last EOY (that's when I usually rebalance).

Here is a direct link, or you can get there on the website: Transact > Buy & Sell > Convert Vanguard mutual funds to ETFs. You can select either a number of shares or a percent of the total position.

As to why you may want to do this, here are a few reasons:

  • converting shares classes isn't a taxable event (but you can't go ETF -> mutual fund)
  • ETFs have a slighly lower ER (0.01-0.02% in most cases, so not huge)
  • easier if you want to ACATS transfer shares to a different brokerage
  • if you have a mix of ETFs and mutual funds, rebalancing between ETFs is easier, so moving a portion of your mutual funds to ETFs may be worthwhile

Have you taken advantage of Vanguard's mutual fund -> ETF conversion? Do you think you'll use this new online tool?

 

Link is to an older podcast episode, and The Money Guy YouTube channel occasionally talks about FINE instead of FIRE.

Here's the definitions of each:

  • FINE - Financial Independence Next Endeavor
  • FIRE - Financial Independence Retire Early

Basically, FINE focuses on what you plan to do after achieving financial independence, whereas FIRE tends to focus on cessation of working. I always called it FI (leave off the retirement part), but I suppose FINE works.

Anyway, just wondering what everyone else is planning to do once they hit Financial Independence, whether that's retirement or starting something new. I'll leave mine in the comments.

 

This is a link to a spreadsheet to help determine which funds to place into taxable vs tax-advantaged space.

Here is a link to the Bogleheads wiki about tax-efficient fund placement:

If all else is equal, international funds have a small tax advantage over US funds, because they are eligible for the foreign tax credit.

TL;DR:

  • put international funds in taxable and file for the foreign tax credit each year
  • the total difference is like 0.1-0.2%, so optimizing fees may be more impactful than going through this exercise

This wasn't good enough for me, especially as I'm looking into applying a small-cap tilt to my portfolio and really like optimizing things, so I went digging for more information.

Foreign Tax Credit

When you own stocks or otherwise make money in another country, that other country may charge taxes, and the IRS will also charge taxes on any dividends you receive, regardless of source. This ends up in double taxation, because you're being taxed on your dividends by both the US and the foreign country.

To eliminate the double taxation, you can file form 1116 to recoup the foreign taxes by getting a credit (or deduction, but that's rarely better). This Bogleheads wiki doc has more information if you want it.

For many funds (e.g. VXUS), the FTC ends up being something like 0.25%, so if it's in a tax-advantaged account, you'd end up with a 0.25% tax drag on your investments due to foreign taxes you can't recoup.

Tax-efficiency

When deciding where to place funds, you generally want fewer dividends and capital gains in your taxable brokerage accounts and to put the higher dividend-yielding assets in your tax-advantaged accounts. And if you have to have capital gains, you want to make sure your taxable account has mostly qualified capital gains so they're taxed at the long-term capital gains rate instead of the (in most cases) higher income tax rate.

However, the foreign tax credit changes things, since you can only get it if your investments are in a taxable brokerage account. There are cases where you'd prefer a higher total dividend in your taxable account provided the tax credit more than makes up for the difference in total taxes.

Worked example w/ VTI and VXUS

For example, let's say you have equivalent amounts of VXUS and VTI. VXUS has 3.34% total dividend yield whereas VTI has 1.66% (both as-of 2021). So you'd want VXUS in tax advantaged and VTI in taxable, right? Wrong. The total taxes for both are:

  • VXUS - 0.56%, of which 0.26% is recoverable foreign taxes, for a net of 0.30%
  • VTI - 0.32%

Here are two scenarios (assuming you have no state income tax, are in the 22% bracket w/ 15% LTCG):

  • VTI in taxable - VXUS pays 0.26% in foreign taxes, for a total tax bill of 0.26% (0.26% + 0.26) / 2
  • VXUS in taxable - 0.30% net taxes (0.56% - 0.26%), for a total tax bill of 0.15% (0.30% / 2)

So in this case, holding VXUS in taxable saves about 0.11% in total taxes paid.

Added notes

I added some Avantis funds (known for value funds) on here that are interesting:

  • AVUV - US small-cap value fund
  • AVDV - developed markets small-cap value fund
  • AVES - emerging markets value fund

So please, make a copy and mess around with your own figures. You can add some funds as well if you like, just fill in the bolded sections in the "funds" tab and it should work for you.

I'd appreciate a second pair of eyes as well if you feel so inclined.

Anyway, do you bother with adjust fund placement?

 

I generally don't like to make political posts, but this one has an interesting correlation to some of the culture around FI, which is things we can and can't control (i.e. this older post about circle of control, which echoes The Seven Habits of Highly Effective People).

So even if you're not in the US or just aren't interested anymore in the election (i.e. I already voted last week), there's still some interesting points about what the head of government can and can't do, as well as what the rest of government has and doesn't have control over.

Stocks are all over the place right now, and there's a lot of concern about what might happen after the results are announced. I hope this article can bring a little peace since a lot of what the market and news orgs are worried about aren't really things the President has direct control over, and the rest of government will have a delayed impact.

It's certainly an important decision and there will be significant impacts, but sometimes it helps to take a step back and look past the excitement in the news cycle.

view more: next ›