Wow, I had forgot that Rin Tin Tin is something I can recall from my childhood. I'm not even sure I remember how I know about him, other than hearing the name and seeing random bits of media (maybe even stuff in advertisements or posters). Maybe one of the shows or movies was still played in the 80s when I was a young child, or perhaps the 80's were soon enough after some of the popularity in the 60's that it was still in the public consciousness, and the turnover cycle of pop culture wasn't as aggressively fast.
There are also some pathological bad use cases out there that are caused by the combination of trying to scrape all the content, a randomized param, and the scrapers trying to be anonymous. The one I've encountered is pbpBB.
phpBB will assign you a randomized session if if you visit it anonymously (without logging in), and will serve the page to you with that sid param added to all links. Using that link will load a page without the sid param appended to links, because the system assumes you have a session I'd saved in a cookie since it saw you have a sid, even I'd you don't have/didn't send a cookie with it. Following any of those links starts the chain over if you aren't sending a cookie along with a sid, which the AI scrapers never do so they can't easily be blocked by that, and a new unique sid is generated, and all the links have the new sid appended.
Every page with a unique set of params and values needs to be investigated, because it can be an entirely different page, so AI scrapers will scrap forever, always finding more and more URLs to harvest, even though they're all duplicates of what they already have. It's easy to have multiple scrapers stuck going through a very small bulletin board continuously.
Maybe they've gotten smart enough to deal with this situation in the last few months, or maybe they put in a specific workaround. I ended up just throwing the site behind cloudflare because spending time trying to outsmart AI agents in a battle of escalation doesn't seem like an effective use of my time.
The issue is that a dynamic site that can serve the traffic that generates 10MB of logs a week might be very performant on the smallest and cheapest of virtual servers, but one that generated a GB daily might find itself very slow and sometimes crashing because of load depending on spikes, unless they opt for a server with more resources, for more money.
Any answer to that along the lines of "do something more complex" or "optimize your site for load" to be able to deal with the rampant bad behavior of multi-billion dollar companies is unpalatable to most.
Pretty sure they're referring to their usage as a potential content consumer, not content creator. You don't need a cloudflare or AWS or any other service account (usually) to be an end user of a site that utilizes those. Increasingly it's hard to view any content on the social media platforms without an account.
What you want is something akin to a Raku (perl6) grammar, which was their enhancement to matching they developed to go beyond regular expressions.
grammar IniFile {
token key { \w+ }
token value { <-[\n;]>+ }
token pair { <key> \h* '=' \h* <value> \n+ }
token TOP { <pair>+ }
}
my $text = "user = alice\nrole = admin\n";
my $match = IniFile.parse($text);
if $match {
say "Parsed successfully!";
}
There are various libraries for other languages that try to accomplish something similar or Port the concept, so if this interests you, maybe you can find one. Or in this day and age, maybe you can have some VC (and much of society) subsidize the fairly quick creation of a library for you language of choice through AI.
If you're not looking for that, and more specifically what you have shown above, there are often ways to accomplish that in certain languages. In Perl it's easy because you can use regex cars in a regex, so you can just assign `my $digit = qr/(? :0-9)/;` and then use it in the regex as you did (and Perl already supports non matching whitespace with a flag). For that matter, Perl regexes allow you to define chunks purely within the regex to be reused in a DEFINE block, so possibly that is a feature other regex engines have as well.
Honestly, I still write a lot of perl, and while interpolation is nice and good to have for simple things, I find myself using sprintf more and more in production code, especially in the cases the examples always show off, such as needing to alter the variable, add two together, etc. I assume those are just shown to illustrate you you can do that, and not imply you should, because commonly using arbitrary code execution within interpolation is something I'd feel compelled to beat out of my coworkers if I encountered it regularly.
The point of (sane) string interpolation is that it runs at compile time, which helps prevent people from inventing crazy template systems at runtime. And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
> The point of (sane) string interpolation is that it runs at compile time, which helps prevent people from inventing crazy template systems at runtime.
It's the trivial cases that are compile time. The interesting templating is done with input that isn't defined within the source, and those can't be run entirely at compile time.
> And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
That's been solved for decades with parameterized queries (binding variables), and doesn't require interpolation in any way (at least not in the context we're using it here, but probably not at all in most DB drivers and engines). In fact, I would go so far as to say if someone is trying to use string interpolation instead of parameterized queries to avoid SQL injection, they've fundamentally misunderstood the problem and are trying to solve it at the wrong layer.
Also, if the string interpolation for the query is done at compile time, what type of content known at compile time is something that we'd be worried about SQL injection being in?
SQL parameter bindings solve only one part of the problem, that of putting variables into value positions. They don't solve the problem of putting variables into name positions (you cannot "SELECT FROM ?" or anything like it), and they certainly don't solve the problem of dynamic SQL. This is somewhat orthogonal to the topic at hand, but the mentality should be that the problem space is still quite open, with the existing solution being a starting point, not an ending point.
The "trivial" cases are also the cases people actually need like structured logging, sanitized HTML, and SQL.
SQL doesn't require interpolation, but it's much cleaner to write it that way and not have to explicitly do binding. It's not an "instead." Like I said, what the interpolator does is automatic safe binding with interpolation syntax.
The content known at compile time is the query template that you're binding. The point is a compile-time interpolator turns e.g. `sql"""select * from users where name=$name"""` into `Statement("select * from users where name=?").bind(name)`.
You can also have macro fragments as "inline def" functions in e.g. Scala so that they compose naturally. c.f. Quill[0].
There's actually a few ways it could have been meant, or it could have been meant to convey all of them. We all have a pretty good idea in the general sense what they meant, but that amusing reply is also an invitation for the person to elaborate and add nuance.
They probably do. Not all medical procedures have a greater than 50% expected chance of survival, but it still might be better than the alternative. That doesn't necessarily mean the anesthesiologist is the once responsible for the death, nor that anyone is, for that matter.
A cavity is just a hole or groove of various depth. It's probably less that one dentist sees a cavity and the other sees nothing and more that one dentist sees a cavity worth addressing the the other sees the beginning of a cavity that they figure will need to be addressed eventually, but there's not a major reason to do it now rather than next year or the year after that.
Also, I imagine some dentists might decide for their patients benefit (as long as there's no pain reported) to let a couple develop to a level is there's a few in various stages of development, so they can do them all at once with a single procedure.
I don't know how likely or accurate those are, but those are some of the obvious ways that came to mind that dentists might be seeing the same thing and suggesting different actions that don't boil down to them wanting to fleece a customer.
My dentist shows me the xray they take once every 5 years. Then they walk me through what a cavity would look like. Then they show me that i have none.
I can understand that the external "poke at it" method requires some judgment, but an xray shouldn't have that much variance.
That's why I also go get a "poke around and look" checkup every year. The X-ray is to spot deeper things, but you can't do that every year without the x-rays becoming a risk factor themselves.
In the United States, it is routine to get your mouth X-Ray’ed every 6 months when you go in for a cleaning. Dental plans include these checkups at no extra charge.
That's what I was led to believe by my dentist when I asked. I just checked danish national guidance, and they say the dose of x-rays is so low the increased risk is incalculable. Instead they say the dentist should only ever use an x-ray if they find it medically necessary out of a principle of minimization.
So it sounds like it's the individual dentists judgment, and their organizing body says that they base it on the occurrence of dental problems in the population the clinics they oversee, with some adjustments based on patient age and risk factors.
So according to Danish authorities, you should be safe getting x-ray'ed every 6 months. They just don't recommend it, since it's a waste.
Yet you are probably in the 90% of developers who cannot estimate properly.
I would like to have a professional judgement closer to how it's done in statics, instead of developers, since you fuck up lives directly with one, and usually not with the other one.
You've missed the point. It doesn't matter that you can rebuild the system exactly, the example in question had little to do with how accurate the restores were, it had to do with the time to reinstall.
I too can entirely rebuild many systems simple from kickstarting a new one and applying an ansible playbook. Do I want to? No, that's too slow, and I might be doing this operation for tens or hundreds of systems.
We have multiple levels of backups. We use veeam for VM and physical backups of the entire system to a disk store that's also shipped off-site to an immutable store, but we also run an older system based on rsync which rsyncs the system to directory on a server (sans some data directories) that uses snapshots to keep space usage minimal for the purpose.
In many cases, if we want to restore we can literally just rsync data back to the host, whether one or a few files or most of the system.
I can restore many types of failures within seconds or single digit minutes at most, and the time required is mostly unattended time. Time to restore is often an important and overlooked metric, until you've been bitten by it and realized that an hour or more of work from a person to restore something doesn't scale well in some scenarios, and those are often the most important ones.
But it's not actually slower. When NixOS loads you get a list of all previous states to chose from. Booting to any one of them is just as fast as booting to the most recent one.
Restoring some backup via copying bits around is much slower because you have to wait for those bits to copy, whereas booting to previous configs is just rejiggering references to bits which are already in place and need no manipulation.
Immutability buys you quite a lot here, although some up-front discipline is necessary to take advantage of it, which might be a dealbreaker for some.
That's useful if the system is still up and you can trust the state information, but when you have a disk failure, or there's enough system state corruption that you don't want to rely on that state tracking, you're then going to need something else.
Also, are you pinning your package versions in your config? For every single case of that, is the original package still available? Were they coming from remote sources which may not keep prior versions always available?
Did you build anything from scratch? Did you supply a source or binary archive to install from? Is that source still available, of the exact same version?
There are numerous things you need to worry about when rebuilding from what the state should be based on a description of that state (which may include arbitrary actions), as opposed to restoring from a recorded state that includes everything needed in the recorded data.
The more you can record the better. Should you also record nix configuration state and use that to restore when it makes sense? Sure! If it's simple and easy and doesn't use an inordinate amount of space, why wouldn't you? Just don't confuse nice to have with sufficient based on the specific requirements and goals your backup system needs to meet.
We have entire system images in an immutable remote store, but that's not what we go to first, it's what we go to when our quicker and easier systems are insufficient. If we were running NixOS, we'd probably keep everything we're doing now, and then also just add the NixOS state as a separate thing that's backed up and saved on every change (and in fact, along these lines, we also run etckeeper on every host and track all changes to /etc with daily commits if something is changes but also an automatic commit at the beginning and end of every ansible run we do that applies our host configuration).
More is better. If I want to see configuration changes, I can usually just look in etckeeper on the box, if I want to restore a tree to the exact state it was at a specific point that a backup was made through rsync, I can do that easily enough (or just navigate the directory tree on the backup server, if I just want to see what it was, or diff between different states at different times). If I need to restore the whole system image from a known good backup, I can use Veeam and the local repository for that. If the local repository is dead, I can use the replicated off-site repository. If an attacker has destroyed both those, I go to the immutable off-site backups, which I'm probably doing to use after rebuilding my backup infra from scratch to restore from. Each of these protects from slightly different scenarios, and offers different trade-offs for security and integrity and ease of use.
Sure, you may lose out of the "faster" part if you have to pull from a remote cache (both inputs and outputs) instead of your local one. And maybe just blindly relying on the community maintained caches isn't right for you, so now you're still in a position maintain a cache and back it up through traditional means. It's not a magic bullet, probably doesn't pay off for a lot of use cases.
But what it buys you is a sort of verifiability that you can't really get any other way. Anyone can build any part of the system from its declared inputs and say "hmm, I got a different hash than you, maybe something is up." If you're restoring from an image which somebody has tampered with, then the image becomes the source of truth, rather than the source code, and it gets a lot more difficult to scrutinize its validity because the pool of available scrutinizers is just the people who care about your particular image--that's likely to be a lot smaller than the set of people who care about whatever sources you're relying on.
I don't feel like this is responsive to what I said when taken as a whole. I obviously wasn't just advocating for something because it's faster.
...but, if your goal is really verifiable state, why don't you just use image mode linux with bootc, since it provides much of what you're looking for, except to a higher level. All your arguments for NixOS so far apply to that as well, but there's even more immutability and verifiability.
reply