And a Finn abroad.
Randomly updated home page at http://bostik.iki.fi
- One should also remember that NVidia does have organisational experience on designing and building CPUs[0].
They were a pretty big deal back in ~2010, and I have to admit I didn't know that Tegra was powering Nintendo Switch.
- Correct. From what I understand, Shodan has had for years a search feature in their paid plans to query for "service X listening on non-standard port". The only sane assumption is that any half-decent internet-census[tm] tool has the same as standard by now.
- > On the other hand, removing exec permissions to /tmp, /var/tmp and /dev/shm is also useful.
Sadly that's more of a duck tape or plaster, because any serious malware will launch their scripts with the proper '/bin/bash /path/to/dropped/payload' invocation. A non-exec mount works reasonably well only against actual binaries dropped into the paths, because it's much less common to launch them with the less known '/bin/ld.so /path/to/my/binary' stanza.
I've also at one time suggested that Debian installer should support configuring a read-only mount for /tmp, but got rejected. Too many packaging scripts depend on being able to run their various steps from /tmp (or more correctly, $TMPDIR).
- Your CI has to be fully codified, stateless and possible to redeploy with a single command. That's the only way it can remain sustainable. No persistent hidden state, no manual configs (even as an option!) and automatically rebuilt on every release as the new version is deployed.
As a really big bonus, that also makes your CI testable.
In the previous job, we built such a thing: https://smarketshq.com/building-a-reproducible-ci-system-for...
- There's a corollary to that question: why would China choose not to block Mullvad? We know every large nation with a capable online force maintains a fleet of ORBs, so maybe they consider Mullvad more useful for them as a functioning system?
Some of their own contractors may well depend on Mullvad. Perhaps as long as the overall "civilian" volume and user count remains acceptably low, the cost-benefit estimate may well be in favour of letting it slip by. (And for the civilians that do use a working variant, subject their connections to fine-grained traffic analysis.)
- As someone who writes both Python and Go (and I've been using Python professionally since 2005), I remember that the scoping behaviour has changed.
Back in Python 2.1 days, there was no guarantee that a locally scoped variable would continue to exist past the end of the method. It was not guaranteed to vanish or go fully out of scope, but you could not rely on it being available afterwards. I remember this changing from 2.3 onwards (because we relied on the behaviour at work) - from that point onwards you could reliably "catch" and reuse a variable after the scope it was declared in had ended, and the runtime would ensure that the "second use" maintained the reference count correctly. GC did not get in the way or concurrently disappear the variable from underneath you anymore.
Then from 2008 onwards the same stability was extended to more complex data types. Again, I remember this from having work code give me headaches for yanking supposedly out-of-scope variable into thin air, and the only difference being a .1 version difference between the work laptop (where things worked as you'd expect) and the target SoC device (where they didn't).
- I think I've seen one or two, and only because I noticed them as a weird callout in a $LARGE_FINANCE_INSTITUTION infosec bingo sheet. Of course I had to check that they really were running with OV certs.
Some of the outfits in that space will be heavily hit by the shortening certificate max-lifetimes, and I do hope that the insurance companies at some point also stop demanding a cert rotation before 90 days to expiry. It's a weird feeling to redline a corporate insurance policy when their standard requirements are 15 years out of date.
- > The ads OpenAI wants to roll out would like be for free users
At first. The scream going through the hallways at HQ must be along the lines of: "Nonononono! Not yet!"
- VictoriaMetrics. The answer to the question "could I get Prometheus, but with ClickHouse architecture?"
- > 2 minutes for their automated alerts to fire is terrible
I take exception to that, to be honest. It's not desirable or ideal, but calling it "terrible" is a bit ... well, sorry to use the word ... entitled. For context, I have experience running a betting exchange. A system where it's common for a notable fraction of transactions in a medium-volume event to take place within a window of less than 30 seconds.
Vast majority of current monitoring systems are built on Prometheus. (Well okay, these days it's more likely something Prom-compatible but more reliable.) That implies collection via recurring scrapes. A supposedly "high" frequency online service monitoring system does a scrape every 30 seconds. Well known reliability engineering practices state that you need a minimum of two consecutive telemetry points to detect any given event - because we're talking about a distributed system and network is not a reliable transport. That in turn means that with near-perfect reliability the maximum time window before you can detect something failing is the time it takes to perform three scrapes: thing A might have failed a second after the last scrape, so two consecutive failures will show up only after a delay of just-a-hair-shy-of-three scraping cycle windows.
At Cloudflare's scale, I would not be surprised if they require three consecutive events to trigger an alert.
As for my history? The betting exchange monitoring was tuned to run scrapes at 10-second intervals. That still meant that the first an alert fired for something failing could have been effectively 30 seconds after the failures manifested.
Two minutes for something that does not run primarily financial transactions is a pretty decent alerting window.
- There may well be some "interesting" financial arrangements in place between the two. After all, Claude models are available in AWS Bedrock, which means Amazon are already physically operating them for other client uses.
- Individual and startup devs yes. Enterprise devs, less so.
The latter are locked in to whatever vendor(s) their corporate entity has subscribed to. In a perverse twist, this gives the approved[tm] vendors an incentive to add backend integrations to multiple different providers so that their actual end-users can - at least in theory - choose which models to use for their work.
- I suspect there is no decent "minimal" API. Once you get to tens of millions of objects in a given prefix, you need server side filtering logic. And to make it worse, you need multiple ways to do that.
For example, did you know that date filtering in S3 is based on string prefix matching against an ISO8601/RFC3339 style string representation? Want all objects created between 2024-01-01 and 2024-06-30? You'll need to construct six YYYY-MM prefixes (one per month) for datetime and add them as filter array elements.
As a result the service abbreviation is also incorrect these days. Originally the first S stood for "Simple". With all the additions they've had to bolt on, S2 would be far more appropriate a name.
- Probably closer to 2019. Maybe the optionality is a relatively new feature then.
- Elasticsearch comes to mind.[0]
The docs state that is query is in the URL parameters, that will be used.I remember that a few years back it wasn't as easy - you HAD to send the query in the GET requests body. (Or it could have been that I had a monster queries that didn't fit through the URL character limits.)
0: https://www.elastic.co/docs/api/doc/elasticsearch/operation/...
- Don't skimp on the power supply either. A dodgy PSU can torch all devices attached to it.
How do I know? I've had two drives and one MB fail in quick succession thanks to a silently failing power supply.
- The thing that's missing is the difference between a unsolicited external content (ie. pay-for-play stuff) and directly user-supplied content.
If you're doing editorial decisions, you should be treated like a syndicator. Yep, that means vetting the ads you show, paid propaganda that you accept to publish, and generally having legal and financial liability for the outcomes.
User-supplied content needs moderation too, but with them you have to apply different standards. Prefiltering what someone else can post on your platform makes you a censor. You have to do some to prevent your system from becoming a Nazi bar or an abuse demo reel, but beyond that the users themselves should be allowed to say what they want to see and in what order of preference. Section 230 needs to protect the latter.
The thing I would have liked to see long time ago is for the platforms / syndicators to have obligation to notify their users who have been subjected to any kind of influence operations. Whether that's political pestering, black propaganda or even out-and-out "classic" advertising campaign, should make no difference.
- As a Finnish citizen living in the UK, I also come from a culture where a national ID system exists. I would not trust the UK to do theirs sensibly.
Even the invoked name "Digital ID" makes it very clear that this system would rely on central databases. Only. In a country where the upcoming political parties are actively proposing stripping foreigners from their immigration status, it's pretty clear that all the parties learned at least one common message from the Windrush scandal: destroying documentation of immigrants was not the problem - leaving behind evidence of such action having happened was.
EDIT: the Finnish system at least sets up _some_ guard rails around how the data is used, and mandates a physical document that one can use as a proof when (not if) the central DB is down or going through Windrush 2.0 purge.
- Or as in my case, lighttpd, with all its CGI, user-input processing or dynamic execution modules not even loaded.
Makes for an attack surface that gets delightfully close to zero.
Incidentally, the voice call quality in the UK is also really crappy. Operators compress/downsample the audio stream to the very edge of recognisability, because investing in sufficient infrastructure to support higher bandwidths is expensive.