The US has a bunch of highly paid medics who fly every week or in some cases every day because they work somewhere with enough population to justify their practice but they choose to live somewhere hundreds of miles away, and at their income it's actually practical to have a small private jet. It's probably only a small minority of the most highly paid (so e.g. cosmetic surgeons) where this makes sense but it's more than a handful of people.
Likewise because it's big and a lot of it is empty the US does more medical flights than a country like the UK, if a Wyoming multi-millionaire needs urgent treatment in a Californian hospital you're not going to load him into a truck and drive there, you use a plane. This is relatively high risk commercial air travel, it's not quite as dangerous as most GA but there's some get-there-itis because you don't want to abort the flight and let down your patient, and you're often flying one-off journeys whereas the people doing scheduled passenger travel it's like a bus, same route, every time, regular as clockwork, and if things go wrong you just scratch the flight and no harm, no foul.
Sure, but of minimal practical impact. The Free and Open Source community has long discouraged releasing software into the public domain, as it has clear drawbacks compared to just using a permissive licence. The legal intricacies of the public domain vary between jurisdictions. Not all jurisdictions even allow copyrights to be surrendered in this way. [0]
Licence-free isn't a concern. That isn't even close to Free and Open source software, it's the opposite: software that you aren't permitted to acquire, use, modify, or distribute. [1][2]
This is exactly what GP was talking about: entrenching a preference for one style of licensing over another. We all know what set of licenses the FOSS zealots would prefer for us to release code under, and those who release license-free or public domain software anyway typically do it with full knowledge of such arguments.
> entrenching a preference for one style of licensing over another.
Sure, that's true. The intent of the law is to give a special carve-out for, in essence, Free and Open Source software. It seems clear that it was deliberately written so as not to include proprietary freeware, say.
> We all know what set of licenses the FOSS zealots would prefer for us to release code under, and those who release license-free or public domain software anyway typically do it with full knowledge of such arguments.
Like what? Really, it's very rare for code to be released into the public domain like this. I've never seen a compelling argument for doing so. If your intention is to make the code available to all, to do with as they wish, the legal reality is that the best way to achieve this is to release the software under a permissive licence, rather than releasing it to the public domain.
If the exemption really doesn't cover public domain software, that presumably means that, as the copyrights on Free and Open Source software eventually expire and they enter the public domain, they will no longer be exempt. Again though this isn't of practical concern.
edit Come to think of it, publicly available software developed by the US federal government is released into the public domain, right? There doesn't seem to be much software like this though.
djb's software is the canonical example here: qmail, djbdns, etc. Widely used; distributed without explicit license until 2007, and placed in the public domain thereafter. No legal disputes ever arose from this.
Of course Bernstein isn't about to file lawsuits against his users, given his motives, but (prior to the public domain dedication) he might have stood a chance in court if people were downloading and using his copyrighted software without a licence. Under modern copyright law, all rights are reserved 'by default' (at least in the US). I'm not sure if a case like that has ever ended up in court, but I can't imagine any corporate lawyer signing off on acquiring and using software in that fashion.
An absence of lawsuits is not the yardstick for success here anyway. It's possible the public domain dedication deterred adoption compared to using a permissive FOSS licence. Consider Google's caution about public domain software for instance [0]. It could also be possible for software to be adopted but, if tested in future, this could be found to be legally murky.
If your intention is to make the code available to all, to do with as they wish, there's no legitimate reason to release it to the public domain rather than just using a permissive licence. If anyone with a deep knowledge of copyright law disagrees on this point, I'd be interested if you could post a link.
I'm not clear if you're doubting the correctness of what I said in my previous comment. I'm not making this stuff up, I already gave sources. The Creative Commons CC0 licence was created purely to address the legal complexities of the public domain. [1][2] (For other reasons of legal nuance, Creative Commons licences should not be used for software works, [3] but the point stands.)
> I'm not clear if you're doubting the correctness of what I said in my previous comment.
I don't dispute any of the factual or legal claims you've made. I even agree that a FOSS license is probably the best choice if the author's goal is to protect the user from the scenario where they turn evil and renege on their gift of code to the public.
In situations where I'm the author, this isn't always my goal. You know that Bernstein isn't going to go after his users, and I know that I'm not going to go after mine. Most users aren't going to be concerned about this possibility, either. Those who are concerned about it are likely to be for-profit corporations or their lawyers, and I'm not losing any sleep over making them nervous or losing them as users. I don't care to over-formalize things by invoking or even acknowledging IP law in my act of publication.
Each author's motives and goals are going to vary. It's not reasonable to enforce that "maximize assurances provided to user" is always at the top of the list for everyone.
If it's possible for program execution with some particular input to lead to a divide-by-zero, that's a bug, especially if the program is expected to be able to handle malformed inputs, or perhaps even deliberately malicious ones. It's not trivial to determine whether a program does this correctly. If it was, program analysis would be easy.
Division can 'go wrong' for certain inputs, but it's not just division. In C, signed integer addition, subtraction, and multiplication, all give undefined behaviour on overflow.
As 'Someone' already pointed out, it's not helpful to just flag all uses of the division operator, or of other potentially dangerous operators. Minimising false positives is one of the core challenges of program analysis.
There's more to it than that though. Defects in JIT logic can lead to nasty low-level bugs. Plain old interpreters, especially if written in a safe language, are unlikely to have similar issues. This is important when the input code is untrusted. JIT bugs are a major source of browser vulnerabilities.
JITs are an attack surface in that process. They are still restricted to things that process was already allowed to do, no matter how badly implemented the JIT is.
In this example usage, one would hope that authentication already happened before the JIT processed the command. So an authorized user can attack themselves is the only realistic risk, which is hardly significant
There's plenty of scope for harm just within the process, even ignoring the possibility of escaping the process. In the case of a database server, essentially everything of value takes place within the database process (or processes). That process presumably has both access to the raw database data, and network access. We wouldn't want it sending data to an attacker's server.
> one would hope that authentication already happened before the JIT processed the command
We'd hope, yes, but SQL injection issues are still somewhat common. Also, an organisation might trust their DBMS to enforce permissions, and a JIT bug is the kind of thing that might allow non-permissioned data access. A DBMS should be hardened against malicious queries, just as a browser should be hardened against malicious JavaScript.
In web browsers, the numbers show JIT compilers are a major cause of security issues. I don't know if there are hard numbers on JIT engines causing security issues in DBMSs though.
> There's plenty of scope for harm just within the process,
Of course, but the process has every right to decide for itself if it wants to take that risk. Just like it decides if it wants to take the risk of a memory unsafe language, forgoing fuzzing, or going all out with formal verification.
Reminds me of the 2024 blog post Look ma, I wrote a new JIT compiler for PostgreSQL [0]. Both articles lament that Postgres's LLVM-based JIT [1] takes a while to generate code.
> The rarity of JIT compilers makes me believe that implementing a JIT compiler historically was too difficult for it to be worthwhile.
That's only true of writing a JIT from scratch. There's no rarity of JITs, it's just that LLVM (and other frameworks) are often used. Every major interpreter has a JIT compiler. PCRE2 has a JIT compiler. There are JIT frameworks out there with much faster code-generation than LLVM: Cranelift, GNU Lightning, Mir. I doubt they could do code-generation faster than a custom copy-and-patch JIT, but they'd be much faster than LLVM.
Not sure where the idea comes from that Cranelift is much faster than LLVM -O0, at least in our experiments in 2024 it wasn't, see [1] Fig. 6.
Template-based code generators suffer from bad code quality due to missing register allocation.
Our TPDE-based compilers compile a bit slower than template-based code generation but the generated code is much smaller and faster ([2] Fig. 2). Also for database workloads ([2] Fig. 6).
All that said, Postgres' main limitation is that it (IIRC) only compiles single expressions from operators, not pipelines. This fundamentally limits the achievable performance improvement compared to databases that perform more extensive query compilation.
Always good to have proper researchers in the thread.
> Not sure where the idea comes from that Cranelift is much faster than LLVM -O0
Cranelift describes itself as a fast, secure, relatively simple and innovative compiler backend. [0] Interesting that LLVM can compete there, with its optimisations dialed down.
> Postgres' main limitation is that it (IIRC) only compiles single expressions from operators, not pipelines. This fundamentally limits the achievable performance improvement compared to databases that perform more extensive query compilation.
That sounds pretty limiting. That's separate from query optimisation though, right? The query optimiser is presumably able to reason 'broadly' and not just at the level of individual expressions? High-level query-plan optimisation must be much more consequential than effective use of JIT compilation.
> That's separate from query optimisation though, right? The query optimiser is presumably able to reason 'broadly' and not just at the level of individual expressions? High-level query-plan optimisation must be much more consequential than effective use of JIT compilation.
Yes, yes, and yes. For databases, query optimization (esp. join ordering for larger queries, which heavily depends on estimates) is fundamental. Query optimization happens at the level of the query plan, JIT compilation is only relevant afterwards. A bad query plan leads to asymptotically worse performance (e.g., bad join ordering with huge intermediate results).
On query plan execution: The "classical" model as used in e.g. Postgres is a pull-based iterator model, where operators implement a next() method yielding the next tuple and in there recursively call next() on their child operators (e.g., a next() of a select operator calls next() on its child operator, then applies the predicate [what Postgres JIT-compiles], and returns the tuple if the predicate was true). This can happen one tuple at a time (Postgres) or "vectorized" where multiple tuples are processed at once (e.g. DuckDB). A query-compiling database will split the tree into pipelines and compile each pipeline as one function (e.g., a pipeline will iterate over all the tuples from a source (e.g. tablescan) and a select operator then becomes an if statement inside that loop). This results in pretty tight loops, avoids per-tuple dispatch overhead, and enables more optimizations inside the JIT-ted code (e.g., tuple values don't need to be reloaded from memory all the time). (I find the original paper on query compilation [1] to be well readable.)
Thanks, sljit looks somewhat similar to GNU lightning.
On reflection I wonder if I overstated the widespread use of JIT and of JIT compiler frameworks. All the 'major' well-resourced high-profile JIT-based interpreters I can think of don't use an off-the-shelf JIT framework for their backend, which makes sense as they want to carefully tune the code-generation. OpenJDK, OpenJ9, .Net, V8, SpiderMonkey, JavaScriptCore. LuaJIT and Python's new JIT don't use one either, nor does the Linux kernel's BPF engine.
The Guile Scheme interpreter uses a fork of the GNU Lightning JIT library. [0] Julia and (as mentioned) Postgres use LLVM for their JITs. I'm trying to think of other projects that use a JIT framework/library.
Similarly, I can't think of many problem domains where it makes sense to use JIT. The ones that spring to mind are interpreters (of course), regex engines, and DBMSs. JIT can also help in high-performance computing, to tailor the code to the particular problem and the particular CPU. [1] I don't think there are many other contexts where it makes sense to use JIT though.
JIT compilation brings its own drawbacks in portability (both between hardware platforms and operating systems), complexity, and perhaps cybersecurity, which might also limit its adoption, even if a good JIT framework could help with all three.
I think that the "manual JIT compilation" that Common Lisp provide is the most practical compromise here. Sure, you don't have the automated switching between bytecode execution and progressively optimized compilation and you need to manually track runtime typing information to feed to the compiler, but the machinery is so much simpler and builtin!
Interesting, thanks for the link. LLVM isn't the only game in town though, nobody using it (or libgccjit) for JIT should be surprised to see relatively long compile times. I wonder if the postgres project will try a different backend.
There's a strong 'diminishing returns' effect in striking a balance between compile time and the performance of the generated code. I'd expect a more lightweight (less optimising) JIT engine to be able to produce code with pretty respectable performance while taking only a fraction of the time that LLVM takes. There's a follow-up to the blog post I linked above, which bears this out. [0] (I don't know if that JIT solution is production-ready or viable for merging into postgres, mind.)
The blog post [0] gives this performance comparison:
> So, on our stupid benchmark, doing 10 times a simple SELECT * FROM demo WHERE a = 42 on a 10 million rows table...
The tldr is you really can't copyright raw surveillance video, but you can apparently lightly edit to turn it into a creative work that is copyrightable.
> The tldr is you really can't copyright raw surveillance video, but you can apparently lightly edit to turn it into a creative work that is copyrightable.
The article doesn't say that, it doesn't speak to CCTV surveillance footage. It discusses rare cases like cameras falling from aircraft, or animals pressing the button to take a photo.
I can see your line of reasoning about there being zero creative input in the video's creation, but if surveillance footage isn't subject to copyright, I'd expect there to be plenty written about it.
The people up thread who replied to my original message give some other references for why this is the case. I agree with you that it is very surprising that it works this way, that this is considered a settled legal decision.
From the techdirt piece, seen above:
"To license out copyright, there must be creative contribution. This can arise from cutting/editing the video in a creative manner. Since there is no other prevailing copyright, the editing then makes you sole copyright owner entitled to all proceeds.
You may feel inclined to call bullshit on this, but it’s actually the ongoing revenue model for "revised" editions of Beethoven, Bach and older."
> The people up thread who replied to my original message give some other references for why this is the case
I'm afraid I'm not seeing it. Which comments specifically? Please link directly, rather than describing them.
> From the techdirt piece, seen above: [...]
My question was specifically about surveillance footage. The law doesn't work on perfect logical consistency, we can't infer an ironclad answer where there's no explicit law or legal precedent.
Another web search turned up a reddit discussion [0] which says that in the case of US law it's unclear, but that under UK law it explicitly is subject to copyright, under a special non-creative films category.
For what it's worth Ada currently has RFCs for constructors in destructors closer to the C++ way. They're currently supported in the GNAT (GCC Ada) compiler.
I'm not sure about that definition. If your software solves a problem that many users face, that makes it useful and, presumably, valuable, but it doesn't mean it's of higher quality than niche software of relatively little use.
OP didn’t say “little-used” software, they said “nobody,” and I think this was meant to be taken literally in this context. Software that has 0 users is of no use to anyone by definition.
If you are using quality as a metric then something having more quality would mean it having more value to more people. So a piece of software working 95% of the time to 1 mil users is deemed "of higher quality" by this metric than a piece of software working 100% of the time to 1k users. I don't think this definition for quality is good at all
You’re still missing the point: software used by LITERALLY 0 PEOPLE cannot be useful. Whether it’s well written is completely irrelevant because it, by definition, is providing value to NOBODY.
Agreed. The quality of a software package doesn't change when its last user stops using it. We don't say that the Apollo Guidance Computer software is of low quality these days given that nobody's using it.
Software quality is, roughly speaking, intrinsic to a software product. Its usefulness is not intrinsic, it can depend on any number of external factors. Quality is not the same as usefulness.
But if it’s unused then how does one measure quality? We can write all the tests, look at architecture patterns, etc. but software truly is a case of “the proof of the pudding is in the eating.”
But that’s not my argument at all. I’m saying that quality is impossible to measure if 0 people use it. Once you go above 0, it can be measured and it’s not necessarily related to how many people use it.
It is still possible to measure the quality of software (or other products) simply by defining a metric that proves quality and testing for it
If I were to write 2 simple functions that reverse an array, and one successfully reverses an array and the other just randomizes it - despite never using this function, we could all agree that function 1 is of higher quality than function 2.
This is an extreme example but the same can be done for, lets say, speed or error handling.
While I think the example is too fake as to be too useful, let's take it. While we could read the code and say that one appears to achieve the job we want and the other doesn't; you don't know if the one that apparently does the job actually does the job until you put it into real-world use. You can't know it'll run with acceptable speed, edge-cases, etc. until you actually run the code in production!
If that code never goes into production with real customer use-cases, everything we say about its quality (on any metric) is 100% theoretical! We can try to replicate that environment, and we should, but until it's actually used, we can't truly know.
I think readability is very important for quality. It creates resilience against any hardship that requires changing the code, which is probably most hardships.
reply