It's equivalent to multiplying all inputs by log b. And multiplying all inputs by a value changes how much the probabilities are extremized. This is easy to see because adding a value to everything doesn't change the output, so the biggest input can be assumed to be 0 and others negative. So multiplying by 0 makes all outputs equal while as the multiplier tends to infinity, all other inputs tend to -infinity and thus the biggest output tends to 1 and others to 0. Multiplying by negative numbers results in the lowest becoming the highest.
The Linux kernel is not usable as a security boundary, so anyone who wants to do "shared hosting" and not be hacked needs to use something else, like gVisor or firecracker VMs
The only important system that uses it as a security boundary is Android and there is mitigated by the fact that APKs need user approval, plus strict SELinux and seccomp policy plus the GrapheneOS hardening, and in this case the mitigations succeeded (https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...)
I'm quite sure there are many application hosting providers which rely on container runtime such as runC (default runtime of containerd/Docker), and a shared kernel between users.
In a just world, those companies would be held legally accountable for negligent practices. The Linux kernel upstream has made it clear for decades that security is a dirty word.
I thought that was the entire design goal of the Unix model, didn't it originate in the times when hundreds of users logged on to a shared mainframe? There are still public Unix servers like SDF out there. SELinux is just an extra layer so that if someone gets root (ex. due to an exploit in your setuid code or cron jobs etc) it's not game over.
Unix originated during the early days of what was called "time sharing", but it was developed for relatively small computers typically shared among a small workgroup within an organization. It was not initially designed to be a highly secure system.
This is how you end up with a file called "/etc/passwd" that is required to be world-readable.
SDF used NetBSD. In the 90's they switched for a while for RH under X86. Worst era ever, very insecure. Now they use NetBSD X86-64.
On Hyperbola GNU/Linux, they will shift into OpenBSD, they got fed up with the corporate slopware (and propietary Linux became). They will still make Hyperbola BSD GNU-license compatible, from core to the userland tools.
In my case, I wish Emacs and GNU developers embraced plotutils and left out Gnuplot (is not GNU at all; worse, it conflicts with the GPL) and made Texinfo independent of LaTeX to produce PDF and HTML files with equations. Groff + troff+pic+eqn already do that, no Texlive needed.
So can mandoc under OpenBSD, no magic needed, everything under few MB's.
Texlive it's huge (full instal it's over 7GB) and the so-called free FSDG is not 100% free, at all.
With just that GNU Emacs would be truely GNU-standalone, relying on GNU tools for plots under Emacs' Calc and Texinfo books exported into PDF. A good plus for security.
Once you get that working, the rest would just follow their way. Also, GNU Hurd being developed with propietary LLM's/SAAS it's a disgrace against what GNU stands for too.
They can go back to the right path, but they need will, for sure.
Absurdly high price for a novel device of unclear utility (a VR headset but incompatible with all existing VR software) resulting in few users.
No support for PC VR nor Android/Quest VR apps resulting in little software, no massive investment in getting Vision Pro specific software written, little interest in porting due to the few users.
I think you can fix this by either patching the binary and replacing the offending prompt with an empty string, or by pointing the harness to an API proxy that filters it out
You don't seem to realize that humans also work this way.
If you ask a human why they did something, the answer is a guess, just like it is for an LLM.
That's because obviously there is no relationship between the mechanisms that do something and the ones that produce an explanation (in both humans and LLMs).
An example of evidence from Wikipedia, "split brain" article:
The same effect occurs for visual pairs and reasoning. For example, a patient with split brain is shown a picture of a chicken foot and a snowy field in separate visual fields and asked to choose from a list of words the best association with the pictures. The patient would choose a chicken to associate with the chicken foot and a shovel to associate with the snow; however, when asked to reason why the patient chose the shovel, the response would relate to the chicken (e.g. "the shovel is for cleaning out the chicken coop").[4]
Most humans don't have split brains, and without split brains you have quite a bit of insight into the thoughts in your brain. Its not perfect but its better than nothing, LLM have nothing since there is no mechanism for them to communicate forward except the text they read.
> Most humans don't have split brains, and without split brains you have quite a bit of insight into the thoughts in your brain. Its not perfect but its better than nothing, LLM have nothing since there is no mechanism for them to communicate forward except the text they read.
I can't prove it but this is almost certainly one of those things that is uh, less than universal in the population.
I'm aware of the condition, but let's not confuse failure modes with operational modes. A human with leg problems might use a wheelchair, but that doesn't mean you've cracked "human locomotion" by bolting two wheels onto something.
Also, while both brain-damaged humans and LLMs casually confabulate, I think there's some work to do before one can prove they use the same mechanics.
On LMArena, Claude Opus is ranked as the best at everything except image and video generation, which it does not support. That may be inaccurate, but it's plausible
1. Anthropic has not published anything about why they made the change and how exactly they changed it
2. Nobody has reverse engineered it. It seems easy to do so using the free token counting APIs (the Google Vertex AI token count endpoint seems to support 2000 req/min = ~3million req/day, seems enough to reverse engineer it)
Obviously an image picker shouldn't leak filenames... The filename is a property of the directory entry storing the file storing the image. The image picker only grants access to the image, not to directories, directory entries or files.
If you want filenames, you need to request access to a directory, not to an image
I have had more cases where I was very surprised that the local filename I used for something became part of its record when I uploaded it somewhere. (For instance, uploading an Mp3 using Discord on desktop web.)
There are many, many more cases where the user doesn’t expect the name to become public when he sends a photo. If I send you a photo of a friend that doesn’t mean I want you to know his name (which is the name I gave the file when I saved it)
I email images as attachments very, very frequently. I go through the browser's file picker and I pick out the photo by its filename. I would be surprised and angry if somewhere along the way the filename got changed to some random string without my knowledge and consent.
In fact, I often refer to the name of the photo in the body of the email (e.g., "front_before.jpg shows the front of the car when I picked it up, front_after.jpg shows it after the accident.")
From a technological standpoint, sure. I'd argue when you're staring down the barrel of 19,234 duplicate file deletions, with names like `image01.jpg`, `image02.jpg` instead of `happy_birthday.jpg`, there's a level of perceptual cognitive trust there that I just can't provide.
If your camera (or phone) uses the DCF standard [0], you will eventually end up with duplicates when you hit IMG_9999.JPG and it loops around to IMG_0001.JPG. Filename alone is an unreliable indicator.
Which systems still use this shortsighted convention? All photos I’ve taken with the default camera app in the last many years are named with a timestamp.
> If I want to find duplicates, it will be impossible if the filename changes.
Depends on what is meant by a "duplicate." It would be a good idea to get a checksum of the file, which can detect exact data duplicates, but not something where metadata is removed or if the image was rescaled. Perceptual hashing is more expensive but is better distinguish matches between rescaled or cropped images.
It's not "obvious" at all, since it's contextual, it depends on the purpose and semantics of whatever service you're uploading the photo to.
Depending on how it'll be used next, not only can the current filename be important, I may even want to give something a custom filename with more data than before.
reply