I think the intent is clear. We could just enumerate all strings in size and lexicographical order. Then the task is only to filter, which strings are programs we desire.
It's the same sentiment as "the typing itself is not the issue, it's the order of the button presses that's difficult."
Of course, by Rice's theorem, all interesting questions are undecidable anyway...
No it doesn't. But as a human being, you and everybody still deserves a decent living. And our current system clearly does not provide that for a lot of people.
How come is anyone "entitled" to a decent living? I don't think this holds evolutionary, nor from historical perspective. It is commendable for a person to want to think that everyone deserves it, but I don't see it follow from anything or manifest in general in a fair way. There are plenty of examples that people are very likely going to be deprived of even whatever they deserved by means of struggling to get it.
Sure it does. Our species is social, meaning we form societies for evolutionary success. Both of us being members of that society, it is in my interest to see your child survive. It is a tragedy to think your child may not survive because human greed prevents them from accessing resources we have in abundance.
The opposite perspective is anti-social in a literal way: the greedy cannot use all of the resources, can't eat all of the food; they want control so you can't have it without their permission. You are entitled to eat, seeing as we have more than enough to feed you. That others think you are not is disagreeable, to put it mildly.
Sorry, but history saw so little (as a fraction) of people that were actually getting fair living that others guaranteed for them. Even when it is about living in decent conditions provided by the community if you want.
Even in a tribe, there’s a lotta suffering and very little remorse for it.
We may say we chase a society that would see everyone understand the principle of ‘your child should also get a decent life’, but what we see now, across nearly all societies is really the opposite. And it phrases like this - we don’t care if your children live or die for as long as our children get better chances.
> Sorry, but history saw so little (as a fraction) of people that were actually getting fair living that others guaranteed for them.
This statement is rather plainly not true. It describes child rearing and claims it does not happen in one breath.
There is a concept of "fairness", which I don't want to discount, but there's not much of a history of people being bottom feeders who do nothing to help those around them. Sure, there's a lot of sentiment to that effect but it is somehow something I fail to observe to this day. It is in the eye of the beholder and I worry for the souls of the beholders who judge so harshly.
This idea that someone is not deserving of food because they have not earned it a sad, anti-social thing to believe, perpetuated by psychological attacks from those who have more than they could ever need. You and your children deserve to eat and disagreement with that statement says more about the one disagreeing than it does any other, regardless of the judgement inherent to the nature of the disagreement (really, because of it, I suppose).
Yeah once payback goes below subsistence[1] - even when it gets near it- things get unstable and extremely dangerous. Ancient people understood this very quickly and built up institutions to keep the baseline above subsistence for urban civilizations.
It's been so long since we've seen actual bread riots I fear we forgot how nasty those are.
I think the notion is that with new automated systems of violence and control, some of them built onto the people themselves, our "future civilization" can dial back the worker's compensation to below subsistence. There was a big zillionaire conference where they talked about slave collars, for example, or humanoid AI workers. I'm always a little distressed when the masters of industry fall back on science fiction in order to build a machine that needs to function in the, well, in the present.
It was a private 2017 desert retreat where five wealthy tech and hedge-fund investors flew out media theorist Douglas Rushkoff, ostensibly for a speaking engagement.
Rushkoff wrote it up first as a Guardian essay and later expanded it into his 2022 book Survival of the Richest: Escape Fantasies of the Tech Billionaires.
The problem's super duper obvious if you studied history, but it is also pretty obvious if you can think about second order effects. In collapse the wealthy obviously need security forces to hold on to their stuff, but in a collapse your stuff will - presto changeo - become the security force's stuff. Essentially the singular founding story of all European royal families. Barbarian general took the house, banged the wife, now he's king. Or King-Sound. Kai- Zar
At the end of the day all these little lords and lordettes figured out the time honored lesson that to be actually safe you want to make friends with the locals. And that's part of being new king types as well. But "making people like you" isn't a popular notion with the Revenge of the Nerds types who love this "Lord of the Bunker" kind of thing.
I've seen zoo chimpanzees make a mockery out of this sort of device in VERY short order, and I would dread to impose it on a Delta Force psychopath who also has more higher degrees than I do. Because he's going to know who it was who did it and have all sorts of ideas about what he's doing about that. So the basic premise is also idiotic.
Sorry, I was a little more snide than I usually am on HN, it's been a long day.
There will always be scarcity and inequality. The point is to minimize/mitigate their effects. Can't you make the same argument for justice? Why does everyone deserve justice? Isn't that just entitlement? What is the historical or evolutionary basis for justice?
Nature does not exhibit anything as entitlement to justice. The whole concept of divine intervention (that we would like to exist more often than we like to admit) rarely manifests as measurable and consequential principle in how evolution operates. And it operates on brutal training cycles with lotta loss…
So, yes, in order to have a society one perhaps and most likely needs to define how rights are guaranteed. But it does not mean anyone is entitled to it by definition. Otherwise millions of dying children throughout modern history, and now also, would see the perpetrators get a ‘fair’ treatment. But they don’t.
Perhaps only as second order effects that are hard to understand and are not entitlement.
So nature doesn't exhibit justice, but a society likely needs to implement it, yes? But you don't want to say who gets to receive those rights? Some might say that those millions of dying children is an injustice that we should try and prevent. In particular, the people whose lives are the most affected might want to have a word with you.
I'm not really sure how your reasoning here is in line with your previous post.
So? We produce enough food for 10 billion people every year, there's only 8 billion of us and a billion are hungry. Those seem like legible KPIs for shareholders (i.e. humanity) to pursue, no? And while World GDP is up, it's come at the expensive of the systems we depend on.
I want my son to live on a livable planet, and not under the constant threat of destitution. And I want that for all children, not just mine.
Depends on who & what you ask. Aggregates hide important nuance. For who? At what cost to who? Do the people who bare the cost have a say? Would they agree that it's worth it? What's their life worth?
No engine can be 100% perfect of course, the original comment is broadly accurate though. CodeQL builds a full semantic database including types and dataflow from source code, then runs queries against that. QL is fundamentally a logic programming language that is only concerned with the satisfiably of the given constraint.
If dataflow is not provably connected from source to sink, an alert is impossible. If a sanitization step interrupts the flow of potentially tainted data, the alert is similarly discarded.
The end-to-end precision of the detection depends on the queries executed, the models of the libraries used in the code (to e.g., recognize the correct sanitizers), and other parameters. All of this is customizable by users.
All that can be overwhelming though, so we aim to provide sane defaults. On GitHub, you can choose between a "Default" and "Extended" suite. Those are tuned for different levels of potential FN/FP based on the precision of the query and severity of the alert.
Severities are calculated based on the weaknesses the query covers, and the real CVE these have caused in prior disclosed vulnerabilities.
Sorry, I don’t understand the point you’re making. If CodeQL reports that you have a XSS vulnerability in your code, and its report includes the complete and specific code path that creates that vulnerability, how is Rice’s theorem applicable here? We’re not talking about decidability of some semantic property in the general case; we’re talking about a specific claim about specific code that is demonstrably true.
> We’re not talking about decidability of some semantic property in the general case; we’re talking about a specific claim about specific code
Is CodeQL special cased for your code? I very much doubt that. Then it must work in the general case. At that point decidability is impossible and at best either false positives or false negatives can be guaranteed to be absent, but not both (possibly neither of them!)
I don't doubt CodeQL claims can be demonstrably true, that's still coherent with Rice's theorem. However it does mean you'll have false negatives, that is cases where CodeQL reports no provable claim while your code is vulnerable to some issues.
OK, but all I said before was that CodeQL’s approach where it supplies a specific example to support a specific problem report is inherently resistant to false positives.
Clearly it is still possible to generate a false positive if, for example, CodeQL’s algorithm thinks it has found a path through the code where unsanitised user data can be used dangerously, but in fact there was a sanitisation step along the way that it didn’t recognise. This is the kind of situation where the theoretical result about not being able to determine whether a semantic property holds in all cases is felt in practical terms.
It still seems much less likely that an algorithm that needs to produce a specific demonstration of the problem it claims to have found will result in a false positive than the kind of naïve algorithms we were discussing before that are based on a generic look-up table of software+version=vulnerability without any attempt to determine whether there is actually a path to exploit that vulnerability in the real code.
Rice’s theorem applies to any non-trivial semantic property.
Looking at the docs, I’m not really sure CodeQL is semantic in the same sense as Rices theorem. It looks syntactic more than semantic.
Eg breaking Rices theorem would require it to detect that an application isn’t vulnerable if it contains the vulnerability but only in paths that are unreachable. Like
if request.params.limit > 1000:
throw error
# 1000 lines of code
if request.params.limit > 1000:
call_vulnerable_code()
I’m not at a PC right now, but I’d be curious if CodeQL thinks that’s vulnerable or not.
It’s probably demonstrably true that there is syntactically a path to the vulnerability, I’m a little dubious that it’s demonstrably true the code path is actually reachable without executing the code.
In light of that, I am wondering why the article opted to go for "However, determining the optimal join order is far from trivial.", when there are hard results in literature.
I was also missing mentioning "sideways information passing", though some of methods are exactly that.
I am wondering whether the company consults literature or whether they fiddle about, mostly reinventing the wheel.
While tedious, you can do the rewrite block-wise from the insertion point and only store a an additional block's worth of the rest (or twice as much as you inserted)
ABCDE, to insert 1 after C: store D, overwrite D with 1, store E, overwrite E with D, write E.
From TFA and AndyP's slides it seems to specifically refer to a variant of SSO where, for large strings, a fixed-sized prefix of the string is stored along-side the pointer, in the same location as that fixed-size prefix would be fore SSO strings. This means that strings lacking a common prefix can be quickly compared without pointer-chasing (or even knowing if they are small vs large).
I had a lot of contact with computer science students coming from the other side, meaning they used Z3 or other (SMT) solvers as blackboxes which they just use at a certain point in their algorithm without having thought what theories they are using (the T in SMT) and what's undecidable in general or in that theory.
So I had quite a few "groundbreaking" approaches end in disappointment.
It's important to know the capabilities and limits of your tools.
I'm not a rust or systems programmer but I think it meant that as an ABI or foreign function interface bitfields are not stable or not intuitive to use, as they can't be declared granularily enough.
C's bit-fields ABI isn't great either. In particular, the order of allocation of bit-fields within a unit and alignment of non-bit-field structure members are implementation defined (6.7.2.1). And bit-fields of types other than `_Bool`, `signed int` and `unsigned int` are extensions to the standard, so that somewhat limits what types can have bitfields.
I think core of the problem in property-based testing that the property/specification needs to be quite simple compared to the implementation.
I did some property-based testing in Haskell and in some cases the implementation was the specification verbatum. So what properties should I test?
It was clearer where my function should be symmetric in the arguments or that there is a neutral element, etc..
If the property is basically your specification which (as the language is very expressive) is your implementation then you're just going in circles.
Yeah, reimplementing the solution just to have something to check against is a bad idea.
I find that most tutorials talk about "properties of function `foo`", whereas I prefer to think about "how is function `foo` related to other functions". Those relationships can be expressed as code, by plugging outputs of one function into arguments of another, or by sequencing calls in a particular order, etc. and ultimately making assertions. However, there will usually be gaps; filling in those gaps is what a property's inputs are for.
Another good source of properties is trying to think of ways to change an expression/block which are irrelevant. For example, when we perform a deletion, any edits made beforehand should be irrelevant; boom, that's a property. If something would filter out negative values, then it's a property that sprinkling negative values all over the place has no effect. And so on.
It's the same sentiment as "the typing itself is not the issue, it's the order of the button presses that's difficult."
Of course, by Rice's theorem, all interesting questions are undecidable anyway...