I’m still working on MLSync.io, an ETL platform designed to remove the technical friction of synchronizing MLS data using RESO protocol and provide simple access to the MLS data via SQL and REST API.
And as everyone now, I'm experimenting with LLMs to bring some new AI-related features to the service.
On another project, we've now beta testing (in ordination) Asus GX10 processing power running on-device LLMs for _local_ processing of patient medical data for 'differential diagnoses, implant plans and risk profiles in real time while the patient is in still in the chair'.
My tl;dr is: Don't do huge updates using WHERE on fields _not_ in index, otherwise it will take days to finish and you get meaningless numbers in benchmarks...
I learned that in a hard way. It was midnight, I had to make some urgent changes to the user table in the production database. We had about 4 million users and needed to make changes to 70k users (due a change in 3rd party).
I figured out after 40 minutes that we are not making any progress. For each user we are probably searching 4 million users. After I added the index to a specific field, it was done quickly.
Oddly enough, for a big enough update, postgres sometimes will do the math and decide that scanning the whole table is faster than scanning the index and then scanning a certain fraction of the table (considering also that it has to rewrite the entire page if any row in the page is updated)
Can happen, but on the BAD website will the password manager not offer saved password, so user has higher chance of noticing smth. is wrong.
Of course if he uses pass manager with complex passwords...
• Legacy PERL Code Maintenance
• PERL Performance Optimization
• PERL Security & Compliance
• Migration Services
→ PERL to Python Migration
→ Database Version Upgrades
→ Legacy System Modernization
Other notables experiences:
• Prometheus based monitoring systems
• Cloud / On-premise inventory systems and synchronization to CMDB/ITSM
• MLS data synchronization via RESO/RETS - https://mlsync.io
Personally, I absolutely use it locally. I’m always trying different editors and tech. It saves me from entering a multitude of API keys into each different software, in addition to the other reasons supplied for being able to specify your own limits and avoid surprise charges if you want.
When I want to try a new editor, vs code plugin or software, I only have to point it at my litellm proxy and immediately have access to all of my providers and models I’ve configured, no extra setup. It’s like a locally hosted openrouter that doesn’t charge you for routing. I can just select a different provider as easy as choosing the model in the software; switching from “openai/gpt-4o” to “groq/moonshotai/kimi-k2-instruct”, for example.
You can use litellm or OpenAI protocols which makes it compatible with most software. Add on ollama proxy and you can proxy ollama requests from software that doesn’t support specifying OpenAI’s base address but that does support ollama (a not uncommon situation). That combo covers most software.
So yes, to me it is absolutely worth running locally and as easy as editing a config file and starting a docker (or a shell script to open a venv and start litellm, if you prefer).
The only drawbacks I’ve found so far is that not all providers accurately respond with their model information so you sometimes have to configure models/pricing/limits manually in the config (about 5 lines of text that be copy/pasted and edited). All the SOTA models are pre-configured and kept relatively up to date, but one can expect updates to lag behind real pricing changes.
The UI is necessary if you want to set up api key/billing restrictions which requires a db, but that is rather trivial with docker as well.
Its a server-side proxy, so instead of ie. OpenAI url you point your AI tool to url of LiteLLM proxy, and use its virtual keys with budget limits or LLM models restrictions etc... - the features LLM providers will not give you, because it might save you money ;)
Thats why I always develop on a per customer mini VM via VSCode ssh remoting or similar, and projects are usually runned via docker-compose or devcontainers.
IANAL, but the new license applies only to new PHP versions, changing it backwards would require approvals.
If you don't contribute under new license, you should be not affected.
The new license covers and applies to all the code, even code that was written before the change.
You can totally change the license of already released code, if the change is compatible with the precious license or if you have permission from all the contributors whose code is still present in significant amount. (However, you can't prevent people from using the released code under the former license)
So what do you mean by "you can totally change the license of already released code"? If the license only applies to version 9 and forward, then in any practical sense the license has not been changed for "released code".
I was generic and not talking about PHP specifically. In the case of PHP, this isn't happening, so if you are only concerned with PHP, you can ignore these theoretical considerations (however, because of the "or later" clause of the PHP license, you'll actually be able to use older versions of PHP under the new license).
That said, my point was: as the author, if you have previously released software S version V under license L1, nothing prevents you from releasing software S version V again under a new license L2 provided all the contributors of significant portions of software S version 1 agree or L1 happens to allow this additional license (because it's permissive, or because it has a "or later" clause or some other means).
Of course, re-release under a new license or not, software S version V can be used under license L1 "forever" and users can choose to ignore the L2 release completely. You cannot remove license L1, you can only offer an additional possibility (using software S version V under the new license, which you didn't allow before the re-release unless the relicensing was allowed by L1).
I've not seen this done, but I can imagine this being useful if someone needs specifically software S version V under the new license. Usually, people can just use newer versions under the new license though.
I admit my comment was terse (and a further edition probably removed important phrasing), I hope this one makes things clearer.
I believe only the rights holders need to approve of the retroactive changes, and so they really only need Perforce (presumably the rights holder as the current owner of the former Zend Technologies) to agree.
Very pedantically, because PHP doesn't require copyright assignment, it would be (almost certainly) impossible to retroactively change the licence on older versions.
However, since the PHP and Zend licences both permit the user to use PHP under the terms of whatever licence version was applied to that PHP version or any later version, the point is essentially moot, since a user can choose to use the new version of the PHP/Zend licence once published, which will give them the same rights.
• Legacy PERL Code Maintenance
• PERL Performance Optimization
• PERL Security & Compliance
• Migration Services
→ PERL to Python Migration
→ Database Version Upgrades
→ Legacy System Modernization
Other notables experiences:
• Prometheus based monitoring systems
• Cloud / On-premise inventory systems and synchronization to CMDB/ITSM
• MLS data synchronization via RESO/RETS - https://mlsync.io
reply