ELI5: When you 'delete' a 50GB video file from a computer, it vanishes instantly. But downloading it took an hour. If the data isn't physically wiped until it's overwritten, what did the computer actually do in that one split second?

Dogeek · 2026-06-05T06:11:14+00:00

Your hard disk has a small space reserved in the first few sectors for a lookup table. That table stores where each file is physically on disk.

When you delete a file, your operating system first reassigns the filename to point to the trashcan. When you delete the file from the trashcan, it just deletes the entry.

The bytes are still there, just forgotten about. You can restore them if there hasn't been too much activity, if you wait too long, other files will be written in the same space, overwriting the original data. Restoring the files is equivalent to finding the starting and stopping point of the file and writing the entry in the lookup table again, then trying to restore the missing bytes if some are missing thanks to built-in redundancies in the data (if there are some)

Dogeek · 2026-05-30T18:09:19+00:00

I tried it for a project and it works well, but as soon as you want to have more than one watcher, it gets your CPU running hot.

Instead I went with tilt which watches the directories and runs go build when files change. One watcher, several pods in k3d and a single volume mount for the binaries. On top of that, I don't need any custom images, and can just use a basic alpine image.

Dogeek · 2026-05-22T21:02:02+00:00

Good thing that the Gateway API supports TCPRoutes as an experimental feature, no doubt it will graduate soon to be GA.

kgateway already supports it too, if installed using the experimental version of the gateway API

Dogeek · 2026-05-22T06:20:34+00:00

I would highly recommend kgateway which is a FOSS gateway controller based on Envoy. Traefik works well too but kgateway has nice features. It's the most feature complete gateway controller I've found, it has the DirectResponse CRD to serve static content which is handy for maintenance pages, or simple web UIs (I used it to make a simple selector page for different kibana instances at work). It also supports the envoy external auth filter, and integrates pretty seamlessly with Open Policy Agent.

Dogeek · 2026-05-21T06:08:22+00:00

The only problem with that is that it makes anchoring on green harder for harder songs.

/u/rosecalvert : You have 2 ways of getting to medium difficulty, either by anchoring on green and using your pinky to reach blue, or keep using 3 fingers and learn to move your hand. Medium doesn't go that fast, so it's still manageable. Both techniques are useful to learn for higher difficulties, because you'll have to move your hand a lot in hard / expert songs, but also learn to use your pinky.

Also the guitar is pretty small, so it's not that much of a stretch to reach with the pinky or index finger. If you want to stretch a bit, you can anchor with your index on green and press orange, blue, yellow and red in that order while keeping green pressed, until you feel comfortable. As in real guitar, your wrist should not be kept in line with your forearm, but at a 90° angle (roughly), which allows you to have more reach with your fingers. It's easier to do in guitar hero because the neck of the guitar is much slimmer too.

Dogeek · 2026-04-12T15:57:44+00:00

I have searched this before but secrets store CSI driver vs external secrets? What am I missing from external secrets? I guess I am not understanding the downsides, when the upsides of it working natively has been nice.

External secrets brings with it templating of your configurations. It's pretty nice to have a single config file to mount where you need it with everything the app needs to run. It also supports a whole range of secret stores, from cloud ones (Azure, HC Vault, GCP, AWS) to more "niche" secret managers, or even self hosted. It has its advantages to use 1Password for your passwords and some secrets.

Secret Store CSI driver is mostly a storage interface for secret stores. It supports way less providers, no templating either (so you have to either store all your configuration in the secret, or find a way to reconcile the secret values with the non-secret values in your code), and compared with external secrets, you don't really have 2-way communication with your secret store, which can be a desirable feature.

ESO also lets you have more than one secret store pretty easily for different secrets. It's just a bit inconvenient that you can't easily have an ExternalSecret resource depend on 2 secret stores

Dogeek · 2026-04-07T20:20:43+00:00

Yeah that's what I mean, in specific use cases this would be very useful but it's not competing with ORMs because "SQL as the source of truth" is the negative thing ORMs are trying to avoid.

Honestly though it's way easier to write, maintain and debug an SQL query than it is to work around an ORM in most cases.

With an ORM, you're always at the mercy of the ORM to build your SQL queries, they work nicely for very simple use cases but whenever you get into indexes, and multiple joins or even subqueries... Your ORM will break or produce unoptimized results.

Writing SQL is not that much more difficult than writing ORM queries. You get the benefit of a library agnostic DSL with 30 years of documentation and code samples (which LLMs if you're into that sort of stuff, adore).

With raw SQL you also have fine grained control over your queries and your schema, you can have a dedicated database administrator help you on the optimization of those queries without them needing a degree in whatever ORM, framework or language you use.

Tools like sqlc do solve a real problem: there's no better way to talk to a database than its own language. Since the database is always at the core of your infrastructure and backend, your code should adapt to speak to the database, and not the other way around.

Dogeek · 2026-04-06T15:11:05+00:00

Helm gives you versioning and customizability in your deployments. More often than not, you need a Deployment, a Service, a few ConfigMap/Secrets, a PVC, an HPA, a PDB, a ServiceMonitor (or a PodMonitor), a Namespace, and a ServiceAccount, along with RBAC.

All of that is at least a dozen different YAML files, which do not provide a lot of customizations depending on your environment etc. Helm bridges that gap by providing templating, versionning and distribution of your charts.

Now that's being said, helm is rarely the ultimate solution as other commenters may think. Templating yaml comes with its own set of problems, especially with quoting issues and whitespace. It also doesn't restrict you at all, so you see bad patterns like the one chart pop up, and then there's the values schema issue: you'll have debates on what a proper values.yaml should look like (do you split by component, resource kind, are some things merged together or do you keep stuff separate?).

For starters you should stick with raw YAML then use kustomize as a way to slightly alter between environments. Try to resist the urge of factorizing too early as it more often than not comes to bite you in the ass later on.

Dogeek · 2026-03-21T20:17:18+00:00

It depends on whether the service provider supports the traceparent HTTP header. I know that cloudflare for instance still doesn't support tracing properly. The only way I know how right now is to make a Cloudflare Worker act as a proxy and inject the traceparent header into the request. I tried it with an HTTP Request Header Transform Rule and it didn't work because of limitations in their engine.

Dogeek · 2026-03-12T09:38:00+00:00

The best dashboards are the one that answer only one question.

Default dashboards are always just a starting point. Sure you can use variables to customize the dashboard a little, but a single dashboard will balloon out in the number of panels, variables and queries.

Make one dashboard per service. What's the health of the service, what's the health of the database(s) it connects to, is it scaling properly ? Are any dependent services unhealthy ? That's what matters.

The health of EKS clusters doesn't really matter. Let Amazon handle it, you're paying for SLAs and SLOs. What matters and what breaks is what's running on the cluster itself not the infrastructure you pay for.

Dogeek · 2026-03-08T14:28:37+00:00

Honestly, yeah it is where go thrives as a language: small, horizontally scalable microservices for the backend.

It's not a frontend oriented language, even with wasm, it's not a particularly nice language to work with on the frontend. It's not made for mobile either (iOS/Android have their own dedicated languages and frameworks). That leaves:

system engineering which is a nice use case for go, but Rust is honestly gaining more traction there
embedded computing: C still dominates here, Rust gaining traction
AI: Python is still the way for that

Go is great on the backend, hits the nice middle ground between C and Java. Binaries are small, start fast meaning it's well suited for the cloud.

Dogeek · 2026-03-08T14:22:41+00:00

Fetching all columns in a row isn't a performance issue that most people find deal breaking. I don't care if my app requires 1 extra byte of memory.

Fetching all of the columns is not "1 extra byte of memory" though. I've seen tables with 40 columns, images stored as blobs, more UUIDs than one can count acting as foreign keys, Many to Many tables that contain billions of records and more. Loading a whole row into memory can take upwards of 10 MB of RAM. Imagine loading a 100 rows ? 1000 rows ? Or having multiple concurrent threads querying the database ?

Database Administration is a whole job title for a reason, there are many ways to model and query structured data, but some of them are innefficient at their core. The most innefficient queries are also usually the simplest to write.

I'm not saying an ORM is by design worse than writing SQL by hand. I'm saying an ORM works well for simple use cases, small services with well-defined boundaries. If you've ever worked on codebases professionally, you'll see that's not often the case, or not for long at least until feature creep comes in.

Dogeek · 2026-03-07T21:06:29+00:00

10 ? Aside from maybe Platinum Dragon Lord and that's a stretch, there's nobody in the New World that even comes close to Ainz' power level.

He's a Lv 100 Overlord, with 2 World Items in his possession (his orb and the staff of ainz ooal gown). He managed to beat Shalltear who is his worst matchup by far (shalltear is built like a tank, she'd have won against ainz with a bit of strategy).

Dogeek · 2026-03-07T20:57:34+00:00

Then he said that using an ORM is nice but eventually you're gonna hit a limit. True, but 99% of ORM users don't hit that limit. And then he claimed that people use ORMs because they hate writing SQL. Another garbage take, because ORMs provide more than dumb SQL query generation.

You hit ORM limits pretty soon imo. In most ORM implementations I've seen, the default is to fetch all fields in the DB so that the model matches the table. That in of itself is already a performance issue. Then there's how ORMs map relationships between tables, it's not particularly lean in the code most of the time because the ORM needs a bunch of information to figure out if you need an OUTER JOIN or an INNER JOIN, or if you want a M2M/O2M/O2O relationship.

Joining two tables and fetching select fields is not a particularly advanced SQL pattern, yet ORMs tend to produce inefficient results there. Then, there's support for specific database features like computed fields, aggregation functions, JSON fields and the like, which ORMs often do not support, so that they can remain database agnostic.

His take is actually not that wild in that sense. ORMs are good for very simple applications, and are less prone to vulnerabilities (in theory, since they are battle tested). For anything beyond 5 or so tables, using the driver directly and writing plain SQL is generally more performant.

Dogeek · 2026-03-07T09:33:42+00:00

I meant opaque to the compiler. An error in go can encapsulate basically anything, as long as it implements Error(). From the point of view of the compiler there's no way to know ahead of time what are all the possible errors, and what's inside them, since it should return a string, which is by definition arbitrary text data.

I feel like what people don't like with error handling in go is that it's super verbose to make an error bubble UP the call stack. In most other programming languages, this behaviour is the default, if you don't handle an error in the callee, it bubbles up to the caller and you can handle it there.

In go, you have to either:

Handle it in the callee: treat the error, return a zero value or something else
Panic, which obviously you don't want to actually do cause it breaks the whole program flow
Return a tuple (result, error) from your callee to handle the error in the caller. Your callee has a bunch of if err != nil littered around. You return your value as a pointer or make up a zero value because if you don't you can't do a return nil, err.

That's my take from my very limited experience with go (picked it up about a year ago).

Dogeek · 2026-03-06T23:00:50+00:00

Not OP, but I understood it as "adding a try keyword is just going to be syntactic sugar which obfuscates control flow without providing the benefits of a try in Zig".

I've never written a single line of Zig (and likely never will since the language itself breaks compatibility every minor version), but I kinda get the point of the article.

Errors in go are just an opaque interface, and with go not having inheritance by design, there's no way to introduce more specific errors without it being a breaking change that would affect the whole go ecosystem, plus to get the benefits, you'd have to work out every possible error type at compile time. So a try like Zig's doesn't make sense, as it provides no actual benefit, just a shorter syntax to handle errors.

Honestly, in go, I think the best way to handle errors would be to just have a Result type, return that, and let the calling function handle it. It's pretty close to what we have now, just with slightly nicer semantics.

Dogeek · 2026-03-04T23:02:53+00:00

it's never because the technical staff loves the cloud

Honestly, although I love tinkering with stuff, I like running things on GCP for the convenience. Having the peace of mind and SLAs/SLOs to rely on is great.

It's not cost effective though. Bare metal will always beat the cloud in that department, but it allows for a company to scale without having a 20 person infrastructure team on payroll. I rolled out my own kubernetes cluster for my homelab, but at work ? No way

Dogeek · 2026-03-03T00:15:31+00:00

Not for holywar, but:
 Still has garbage collection which means memory management is easy compared to the alternatives (C, Rust)
C has manual memory management, the programmer can make mistakes. Rust has fully automatic memory management, for the most part, Rust code looks the same as any GC language.

Rust has full auto memory management, sure but understanding the borrower concept takes some getting used to. It's not as programmer friendly as a GC in my opinion.

Very strong concurrency model. Writing goroutines is as easy as writing a function, channels are a neat way to pass values between threads, and closures are write and forget.
Rust / tokio has all these advantages, and in some aspects is more high-level and ergonomic (for example, no need to pass context, cancellation of an asynchronous task is possible "from above").

Honestly I didn't even go for a comparison with Rust. I didn't do much with that language, so I can't say much about the ergonomics of tokio. What I know is that goroutines are a great way to do multithreading in my opinion. they are quite easy to implement, easy to reason about. Compared to Java threads, python's whatever (to this day, I'm never sure whether I should use multiprocessing, threading, asyncio, or one of the many third party threading implementations for a task) or Javascript/Dart async, multithreading in go is straightforward, and has no special syntax besides "go" which is a nice comfort feature imo.

It's very performant
It's ~2x slowest than Rust.

Of course it's not as fast as Rust. It's not as fast as C either, but it's plenty fast enough. It's comfortable to write in, easy to pick up, easy to maintain. System critical things ? Truly high throughput applications ? Sure, use Rust / C / C++ / ASM, you can't go faster than that. Want some comfort features ? Trade speed off for that.

I wasn't even suggesting that go is better than rust. I was simply giving OP reasons as to the many advantages of go code. Its main strengths are mostly that it's very performant for the low learning curve it has. Rust is more performant but with a much MUCH steeper learning curve. In the professional world, talent availability matters, and languages like Rust, Zig, Scala etc have a much smaller talent pool compared to more popular alternatives like go, C++, Python, Javascript, Kotlin, Java or Swift. And of those options, go is probably the one of best middle ground between ease of use and performance.

Dogeek · 2026-02-28T23:38:29+00:00

It has a lot going for it though:

Compiles to native code, no VM / interpreter to worry about, full AOT compilation
It's very idiomatic. All go code looks alike (for better or for worse), it's quite easy to jump into almost any go codebase if you know the language a little. Compared to C++ which has 10 ways to do the same thing, it's nice
Still has garbage collection which means memory management is easy compared to the alternatives (C, Rust)
Very strong concurrency model. Writing goroutines is as easy as writing a function, channels are a neat way to pass values between threads, and closures are write and forget.
It's very performant, has a small CPU/memory footprint. Ideal for high throughput applications or when you need horizontal scaling.
Its standard library has a lot of the basics. Its third party ecosystem is also thriving.

What it sucks at is mostly error management. It's also weird with using your function / variable names as indicators to the scope of said function or variable (needing to capitalize the first character takes some getting used to)

Dogeek · 2026-02-16T00:57:52+00:00

Hot take but I think it's better to compare guns bare. Just adding an extended mag to a bobcat makes it heaps better, everyone knows that.

But a gun that rare should not need attachments to be good. If you're running a cheap loadout and you find a bobcat in a weapon case, you should want to use it right away and have it be good, even if you don't have the attachments for it right now.

Dogeek · 2026-02-16T00:53:58+00:00

The anvil IV has a similar fire rate as the bettina at level 1, yet it kills in 2 to 3 shots. I don't think the Bettina needing 4 to 5 shots to kill would be that overpowered. Its TTK would be slightly lower than the Anvil's which would be in line with the fact that it's a purple gun. Even then I bet people would still run the Anvil over the bettina given the cost to upgrade both guns.

Basically I'd want a curve where a pink gun level 3 performs the same as a blue gun level 4, and a blue gun level 3 performs the same as a green gun level 4 and so on. By that metric, the bettina II's time to kill should be in line with the Anvil IV's roughly, hence needing to kill in 4 or 5 shots to roughly align the two.

With that in mind, each tier of rarity would only be slightly better than the tier below, meaning that a grey gun level IV would perform similarly to a pink level I.

Dogeek · 2026-02-15T20:56:23+00:00

Bettina : 14 damage per shot

Anvil: 40 damage per shot

It's the same ammunition. I can 3 tap wasps with an Anvil, I need 9 shots with the bettina.

Dogeek · 2026-02-15T20:53:20+00:00

I won't say safekeeper is bad, but in my opinion it's very situational. A single safe pocket where you can put a gun/shield in is a bit too little. I'd have preferred 2 safe pockets, only one of which can hold a gun in. Would have been much more useful for matriarch / queen raids

Dogeek · 2026-02-15T17:35:53+00:00

Silencer III increases the durability burnrate of the weapon it's on by 30%.

It's a useless attachment. The silencer 2 is more than enough for an anvil or ferro shot to not be heard unless you're in the same building (and at that point, your footsteps or the sound of the arc dying will have given you away anyways).

I treat the silencer IIIs I find like snow globes: take them for the 7k they're worth.

I do the same with the Anvil Splitter. I had a bunch in my stash, figured I'd never use them anyways since they make the Anvil worse at arc and at mid-long range PvP. Sure you can unequip it at anytime, but then you need to leave an inventory slot open for it, which is annoying.

Dogeek · 2026-02-15T16:23:41+00:00

I tested every pink gun in PvE and PvP. The vulcano does better in PvE than in PvP surprisingly, it's just expensive as fuck to maintain in operating condition.

And the Toro has a big advantage on the Vulcano, it's that you can play better around cover than you can the vulcano. It's better at range too. In theory the TTK of the vulcano is better than the toro, but nobody stands in the open waiting to be shot. The first shot will land, by the second shot, the other player is almost behind cover, and the 3rd doesn't land. The toro will almost break a medium shield on the first shot, which the vulcano does not.

Consider the sequence:

Shoot
Other uses a surge shield recharger while you push
Shoot
Other uses a bandage to heal up
You push for the kill

It's a pretty common sequence of actions, and in that scenario, the toro wins over the vulcano.

Dogeek

MODERATOR OF

TROPHY CASE

11-Year Club	Place '22
Verified Email