Very cool! What a wonderful game. The Wireless Data Transfer level is unreal.

I am trying to see if I can build some small mechanism that resembles the ATP Synthase mechanism… Perhaps a bit too ambitious of a starting point, haha. The program runs smoothly in my Linux machine.

Yes, this is a problem that happens with a lot of detector types as one tries to push them to detect lower energies.

In this specific case, light is captured by a retinal molecule that is held within an opsin protei and this excess energy allows it to twist. The opsin protein envelope tunes the environment around the retinal molecule such that it absorbs photons of specific colors. To tune these to lower energies means altering the energy landscape in a way that makes the twisting of the retinal molecule require less energy. Temperature is a measure of the kinetic energy of molecules, and some molecules at room temperature can move with kinetic energies that match the energy of infra-red and sometimes near-infra red photons. So, from time to time, molecules with enough kinetic energy may collide against the protein with enough force to induce the twist without light. Absorbing near-IR light would lead to an increase in thermal noise, because the opsin becomes activated by a collisions more often as opposed to light.

Here is an image showing the retinal twisting and the energy landscape. The ‘hv’ arrows indicate light absorption, and the opsin’s structure alters the energy curves.

The core-shell upconversion nanoparticles are special in that the photoactive region in the core is protected from the environment by an inert transparent shell. Light can pass through the shell and create localized electronic excitations within the core, while it is much more difficult to transfer the energy from a molecular collision against the outer layer into a localized excitation in the core. This shell is a strong dampener that protects the core from external influence.

Here is an example image of the core-shell structure, for reference:

What is the justification for selecting the range 2022 - 2025? I suspect that this is cherry picking.

One of the data sources they reference is: https://www.cdc.gov/hantavirus/data-research/cases/index.html, this site has data up to 2023 (I could not find 2024 - 2025). Here is the plot of the total hantavirus cases in the US vs year:

The number of cases vs year is rather noisy, and 2022 was a particularly low year. Saying that there is a ‘192% increase’ might be technically true but misleading.

If you are looking for eye bio mods you might also like this one: https://www.sciencedirect.com/science/article/pii/S0092867419301011

Not yet, unfortunately… But knowing more about what might be happening in the brain to cause it increases the probability that a cure will be found.

Definitely, disclosing (either private or publicly) a vulnerability that has been verified is significantly better than passing on the LLM output without verifying it.

It isn’t my intention to argue one specific case. What I think is that normalizing public disclosure of LLM-inspired vulnerabilities would lead to a wide distribution of cases. We would have some successful cases like yours, and also some cases of the type that I have mentioned. Increase in disclosures will raise the noise floor, and the fact that it is done publicly adds the additional pressure that I mentioned.

I see your point, but I don’t agree that the benefit of public awareness offsets the increase in noise. This disagreement isn’t rooted in aspects that we can objectively quantify though - we just have a difference of opinion here.

And in that world, doing a private disclosure made a lot of sense because you did a lot of hard work to find it, and it wasn’t easy for somebody to replicate. This was valuable and dangerous knowledge that had to be communicated in a responsible fashion.

Private disclosure still makes sense to me when you add LLMs into the mix. It is possible that an LLM outputs some plausible-sounding story that over-estimates the actual risk and impact of the exploit. If this story is publicly announced to people who use the software but are not capable of assessing these risks themselves, this can easily have a negative unnecessary consequence - for example, people may bring their server down until an expert or developer provides an assessment or fix.

This is a source of noise, and I don’t agree that this is better than private disclosure. Via public disclosure one is applying a lot of pressure to the developer(s) to prioritize whatever is being disclosed, which may not always be the nicest thing to do, especially if the impact is not as significant as the LLM suggests. This may not have been what happened in your case (I don’t know the details), but I am thinking about the idea of the average person disclosing publicly LLM-discovered vulnerabilities.

😁 👍

So, ultimately my problem was that I was trying to set all of the limits to what I thought were “reasonable” values simultaneously, and misunderstood what ‘Message’ meant, and so I ended up breaking things with my changes without the reason being obvious to me. I looked into the source code and I can see now that indeed ‘Messages’ refer to API calls and not direct messages, and that there is no ‘Direct Message’ rate limit.

If I let ‘Messages’ stay high I can adjust the other values to reasonable values and everything works fine.

Thanks a lot for your help!! I am surprised and happy it actually worked out and I understand a little more 😁

Have fun! 😁

Thanks!

I was able to crash the instance for a few minutes, but I think I have a better idea of where the problem is. Ths $emote_addr variable seems to work just the same.

In the rate limit options there is a limit for ‘‘Message’’. Common sense tells me that this means ‘direct message’, but setting this to a low number is quite bad. While testing I eventually set it to ‘1 per minute’ and the instance became unresponsive until I modified the settings in the database manually. If I give a high number to this setting then I can adjust the other settings without problem.

Yes, I see this there. Most of the nginx config is from the ‘default’ nginx config in the Lemmy repo from a few years ago. My understanding is somewhat superficial - I don’t actually know where the variable ‘$proxy_add_x_forwarded_for’ gets populated, for example. I did not know that this contained the client’s IP.

    # backend
    location ~ ^/(api|pictrs|feeds|nodeinfo|.well-known) {
      proxy_pass http://0.0.0.0:8536/;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";

      # Rate limit
      limit_req zone=mander_ratelimit burst=30000 nodelay;

      # Add IP forwarding headers
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

I need to do some reading 😁

Wow! Beautiful jumping spider!

Thanks! Yes, I saw both messages and I am now going through the NGINX config and trying to understand what could be going on. To be honest, Lemmy is the hobby that taught me what a ‘reverse proxy’ and a ‘vps’ are. Answering a question such as ‘Are you sending the client IP in the X-Forwarded-For header?’ is probably straight forward for a professional but for me it involves quite a bit of learning 😅

At location /, my nginx config includes:

      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

So, I think that the answer to your question is probably ‘yes’. If you did have these rate limits and they were stable, the more likely explanation is that something about my configuration is sub-optimal. I will look into it and continue learning, but I will need to keep my limits a bit high for the time being and stay alert.

I don’t recall any of them being from mander (unless they were dealt with before I started testing?), but thanks for taking preventative measures :)

I don’t know what ‘Antiyanks’ is

It’s the codename for a particular long-term troll and is based off of their original username pattern (which they still use sometimes). I have reason to believe it’s also the same troll that used to spam the racist stuff in Science Memes.

These are most of today’s batch (minus the JON333 which was just a garden-variety spammer that made it into the last screenshot).

No, they were not in mander.xyz. But I am generally quite relaxed when it comes to accepting applications. I mostly reject an applicant if it is very clear it is not an actual user, and then actively follow up on recent accounts for a short time. So the possibility of silent spammer accounts accumulating over time is always a concern.

So, a ‘Comments’ Rate limit: 10, Per second: 60, means a maximum of 10 comments per minute, correct?

Correct, per client IP.

Setting the limits to more reasonable values, like ‘20 posts per minute’, causes the server to stop serving posts. My front page goes blank.

So, I am starting to think that ‘20 pots per minute’ means ‘requesting 20 posts per minute’ and not ‘creating 20 posts per minute’.

I am still having doubts about what these limits mean, but setting reasonable numbers seems to break things, unfortunately.

Hmmm - after changing these settings to what I think are reasonable settings, the server crashed and I am now getting ‘Too many requests’ messages… So, perhaps there is something not working so well with these rate limits, or I am still misunderstanding their meaning.

Thanks for the heads up. I don’t know what ‘Antiyanks’ is, but I already had to ban one comment spammer.

The rate limits are indeed a bit confusing. The settings are:

Rate Limit: X Per Second: Y

I understand this to be ‘X for every Y seconds’

So, a ‘Comments’ Rate limit: 10, Per second: 60, means a maximum of 10 comments per minute, correct?

Maybe the reason you see 99999999 is due to troubleshooting. I have increased my instance’s limits multiple times while troubleshooting server issues, because the meaning of the settings was not clear to me. These limits are usually not the reason for the sever issue, but I put some high number and did not bring them back down after the issues were resolved.

I have lowered them now to more reasonable numbers. I will also be more strict with new applications for the time being.

Trying not to get stung + arms getting tired + unable to look through the viewfinder or camera screen, because the nest was above my height and I had to keep my hands up to aim the camera at the nest. One of these would walk out every few seconds, stand in a random position near the hole, and fly away quickly.

Of course, no worries at all! I also was not active. Thank you for pointing it out. I will pay attention.