I think both preceding comments are a bit too strongly worded. I’m experimenting as well with pairing deterministic programming with llm use in a similar fashion and find that it allows you to squeeze more out of smaller models than with llm-only agentic loops. It is also no question for me that the large SOTA models can do way more in llm-only agentic loops with less hassle and pre-work. If you discount the hassle of actually running them, that is.
So I guess it depends a bit on what your objective is.
As far as their public website tells (https://www.riec.nl/) the RIEC is about a targeted bundling of knowledge, experience and resources to better deal with the effects of organized crimes, instead of everyone working in their own little silo.
The "interventions" are basically the forming and supporting of work groups / special interest groups around a specific organized crime phenomenon, with the intent of devising an approach to deal with the specific phenomenon. They publish a report of those so-called interventions here: https://www.riec.nl/documenten/publicaties/2024/12/18/interv...
My comment is made from the background of someone who has led the effort of bringing software development in-house, building a 20-odd FTE dev team, and is still leading it 3 years in.
I'd not bring everything in-house at once unless you really have to. Your fear that the devil is in the details is very much justified (I have stories, boy, do I have stories ...). However, in your position I would definitively start building a dedicated tech team. That allows you to start developing real solutions to solve pain points in a way that feels less like "filling the gaps" and more like "the first steps towards a better future". It also may make you a better, more informed customer which may perhaps help with your current vendor as well. It also gives you something to fall back on if the proviable shit really hits the fan with your current vendor.
Do not underestimate the importance of product management. Product management drives your development team. If you now use a basically off-the-shelf product, this is likely taken care of for you. Or not, given you describe the vendor as stagnant. In either case, you need to have that covered well.
One-is-zero: do not rely on single individuals, build a team. At the leadership level you'd want at least a product lead, business analyst, cto and a senior software architect. Make sure they work together as a team and that there is healthy cross-over in expertise/experience so that people can cover for eachother. In-house, not contracted.
I'd advice against fully outsourcing to an agency. You can contract a development team, and depending on where you are located that may be the most realistic option, especially in the beginning. But make sure you are at the steering wheel and have the people and experience in-house to use that wheel well (see previous point).
Invest in boring things like documentation and testing right from the beginning. It will pay for itself many times over. If you let it slide, you'll never catch up and you'll pay for /that/ many times over.
Other than that there's probably a lot I've learned from my adventure so far, but I find it typically difficult to assess what the lessons learned are unless someone pokes me with the right questions. Feel free to reach out at my HN username @ mailbox.org.
Exactly this. For the docker images we use in production, we fork the corresponding git repo, build our own image and push it to our own local docker registry and pull it from there. It's fairly easy to setup in fact.
You might be able to proxy the dictionaries from your own server? Unless something in the t&c's of the dictionary providers prohibits you from doing that of course.
Hmmm I've a distinctly different experience. In my experience their support is good and their engineers quite knowledgeable. Tickets are dealt with within reasonable time frames. If I really do need something to happen quickly, I can call in and have someone knowledgeable on the phone within 10 minutes, who often will do whatever is necessary right away. During a recent issue they had two engineers in two time zones working on it, to shorten the time to fix as much as possible (still took a long time, but it was a difficult issue so ...).
Well, that's the million dollar/euro question isn't it? It's a bit hard to verify with all the secrecy going on. And arguably without some level of secrecy you cannot have effective intelligence. It's a bit of a catch-22.
In fact the Dutch owned New York once (then called New Amsterdam ;-) until they effectively traded it with the British for Suriname and some spare change.
And that whole Dutch East Indies and Indonesia thing still has some repercussions till this day.
"Non-intrusive" is the most important part here I think. Measuring productivity does not produce anything that adds to your bottom line directly.
An often overlooked aspect of performance/productivity management is that there should be a nett benefit ...
In addition to templating, orm and routing there is also highly integrated i18n toolchain/workflow, built-in csrf protection, good session handling, well integrated caching and many more of such 'details'.
All those things by themselves could be considered trivial and could be gotten from many individual libraries - the level of integration and polish you encounter with Django is anything but trivial though and takes real time and effort.
I've recently had to make a choice for a Python based application platform/environment and have chosen Django (again) despite having no use for the ORM and ORM-using contrib modules. Simply because all the other things are there and work together beautifully without me spending any time on code that is not directly related to my goals.
Yes, I know, it's turtles all the way down, of course.
Still, I think that "but here we are aiming for practical applications not a philosophical debate about how everything is just an illusion." is a dangerous statement. Some people would say the same about something like sql injection, or cross-site scripting (Really? Yes, really, I encounter them on a regular basis).
With security issues the border between 'practical' and 'not practical/philosophical' depends on your threat model. If the kind of adversary that is able to compromise your JS engine does not appear in your threat model you can ignore the possibility of your JS engine being compromised and your solution may be good enough. If however that kind of adversary does appear in your threat model you do not have that luxury and your solution is not good enough.
That's not philosophical, that's real world practical.
I was not referring to your comment per se, but indeed your comment fits the general sentiment I was referring to.
And I think that localStorage is indeed literally no better than server-side storage. Whether it is any worse depends on the situation - but better it is not.
"This ignores the scenario of app deployment models like Chrome Packaged Apps, in which the JavaScript code gets downloaded up-front and then is only used locally. Since you don't re-download the code every time, you only depend on the security of the code once, up-front, instead of on a continuous basis. You aren't affected by server compromise (well, no more than compromise of your OS vendor, but surely you aren't arguing that we might as well send all our keys to Microsoft, Apple, and Canonical)."
It's true that you do not re-download the code every time. Still, the trustworthiness of the code you received initially depends on the trustworthiness of the server you received it from.
So you say, "but what if I have reason to trust it initially and not later on?", e.g. when the government comes knocking.
Well, there are two things to keep in mind in that case:
a) you download other stuff with your browser. Stuff that can influence the environment where your secure and trusted packaged app runs in. See also comment of zimbatm - even if it is not formally meant to be that way, in practice there are bound to be ways around any limitations - sandboxing in browsers is still nowhere near perfect unfortunately. Server security is not entirely peachy either, but at least on a properly secured server only a limited, carefully screened set of applications is allowed to run which makes things hell of a lot easier.
b) Chrome packaged apps support auto-updating, so unless you take steps to prevent that from happening, you're never sure you're running the same version today as you did yesterday. Again, trusting the server to serve you a trustworthy version of the app repeatedly. And if you're trusting the server already, local storage is no better than server side storage.
So I guess you could say local storage is better than server side storage (for some definition of better) if you run one and only one packaged application ever in a specific installed browser in an isolated environment. The browser + locally installed web app then effectively becomes a natively installed application without an Internet dependency. More secure indeed, but kind of defeating the purpose of that whole web thing ;-)
You're technically correct - it's all a matter of degrees of certainty. That does however not invalidate any of the points made in the article.
If that native C application runs on a server that is fully under your control you stand a far, far better chance then when that native C application (say a web browser) runs on some computer not under your control. Especially if that native C application is explicitly written to accept run-time addition of random third-party code (aka browser extensions).
True - but how is a web server with certainty going to decide which clients can be trusted (because they've a truly capable browser)and which are not to be trusted (because they have a vulnerable and compromised browser that just pretends to be capable and secure)?
Of course it may be possible that one day there is a way around that issue, but currently there is not. Not even academically let alone practically. Hence Thomas's next remarks about the impossibility of 'graceful degradation' for crypto-in-the-browser issues.