nmaludy's comments

nmaludy | 2 months ago | on: Programming language speed comparison using Leibniz formula for π

If i'm understanding the repository correctly, it looks like each language reads from a file, does some I/O printing to console, then computes the value, then some more console printing and exits.

In my opinion, the comparisons could be better if the file I/O and console printing were removed.

nmaludy | 2 years ago | on: Double Standards

I asked about that and never got a response. My thought would be some sort of side/end fed cooling fan instead of one that exhausts out the top.

nmaludy | 4 years ago | on: Memory leaks: the forgotten side of web performance

Warning, im feeling synical this evening...

Completely agree! I find that a lot of developers don't understand how things work under the hood or how things fit together. This always comes back to bit them. Same can be said for modern infrastructure engineers / DevOps / sysadmins.

nmaludy | 4 years ago | on: NVMe over Fabrics Explained

I'm curious how NVMe-oF compares to iSER?

From a quick search it seems that NVMe-oF is still early days with limited implementations, where iSER is more established. Both rely on RDMA.

I could not find any performance comparisons. Any insight here?

nmaludy | 5 years ago | on: Getting Started with Ansible

I do agree that Ansible is quite easy to start with, YAML being a fairly simply syntax to understand if you've never coded before.

One of the things i struggle with most in regards to Ansible is that things that are semi-interesting like loops, conditionals, data munging, etc are quite complicated and cumbersome. I agree that things like Puppet and Chef make these tasks _much_ easier and i end up writing more understandable code that works just like any other scripting language.

I also _very_ much appreciate the fact that i can unit test my code in Puppet and Chef. As part of a good DevOps practice, unit testing along with integration/acceptance testing is crucial!

On top of that i believe that the roles in Ansible Galaxy are very much sub-par when compared to modules in Puppet Forge. Most of the modules in Ansible Galaxy are simply "install package, start the service". In general, Puppet Forge modules are much more in-depth and allow for configuration and customization to many aspects of the application you're configuring.

Also, check out Bolt from Puppet: https://puppet.com/docs/bolt/latest/bolt.html

Bolt is an "ad-hoc task runner" very much like Ansible. One of the cool things you can do with Bolt though is apply Puppet code as part of the run, so you can reuse all of the Puppet Forge modules that already exist.

nmaludy | 5 years ago | on: An update to the Timescale license

Agreed!

We run several instances in production and have had zero problems. TimescaleDB engineers, if you are watching / reading. Thank you VERY MUCH! You totally rock!

nmaludy | 5 years ago | on: Moving your SSH port isn’t security by obscurity

An FBI agent from the Cyber Crimes division gave a talk while I was in college (>10 years ago). He was interested in brute force attacks against SSH daemons and created a couple hypotheses around number of logins and common passwords. To test this he setup two Honey Pot to record all of the username/passwords. The first one listened on standard SSH port 22, the other listened on a random high-numbered port. He left both of these running for ~6 months.

Results: The honey pot listening on standard port 22 received 1,000s of login attempts (sorry, don't remember the exact number). The honey pot listening on the random high-numbered port received exactly 0.

I know this is just an anecdote and it might not necessarily be true today, but this experiment always sticks in my head. At least the guy used the scientific method: created a hypothesis, conducted the experiment, analyzed his results.

nmaludy | 6 years ago | on: Gitlab features that are moving to open source

Bummed that Pull Mirroring isn't on the list. I really want to use GitLab for CI/CD, but we dont want to store our code there exclusively. Instead we use a series of scripts to work around this problem. Would be great if the core platform just supported this.

nmaludy | 7 years ago | on: Verizon Digital Operates 20k Servers

Very interesting use case here. Would love to get more technical details on the scale-out process. The author mentioned two pieces:

- Turning down the data retention period in the database. Wonder how long data is kept?

- Scaling out with additional worker nodes. Curious what st2 processes got scaled out? st2actionrunner, st2rulesengine, st2api?

Any other tips/tricks?

page 1