nmaludy

We've had good experiences with Lattice parts. Their software tools are free for all of their basic chips. They only charge for licensing when you use the higher end SKUs with SerDes. Example, you can use and develop on an ECP5 or Certus using their free license, but then you need a paid license to work on ECP5-5G or CertusPro chips.

They're not perfect, but they're better to work with than Xilinx. Also, their datasheetd are better than Xilinx in my experience.

Give Lattice a look for your next project.

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.

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.

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.

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?

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.

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!

Different servers.

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.

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.

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?

If you're into emacs there is something similar called restclient.el https://github.com/pashky/restclient.el

Comments and opinions are welcome!