I'm on the hunt for ways (system instructions/first message prompts/settings/whatever) to do away with all of the fluffy nonsense in how LLMs 'speak' to you, and instead just make them be concise and matter-of-fact.
fwiw as a regular user I typically interact with LLMs through either:
- aistudio site (adjusting temperature, top-P, system instructions)
CLI tools are better about this IME. I use one called opencode which is very transparent about their prompts. They vendor the Anthropic prompts from CC; you can just snag them and tweak to your liking.
Unfortunately the “user instructions” a lot of online chat interfaces provide is often deemphasized in the system prompt
ChatGPT nowdays gives the option of choosing your preferred style. I have choosen "robotic" and all the ass kissing instantly stopped. Before that, I always inserted a "be conciseand direct" into the prompt.
i found robotic consistenly underperformed in tasks and it also drastically reduced the temperature, so connecting suggestions and ideas basically disappeared. I just wanted it to not kiss my ass the whole time
… and then the return argument is that those who actually want to do this nefariously are already going to be able to hide device modifications/rooting.
For us the combination of WoW and WC3, then later LoL, are what ruined the thriving LAN centre scene across Ireland. There were 12 or so actual GAMETHEWORLD centres, then other wee franchised ones. WoW especially just didn't lend itself to LAN gaming, absolutely sucked the life out of the centres.
The issue that was noted at larger LANs I used to go to was that matches of DotA could lock in around 12 people for around 45m per game which would make getting participants for other games more difficult. There would be constantly running CS/UT servers where people would drop into to kill time, but trying to get a large game running or something like battlefield required advance planning
Thank you for the report! I was thinking of redoing the landing page for a while anyway. Are you using a niche browser or something like that? I haven't had anyone experience this issue nor was I able to reproduce it.
I'm going to go out on a limb and guess you don't manually check the headers for every single email, or even only every one from Google and co, so are you doing something to flag or visualise this in some way?
Whenever I get an email that seems like it's a scam or scary like this I will open headers and the Received headers (sometimes even a From et. al. are enough) will give it away.
In zero cases did I care about SPF, DMARC or DKIM.
I recognize that this is not something non technical people or even technical people that don't know how email works and that don't have a broader technical ability/knowledge can usually use/do but it has worked 100% for me so far. knocks on wood.
I literally only skimmed the article looking for any place they might show all headers and finally when they had the list of Received I was like: duuuh, that's the first you should have looked at and this would be a non blog.
So of course it's still bad this happens as most folks, even technical ones, couldn't read email headers to save their lives and rely on little badges and filters based on things like DKIM to keep them safe.
The sibling comment basically answered for me; I don't check the headers unless I'm feeling suspicious, and such an immediate urgent call-to-action definitely counts as suspicious.
It helps that I'm using a client which shows all the headers by default, and I normally just scroll past them if I don't have doubts; all the mainstream consumerist ones seem to make that very difficult or even impossible.
If anything, it seems hiding these details is a way to increase blind trust in things like DKIM and promote learned helplessness, so they have the incentive to make clients opaque.
Ah right, that's odd, wasn't aware I lived in a totalitarian society here in the Nordics. We literally just get a notification to check it, and because the state is neither trying to gotcha us or baby us, that's just the norm. The part that takes longest for me in the whole process is usually the 2FA.
Forgive my ignorance, feel like it's embarrassing to ask here to be honest, but can someone explain how this helps/works? I've never actually used these placeholders, but I always imagined that they work by processing the image beforehand on the server and using something like a super low quality image or gradient or such as the placeholder. If this is done in pure CSS, does the browser not need to download the image first to figure out what's in it, before then doing the placeholder effect? Perhaps it doesn't help that I've not had my morning coffee yet, but I don't understand.
These placeholders are generated by processing the image on a server beforehand. Generally they create some html, css or svg markup that is served inline. Having to do a separate request for such placeholder is very bad idea.
It's not clear if these placeholders do actually help, especially placeholders with very low quality. In my opinion, they only add visual noise.
I'd focus more on avoiding layout shifts when images load, and serving images in a good format (avif, webp) and size (use `srcset` or `<picture>`).
> It's not clear if these placeholders do actually help
Well, it depends what you mean by help. It’s very dependent on use case and desired UX. Obviously you can prevent layout shifts without them, you can provide feedback on loading status in other ways, and ensure images don’t slow load time without colored placeholders. But they can provide a pleasant UX for some use cases, when done right. They can be annoying when not done well.
There are certainly legitimate cases where the placeholders come from a separate request. Most
CRDTs and similar sync engines you don’t want to (and/or are not allowed to) store binary images directly inside them, so you need to store references to some other blob storage. But Blurhash is a simple short string (and LQIP here is a simple integer) and those store well in CRDTs and other sync engines, so you can pair that with your reference pointer (which might not even be a URL depending on your blob storage engine and its sync mechanics and authorization schemes and whatever else) and whatever other metadata you want/need to include like width/height or aspect ratio and alt/title/caption.
When the CRDT or document sync engine inevitably sync much faster than your blobs you have something to show in that placeholder. If the blob sync fails for some reason, you still have something to show more interesting than your browser’s old broken image logo under your “Sync is slow or broken” warning.
I think placeholders help a bunch in situations like that where your image fetch is a lot more complicated than a URL that you can add in a `src` attribute. It’s also really easy to get into situations where such blob fetching is complex: In cases where you have to respect user and/or tenant privacy and need complex OAuth flows. In cases where you need end-to-end photo encryption. In cases where you need peer-to-peer sync and only P2P sync because you’ve been mandated to reduce touch points and likelihood of accidentally storing photos at rest in middle layers. Situations like images of HIPAA data, PII, PIFI, etc.
On a static site with public (or cookie sessioned) images direct linked by URL, yeah the placeholders don’t do much other than check certain design boxes. There’s lots of other places images (and their metadata) come from, and placeholders are a useful fallback in the worst cases.
It’s still computed at build time or dynamically, by a programming language. The “pure CSS” part of it means that the hash is decoded into something visual by CSS without any JavaScript required.
This same thing happening on the 40 series cards was good enough vindication for me not 'upgrading' to that at the time. I'd rather not burn my house down with my beloved inside.
I can relate to this perspective! It's important to step out of the system and recognize priorities like this; balancing risk and reward.
I think, in this particular case, perhaps the risk is not as high as you state? You could imagine a scenario where these connectors could lead to a fire, but I think this is probably a low risk compared to operation of other high-power household appliances.
Bad connector design that's easy to over-current? Yes. Notable house-fire risk? Probably not.
fwiw as a regular user I typically interact with LLMs through either:
- aistudio site (adjusting temperature, top-P, system instructions)
- Gemini site/app
- Copilot (workplace)
Any and all advice welcome.