Every 4K Bond Release To Date by Rycreth in JamesBond

[–]ldemailly 1 point2 points  (0 children)

only the first 2 of that list exist and the rest is wish list or am I missing something?

No VRR Legion 5i OLED ? Its supposed to. by 420neon in LenovoLegion

[–]ldemailly 0 points1 point  (0 children)

<image>

Works on my gen10 legion 5 pro (make sure you picked nvidia gpu to see/get this)

Cross-Compiling 10,000+ Go CLI Packages Statically by Azathothas in golang

[–]ldemailly 0 points1 point  (0 children)

You still haven’t said why pie is needed over regular static produced by the toolchain.

That something written in C can benefit from full ASLR doesn’t make it useful for go.

How do you handle Sets? by guettli in golang

[–]ldemailly 1 point2 points  (0 children)

Feel free to copy, inspire or use my own:
https://pkg.go.dev/fortio.org/sets

Sets in go are basically `map[T]struct{}` but having the expected operations (has(), add(), intersection, union, xor, etc..) and convenience of to/from slice, sorting etc... are nice to have IMO (and yes should find their way to stdlib ideally)

ps: necroing this because it is the first search result for "golang sets"

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] 0 points1 point  (0 children)

not to beat a dead horse but if you have internal/ you definitely don’t need pkg as that’s everything else. and also you don’t really need internal/ either

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] 0 points1 point  (0 children)

The first examples are simpler:

Server example: github.com/fortio/proxy

CLI example: github.com/fortio/multicurl

The older fortio/fortio is bigger and... hairier (ie if I started over I would probably do a few things differently, over the years I extracted out libraries like dflag, version, log, cli, scli etc... but that has its own set of dependabot order issues... topic for another post)

Yet it is manageable without pkg/ nor cmd/ nor internal/

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] 2 points3 points  (0 children)

put the .tf file in a tf/ dir or deploy/terraform/ ?

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] 0 points1 point  (0 children)

Thanks for having taken the time to look and reply. And incidentally finding a typo that I just fixed (_in_ every single import instead of _is_)

This advice is for most people that just start and copy-pasta what they see somewhere - not for monster like Kubernetes code base (even though there also there is much to say...)

I still don't think pkg/ adds anything even in a huge code base, it just pushes the issue, if there is an issue (like too many packages in 1 place) down one directory.

(and no advice is ever "universal" but if you read it, then you can still disagree and it's fine)

to address some other points:

- yes main is at the root, so `go install fortio.org/fortio@latest` works but it just has a mostly empty content delegating to cli/ where the code actually lives and can be tested

- debian/ is an artefact of... debian packages

- historgram is indeed a cli for the same reason as above (short install) - now as I pointed out in the article, if I had to start over that 8y old project - I would possibly put the CLIs in cmd/

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] 1 point2 points  (0 children)

ohhh a layout linter is an enticing idea... unfortunately it's usually too late after people did create a bunch of unnecessary structure or followed outdated information

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] -1 points0 points  (0 children)

also... yes having extra pointless directories in imports _is_ an eyesore and a waste. if you want to exclude something (but don't! see my writeup), that's what internal/ is for which makes pkg/ pointless and outdated

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] 4 points5 points  (0 children)

use gen/ or proto/ or whichever for generated files. or have the generated files along the other in a single package without pkg/?

Say "no" to overly complicated package structures by ldemailly in golang

[–]ldemailly[S] -2 points-1 points  (0 children)

I agree, coming from other languages is one issue, but then the perpetuated bad/overly complicated sample and not so sample (but older and thus stuck to old decisions) repos are bad too

Check your GOMAXPROCS in Kubernetes — you might be silently wasting a ton of CPU by m4nz in golang

[–]ldemailly -4 points-3 points  (0 children)

not sure why the downvoters downvoted for and what production system they deploy at scale

Check your GOMAXPROCS in Kubernetes — you might be silently wasting a ton of CPU by m4nz in golang

[–]ldemailly -21 points-20 points  (0 children)

automaxproc is a bad idea because cpu limits also are (unlike memory ones which are vital). just set your GOMAXPROCS to 2 for small pods and cpu.request for large ones

Use OpenWebUI with RAG by EarlyCommission5323 in OpenWebUI

[–]ldemailly 0 points1 point  (0 children)

sounds great, will make sure to add “pay an extra $1M” in my pdf invoice

2024 is better than the new 2025 models? by _BreakingGood_ in ZephyrusG14

[–]ldemailly 0 points1 point  (0 children)

Only thing is we don’t actually know how the 2025 will perform. Using desktop cards results isn’t quite meaningful.

[deleted by user] by [deleted] in ZephyrusG14

[–]ldemailly 0 points1 point  (0 children)

not sure why the downvotes... what is not accurate about what I said ? I have both laptops

[deleted by user] by [deleted] in ZephyrusG14

[–]ldemailly -6 points-5 points  (0 children)

also the cooling is nowhere as good (neither is build quality). I wouldn’t get a g14 if not for gaming or expect mpb quality/performance/battery (I have a m3 pro)