> Looking at the PHP bug tracker the specific bugs were fixed. So my best guess is that the LLM was able to find alternative variants that still worked?
In the link from the comment to which you replied, buried deep below the comic strips and all that, there is this explanation which seems to confirm your guess:
> Right. We should explain from the start. My first step of finding if any long-lost siblings of Stefan's 2004 bug were still lingering in the codebase was to look for ways to exceed the memory_limit that allows us to throw a controllable fatal. I asked my LLM companion for help.
> The first useful finding was a way to bypass the smaller post_max_size barrier that normally prevents a request from delivering enough memory pressure to reach memory_limit. PHP compares post_max_size with the declared Content-Length before automatic POST parsing begins, but it does not enforce the same limit against the bytes it actually consumes. Apache can therefore pass a chunked HTTP/1.1 or lengthless HTTP/2 multipart request with no meaningful declared length. A configured input-decompression filter creates the same mismatch between the compressed length and the decoded stream.
> The second useful finding was a way to exhaust memory_limit with a multipart request that remains below post_max_size. An RFC1867 file-upload part with filename="" contains no file data, and PHP does not count it toward max_file_uploads. PHP still creates all six corresponding $_FILES entries: name, full_path, type, tmp_name, error, and size.
The article notes that it was written by an LLM from a conversation, and indeed it would benefit greatly from a good copy editor, but I still find it an interesting way of looking at the effects of LLM use now that the token-maXXing wave is receding:
> The term Demulsification describes the physical separation of a stable emulsion into its distinct chemical constituents. In software labor economics, high enterprise salaries acted as an artificial emulsifier, suspending supernumerary application bloat alongside core systems craft within the same engineering organizations.
> As AI tools collapse the cost of generating high-level glue code, this corporate emulsion is rapidly breaking apart:
First I thought this post was someone looking for a job, then seeing that it was only a link to a company's About page and that your user name matches its co-founder's name it seemed as if you were offering a job and the question mark got lost somehow.
But then I do not see any indication in your website that you are expanding and given the current situation it sounds more likely that the link is meant as a portfolio to show what you have done lately.
Then again, the lack of a jobs/careers listing might be a way to prevent a flood of automated applications.
> After all that work, and the expense of getting an original Zytek interface, giving it away for free seems almost as socialist as Britain’s NHS. But the potential market is limited to fewer than 400 owners. “You don’t have to be a mathematician to understand the very limited upside of trying to sell something like this,” Radom explained. “The better approach is to increase the value of the car itself by giving away the technology.”
I learnt about the XJ220 from the Amiga game and many years later got to see a real one at the Technikmuseum in Speyer, Germany. What a beautiful machine!
For a more detailed technical description you can see my 2019 edition of Chip Morningstar's “Xanadu Hypertext Documents” architecture and data structures from 1986, that got some comments in HN: https://news.ycombinator.com/item?id=30905524
This is absolutely relevant to my interests and I will try it out in a few hours as it is early morning in Europe now.
So far I do not see any licensing terms, the source file headers only state the copyright notice. Do you have any plans about that?
> I came up with the idea while waking up from a nap and then was so blinded by how great this feature would be to have.
This has happened to me many times. In my case I forget how my program works fron all the approaches I have tried while writing it, then get excited to try a great idea which then does not work because it relies on some feature from one of the alternatives that I rejected for some other reason.
I will indeed waste a few hours trying the PDF indexing idea, there has to be some way to make it work. I have done some feeble attempts in this direction by myself before using the C library pdfio ( https://github.com/michaelrsweet/pdfio) which would work also on Windows. I will probably crash again on that wall but if the code search works as described I will still use this program every day.
I usually don't put a license in my repos, sometimes because I never really know which one to put in, and other times because I don't really know what I would want to allow or disallow, etc. I put a license on my vec-mat-comp-quat repo but that was because it was essentially a library so by its nature, it would have to be used in other people's code. The license I chose required (IIRC) or perhaps requested, that the users let me know how they use my library, but to this day, no one has - so that's another reason I don't usually put a license (people will probably ignore it anyway).
In regards to your story of essentially the path not taken: in general when I create a version that either doesn't work or doesn't work as well as I wanted, I keep the file around (renamed usually). Sometimes, much later I figure out how to make it work or some part of it becomes the basis of another project. Unless I didn't spend much time on it, I don't like to waste effort. The PDF addition was kind of an example of that - I kept the file around, but then when I was prettifying things up to upload to github, I figured I would add the PDF code to my file and put it within #ifdef's in case someone would want it. And also, in case you haven't noticed, I provided many different versions of the search system - it's harder to maintain, but allows the user to pick the option they like the most. So, in your case, you never know if the paths not taken might someday be paths you will want to go down.
For my own selfish purposes I would like to have a license that allowed me to reuse parts of SearchEngineSuite as if it was a library, for instance Apache 2.0 which I used for my C preprocessor at https://sentido-labs.com/en/library/cedro/202106171400/
I am preparing a pull request adding the Apache license in case it is acceptable for you.
The article does not promote it on security grounds:
> This article however will focus on the technical reasons why I won't be installing Omarchy yet. It boils down to what I call the security sweet spot.
> ... Most of the improvements I read about seem to focus on the desktop and UX, but I wish this humble list gives some food for thought about deeper OS architecture in terms of security and privacy.
No, that is not what I meant. No replacement for the person who left the organization has been hired. It would be inaccurate to say that they were "replaced" by AI, insofar as we had no plans to get rid of them if they had not decided to leave.
Might be your ISP's DNS censoring the domain name, it happens to me for different ones depending on whether I am in Spain or in Germany at the moment when I click the link.
It might work if you manually change the TLD part of the URL.
What I did was get the IP address when it worked and add it to "/etc/hosts" so it works when on another network.
> A town, street name or postcode were omitted, but a highlighted note – presumably written by a postie – chirpily added ‘Royal Mail, we never fail!’ to the front of the letter.
I think the note was written by the sender because the handwriting looks the same as in the vague "woman in Cornwall shed" address.
My guess is that it was intended to motivate Royal Mail to figure it out by quoting what might have been their slogan at some point. Now the highlight could have been added by a post office worker as a way of saying "indeed we never fail". The sender's style of higlighting things seems rather to be adding asterisks.
In the link from the comment to which you replied, buried deep below the comic strips and all that, there is this explanation which seems to confirm your guess:
> Right. We should explain from the start. My first step of finding if any long-lost siblings of Stefan's 2004 bug were still lingering in the codebase was to look for ways to exceed the memory_limit that allows us to throw a controllable fatal. I asked my LLM companion for help.
> The first useful finding was a way to bypass the smaller post_max_size barrier that normally prevents a request from delivering enough memory pressure to reach memory_limit. PHP compares post_max_size with the declared Content-Length before automatic POST parsing begins, but it does not enforce the same limit against the bytes it actually consumes. Apache can therefore pass a chunked HTTP/1.1 or lengthless HTTP/2 multipart request with no meaningful declared length. A configured input-decompression filter creates the same mismatch between the compressed length and the decoded stream.
> The second useful finding was a way to exhaust memory_limit with a multipart request that remains below post_max_size. An RFC1867 file-upload part with filename="" contains no file data, and PHP does not count it toward max_file_uploads. PHP still creates all six corresponding $_FILES entries: name, full_path, type, tmp_name, error, and size.
> https://calif.io/php2shell/#you-said-oom-fatal
reply