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?

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?

Comments and opinions are welcome!