Yes, there is a lot of potential. There are micro-spectrometers available covering this range, like the MEMS-FPI type spectrometer or the multi-pixel arrays with filters (example: https://www.mantispectra.com/products). But this new kind of detector seems to come with higher resolution, faster readout than the MEMS-FPI, and more sensitivity. It is quite exciting, I’m curious to see if they commercialize it soon.
I am not 100% sure, but I think that the designer bears the cost of the wafer yield.
The PDK is specific to the manufacturer, and I imagine that the risk associated with specific features is known and the yield range can be estimated. A design with more and riskier the features would lower the expected yield, and it makes sense that this risk gets passed onto the designer. The contract may have some protections for the case when the yield is significantly lower than expected because of the manufacturer’s fault. Just a guess though, it would be great if someone with real experience can answer.
Very cool!
I also like that they included a device cost analysis. I think they used some aggressively optimistic assumptions (100% yield from the wafer) and large-volume procurement prices that I am skeptical of, but if true it is valuable info.
Wait what, how do you know my code?
Also: I use the timer very often, and I find setting a timer on a phone to be more awkward.
Sport watches.
Combination of two tings: I used to think that wearing a watch was irrelevant because I could always see the time in my phone. And I did not want to have an app knowing how many steps I take.
What changed a few years ago: I stopped having a phone on me most of the time, so a watch became extremely handy for knowing what time it is, and I found out that Garmin watches work perfectly well without an app. So, now, I really like my watch. I am considering getting a fancier one with solar charging, and I even got a chest strap to improve measurement accuracy while running.
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 😁
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 😁
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.
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.
Is your friend alright?