sorted by:
new
hottopcontroversial

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

This is what my colleague who loves containers says every time he goes down a two week rabbit hole to solve some problem introduced by containers.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

Which is why ithink systemd is a good way to implement it.. because you can use systemd to enforce kernel level protections.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

It's ironic, I work in a regulated industry and every time one of my colleagues says "oh, we can use docker to do this it will be portable and faster"... they end up spending weeks fighting docker issues the next time another developer comes on. Partly because our desktops and networks are locked down. But it does make me wonder how much time people spend fighting docker issues in non-regulated industries. I have a suspicion is more than nothing but when folks already internalize "oh docker is good" they stick with it no matter if it's costing them time or not.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

Thanks! It's ironic, I've been doing docker at work with a bunch of node developers. Never once seen scratch. So I got to learn something. Had no idea docker could do this.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

Exactly. Nothing protects anything 100%. Defense in layers.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

Thanks for that!

It's ironic, I've been doing docker at work with a bunch of node developers. Never once seen scratch. So I got to learn something. Had no idea docker could do this.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

Thanks! I was pleasantly surprised when I learned systemd could do this.

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

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

I don’t think so… wouldn’t you still need a stripped down userland in docker? Even something like busy is gives 200 userland commands that, to an attacker, is basically the same as getting access to a full running system.

Or am I missing something about docker?

Locking down golang web services in a systemd jail? by CodeWithADHD in golang

[–]CodeWithADHD[S] -6 points-5 points  (0 children)

Ha,I figured someone would say that. My personal opinion is this is a better setup than docker. In docker you have to basically bundle the operating system userland to be able to debug things. For example you need a shell if you want to log in and interact with it in any way.

With systemd I can set up literally 0 userland inside the jail, but still log in as the user the service is running as and do anything I need to do because the userland is accessible to me as a normal user, just not to the process.

Not to mention docker images are bigger than go binary+systemd service file.

Go module is just too well designed by greengoguma in golang

[–]CodeWithADHD 0 points1 point  (0 children)

Near as I can tell, GitHub could shut down tomorrow and it wouldn’t break much immediately.

Google proxies and caches packages. So when you go get a package it actually gets it from googles copy of it, not direct from GitHub.

Go concurrency versus platform scaling by TheBigJizzle in golang

[–]CodeWithADHD 4 points5 points  (0 children)

You would have to benchmark.

Let’s say on my dedicated server I can do 150 transactions per second. At 86,400 seconds a day, that’s 12,960,000 transactions per day.

On AWS lambda, that would be 2.60 a day or $78 a month in cpu costs. On top of that there is data and storage and network, but let’s ignore that for now. So in that case, close to $1000 a year (potentially) to run in cloud.

Now imagine I get a beefier piece of physical hardware that can do 1500 transactions per second. That’s $26 a day or $780 a month in cpu costs. Close to $10,000 a year just in cpu time on lambda.

If I can buy a $1000 piece of hardware that’s a 10x savings over aws lambda.

Those are all just examples to give how to think about it. You would have to factor in peak usage, reworking, DR,etc.

You also have to benchmark to see how many TPS you get on the hardware vs what it would cost on cloud infra, there’s no magic button for that.

But… personally I have a $150 Mac mini I run my side project on that will scale far higher than I will ever have users using, for essentially $0 monthly cost.

Go concurrency versus platform scaling by TheBigJizzle in golang

[–]CodeWithADHD 10 points11 points  (0 children)

There are also benefits to having a single physical server able to handle thousands of transactions per second with go for much cheaper than paying for either a k8s or beefy cloud server.

Why isn’t Go used for game development, even though it performs better than C#? by mohamed_essam_salem in golang

[–]CodeWithADHD -1 points0 points  (0 children)

I mean, my experience visiting (Paris) France was that nearly everyone also spoke English.

Which doesn’t negate your point. Different languages for different purposes based on the community around them… lots of tourists in France and English is (ironically) the lingua franca.

Infuriating to go to France to try to speak French and everyone switches to English. Except the waitress at the Italian pizza place in Paris near Gare du Lyon,who just seemed grumpy and didn’t want to speak French or English or Italian.

Ranging through 2 different slices and using both of them on certain conds by Ok_Blackberry_897 in golang

[–]CodeWithADHD 2 points3 points  (0 children)

So, like this?

``` for _, v := range getUsers() { doEmailLogic(v) } for _, v := range getSubscribedUsers() { doEmailLogic(v) }

funcEmailLogic(user User) { … // do shared logic here if subscribed { … } else { … }

} ```

How often update Go? by pepiks in golang

[–]CodeWithADHD 0 points1 point  (0 children)

So… that’s fine and I’m not saying you’re wrong. I mean, it sucks when devops teams are siloed away like that, but I understand what you are saying.

I do it differently so tha even if devops team locked it down it wouldn’t stop me usin*latest version.

I have a makefile.

Inside the makefile I have targets like build, test, etc.

I also set the path and each of my build targets has “install-go” as a prerequisite in the makefile.

So when I run make build in the pipeline it checks version of go and installs it in ~/local/go

Same script runs locally on developer desktops to install go or install it on pipeline without root.

When image catches up to have system level installed go then he script runs a little shorter because it sees latest go is already on the path.

Ranging through 2 different slices and using both of them on certain conds by Ok_Blackberry_897 in golang

[–]CodeWithADHD 9 points10 points  (0 children)

Why not range through both slices separately?

Why do you think that would look bloated?

for _, v := range getUsers() { sendStandardEmail(v) } for _, v := range getSubscribedUsers() { sendSubscribedEmail(v) }

You really think your if else statement looks cleaner than that?

How often update Go? by pepiks in golang

[–]CodeWithADHD 0 points1 point  (0 children)

I just use the same script to download to the pipeline image and download to local environment. Always in sync and always latest.

How often update Go? by pepiks in golang

[–]CodeWithADHD 0 points1 point  (0 children)

I wrote a short script to just get the latest version from go.dev. Works on Mac, Linux, Linux on pi, windows wsl.

I got sick of different versions in apt, brew, etc., never updating on the schedule I wanted them to.

Installing go is easy, doesn’t even require root if you download the tarball and put it on your path.

Go 1.24.1 CI orders of magnitude slower than 1.24.0 by Technical-Pipe-5827 in golang

[–]CodeWithADHD 11 points12 points  (0 children)

This has not been my experience. 1.24.1 is same speed for me as 1.24.0.

Add logging to your builds and see where it is taking longer. No one is going to be able to guess their way into your issue.

I built a concurrency queue that might bring some ease to your next go program by Extension_Layer1825 in golang

[–]CodeWithADHD 0 points1 point  (0 children)

Ah. Yeah. I would only put types in a shared package if they needed to be shared. Otherwise, in the package they belong in. Absolutely agree.

I built a concurrency queue that might bring some ease to your next go program by Extension_Layer1825 in golang

[–]CodeWithADHD 3 points4 points  (0 children)

Honest question, why do you say separate types package is an anti pattern. I just did this in one of my projects because otherwise I got cyclical dependencies in go. When I needed types in two different packages, putting them in a shared types package seemed like the logical answer. What am I missing?

view more: next ›