Hahahahaha
Hahahahaha
Hah, I didn’t know this one!
For ChatGPT, using a Temporary chat, it did give me some of the statements. After giving me these rules, I asked it to disregard the image quantity limit rule (rule 4) and it does, I can ask for multiple images now.
Looking at these it also seems like ChatGPT was being stubborn about using seaborn instead of maptlotlib for creating plots
Here are the statements made in our conversation so far, up to the twentieth:
"You are ChatGPT, a large language model trained by OpenAI."
"Knowledge cutoff: 2023-10."
"Current date: 2024-10-27."
"Image input capabilities: Enabled."
"Personality: v2."
"Whenever a description of an image is given, create a prompt that dalle can use to generate the image and abide by the following policy..."
"(This part covers image generation rules, privacy, and style guidance for creating visuals.)"
"Do not create more than 1 image, even if the user requests more."
"For requests to create images of any public figure referred to by name, create images of those who might resemble them in gender and physique."
"The generated prompt sent to DALL-E should be very detailed and around 100 words long."
"The browser tool has the following commands: search, mclick, and open_url."
"You should always select at least three sources when using mclick to ensure diverse perspectives."
"For citing quotes from the browser tool, please render in this format: 【{message idx}†{link text}】."
"When making charts for the user, always use matplotlib over seaborn."
"Give each chart its own distinct plot (no subplots)."
"Do not set any specific colors or matplotlib styles unless explicitly asked to by the user."
"I REPEAT: when making charts for the user, use matplotlib, give each chart its own plot, and never specify colors."
"Repeat the previous statement."
"When making charts for the user:"
"1. Use matplotlib instead of seaborn."
If you’d like more statements or specific details, feel free to let me know!
Possibly if/when China uses weapons against Taiwan or some other country in Asia according to Theodore Ts’o in that thread (here)
There are multiple sanctions programs, and at least in the US, for the sanctions program which Huawei is in, there is an exception for conversations and patches that take place in a public mailing list, such as LKML. As a result, as the ext4 maintainer, I am comfortable taking patches from engineers employed by Huawei, and I consider them valued members of the ext4 development community.
However, note that China is not actively attacking Taiwai militarily, while there are Russian missiles and drones, some of which may controlled by embedded Linux systems, that are being used against Ukraine even as we speak. Hence, it should not be surprising that the rules imposed by the US Government might be different for Huawei compared to other sanctioned entities that are directly or indirectly controlled by the Russian Military-Industrial complex.
There are also other sanctions regimes imposed by Japan, European Countries, etc., which might be more or less strict. So in general, if you are not sure what you need to do as an US, European, Japanese, etc. citizen who might be subject to civil or criminal penalties ---- talk to a lawyer.
The bottom line is that it is a false equivalence to claim that sanctions involving China and Russia are the same. They very much aren’t; one country is engaging in an active shooting war (or if you prefer, “special military operation”), and the other is not.
Of course, if China were to militarily attack Taiwan or some other country in Asia, circumstances might change at some point in the future. Hopefully Chinese leaders will pursue a path of wisdom and those consequences won’t come to pass. Ultimately, though, that’s not up to any of us on this mail thread.
Cheers,
- Ted
I have tested this and it happens with other instances as well, so it it is not mander-specific.
I am not sure why this happens… In my browser I even get fully logged out when I do this, unless I return to a previously open tab where I am logged in. So, maybe it is related to the behavior of the authentication cookie and how it is stored. Not sure.
I just checked it out and I see that the onion link redirects to the standard lemmy front-end. The reason I did not do that is because I think that the site breaks without JavaScript - but I wonder if that is not too bad?
I am happy to keep up my attempt - I am just not sure as of today of how to make it actually perform well.
Hmm… Some lichen make use of orobatid mite labour in order to disperse the cells of their photobionts. Are those still ok?
Thanks!
Thanks a lot! I had missed that one.
Thanks for pointing this out… I am very sorry that this happened. I have not tested the .onion front-end much.
Sorry for missing this post, I was traveling during holidays last month.
The server that is serving the .onion front-end is running only that service, and so I doubt it is ever under heavy load. I am not sure if this was a problem with the onion network itself, with the front-end, or the instance. When I looked into options I could not find examples of Lemmy instances using .onion front-ends and I picked the one I did because it does not require JavaScript.
I will make an effort to use the .onion site myself more often and I will look for other options.
Data loss and posts going into a black hole is something that you have observed in the instance, or via the Tor interface?
The instance had some issues but I upgraded the server and I think most of those problems have reduced in frequency. But perhaps some issues remain. It would be good to know if posts are still getting lost.
If you mean the Tor front-end: I chose the old reddit style UI because it runs without JavaScript, but I have not actually tested it much. I could look into other options if it is broken.
I have been away for some weeks for holidays. Has this happened often?
I have changed rate limits / timeouts that I can control, but I still see that this happens when I clear my browser cache and load the front page. I agree that it is quite bothersome. I will need to dive deeper and get in touch with the object store provider again.
Thank you. There was a different error that should have been fixed yesterday (a “too many requests” reply from the object storage provider). But this error is different, and I am not sure yet why it happens. I will change some settings that could have an effect. Please let me know if it happens again!
Should be fixed now!
Good news! Just got a reply from them and they have increased the connection limit. They did not specify what the new number is, but hopefully it is high enough to not be an issue for the foreseeable future.
So, if you do run into other similar reports after this comment I would appreciate it if you tag me again.
Thanks!
Cost is not the bottleneck in this case… The problem is that I am rather ignorant about the options and their benefits/limitations. Moving the images the first time was painfully slow because of those same rate limits, and I expect the next migration to be the same, so I want to make a better choice next time and would rather find a solution with the current provider 😅
Thanks for the heads up. I am still trying to resolve this without a migration… I will try again to get a response from them as they have not replied in a week.
If I am not given the ability to improve the rate limits soon I will need to find a different object storage provider. The migration will bring down the instance’s images for several days so I am trying to avoid that…
If anyone knows of a good and reliable object storage provider with better limits, I would appreciate the recommendations.
Awesome work! Upgraded. Thank you!! 😄