> While this is sort of laughable out of context (I mean, Steam on Linux for the last few years has run basically everything with full acceleration)...
Eh. It's sort of like saying FreeDOS is laughable because DOSBox exists. I think that's missing the point.
It's difficult to do that because we don't even really know how many cancers there are.
Cancer is best understood as a family of tens of thousands of diseases. They're a whole range of different genetic changes that can happen which result in similar categories of symptoms and consequences. They can also be incredibly complex, such as being the result of hundreds of stacking genetic defects acquired over a lifetime. There can be a thousand varieties of one specific type of lung cancer, and they might all react differently. Some of our solutions might work on a lot of them, but others might only work on a handful. And we're at the beginning of figuring all this out.
CRISPR may eventually allow us to genetically profile a cancer and design highly targeted medications to cure them, but we don't know yet how well it will work. It may only work on a portion of them. It may have worse outcomes than chemotherapy or radiation. It's nice to think that we're going to find a magic solution to the entire problem, but things almost never work that way. I think we're going to be able to resolve a wide range of issues, but I don't think it will really cure cancer as a whole.
If a security bug is exploited in the wild, it's an n-day if it's been first exploited n days after the publication of the bug, and a zero-day if it's been exploited before or on the day of the publication.
When a bug is not yet exploited in the wild, it's just a discovery of a bug, not a zero-day.
Originally a zero-day exploit was one that was found by crackers on the first day of release of a software product. Like finding a licence crack for a new Microsoft program on the day it went on sale.
There used to be fierce competition to find such an exploit within those 24 hours, and great kudos for those who did.
Nowadays a zero-day can apparently be found years after release, which makes no sense.
Does "publication" refer to the software or to something documenting the existence of the bug? Because I thought zero-day meant the bug was exploited the same day the software containing the bug was released, but your phrasing sounds like if you exploit a bug before the maintainers know about it then it's a negative day.
I did so in the other reply thread of the comment you replied to.
> [Z]ero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.
And, again, you need to be aware that the vulnerability is the flaw or defect in the software or system (e.g., buffer overrun), and the exploit is the specific methodology that takes advantage of it (e.g., worm, malicious web request from a botnet, etc.).
Some people differentiate between a zero day vulnerability and a zero day exploit. I don't really find that is common anymore, and essentially everyone using it means zero-day exploit.
I understand why it's poorly understood. It's a snappy term, and people assume it means "bad" and nothing else because that's all you can get from the context. However, since most people also don't know the difference between a vulnerability and an exploit, they won't understand the definition of a zero-day when they read it.
But I'm still going to complain if a security vulnerability research company is using the term incorrectly in their own press copy. It makes them look amateurish.
No, that's the difference between exploit (knife) and either the incident or impact (wound). The vulnerability would be a gap in armor.
The vulnerability is the exposed weakness. Vulnerabilities get fixes, and they exist without anybody knowing about them. Vulnerabilities get CVEs assigned to them.
The exploit is the means of attack. It's the specific actions or calls that let you take advantage of a vulnerability. It could be a worm, or botnet scripts, or specifically crafted data[0]. A proof of concept is not an exploit itself, but it demonstrates that the vulnerability can be exploited.
An example of a vulnerability might be a gate where the gap between the door and the jam are too wide. The exploit is a coat hanger used to lift the inside latch from outside the gate. That results in unprivileged access.
And zero-day specifically compares when the white hats (vendors, system owners) and the black hats learn about the existence of a vulnerability. If white hats learn that a vulnerability exists by being subject to an in-the-wild black hat exploit of it, then it's a true zero-day.
That seems like it would be incredibly fragile. As soon as the receiving party made a change that required re-saving the PDF -- like commenting, highlighting, changing default layouts, saving as a PDF/a, checking PDF/ua, etc. -- it might erase the attached files.
It's also very easy to use pdftk to embed or attach files in a PDF using the methods defined in the PDF standard. No renaming or special knowledge required of the audience.
The planner breaking on updates is common for almost all RDBMSs. They introduce optimizations that work great for 95% of customers, and some will just have queries that now act like cardinality is way off or covering indexes are missing.
This issue was one of AWS's listed reasons for tending to prefer NoSQL style databases over "more performant" RDBMS, because of the more consistent worst-case performance, even if the result is worse average-case performance, which was important in their assumptions for scalability planning.
Not just television. Also the supermarket checkout aisle magazines. Not just tabloids, although that, too. Also the "glossy" magazines. Vogue, People, Us, Cosmopolitan, Vanity Fair, McCall's, Seventeen, etc.
The commercialization of the engines of culture continues.
The last I knew, EDS and HSD are mutually exclusive. HSD is typically diagnosed because you have hypermobile joints, fatigue, brain fog, POTS, and other symptoms, but you lack the very specific genetic markers that hypermobile EDS requires.
The real problem is twofold. One is that EDS had historically been a diagnosis of exclusion, and a lot of the diagnostic tests were difficult. The second is that the disorders overwhelmingly affect women, and women tend to get ignored about chronic pain and fatigue.
No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless.
Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.
Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.
printf("Hello world!");
also does not tell anything to the system about how to accomplish this.
Anyone who claims that an SQL command like insert a row, create a table or destroy a table is not imperative, is just plainly wrong.
Even in real life, when humans communicate commands to each other, from where the term "imperative" comes, the commands normally do not tell anything to the recipient about how to accomplish the order, they just name the action, because it is supposed that whoever receives the command knows how to do it.
After programming languages were invented there was a clear partition between commands a.k.a. imperative statements, expressions and definitions a.k.a. declarations ("definition" and "declaration" were originally synonymous terms, "declaration" being the ALGOL 60 term and "definition" being the CPL term; the use of the 2 words with different meanings, like in C, where it is required by a defect of the compiler, which needs additional declarations besides a definition, is only recent.)
Later the meanings of these terms have become muddled by their careless use by many authors, which usually had political reasons, i.e. because they somehow considered the words "imperative" or "command" as shameful, they attempted to present their pet languages as purely functional or purely declarative, so they twisted the words in various ways, despite the fact that any practical program must contain imperative parts, not only functional or declarative parts.
> Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.
No. That's more to do with imperative vs functional programming, which is a subset of declarative, but even then you can't simply say "I changed state so it's imperative." That's a drastic oversimplification. That's like saying Haskell can't write to a file, which is plainly false. Declarative (functional) can absolutely change the state of the system. It just doesn't let you do it except by calling fixed commands, which is exactly what `INSERT` is.
When we're talking about imperative vs declarative, state can still be manipulated in both, but it's abstracted away with declarative programming. Like, a `filter()` or a `map()` transform in JavaScript is declarative programming, even in an otherwise imperative language. That's why it returns a new object with an updated state.
This just exposes how weak this definition of declarative is, I think. Or how it's carrying two meanings here.
What you're really talking about is one of the things Codd wanted to emphasize: representational independence. Which actually was the primary thrust of his famous paper: the user should not need to know how the data is stored in order to use or manipulate it.
The other thing that people are talking about with "declarative" is probably another level up in abstraction. Talking about the business logic or problem in terms that are closer to logic than a sequence of instructions, and then letting the machine sort out what those steps are.
Consider in a Datalog users don't customarily perform DDL type operations; they declare data rules and the system decides the form of the underlying relations. That's a small step up the declarative ladder from SQL, even if it's somewhat analogous to "create view".
So I think there's a blurry definitional line between the two. But I don't think your very blunt "No." is doing much to help clear that up?
I would say it exposes how imperative programming was forced to adopt declarative/functional paradigms in order to write things concisely, to the extent that nobody thinks those elements are declarative/functional anymore.
C#,C++, Java seems imperative. You are in control? But you aren't really telling it how to move values between registers, the compiler is making a million decisions for you on how the computer will execute that 'imperative' code. Just like SQL isn't really telling the DB how to do it either..
It's really a matter of degrees though. You're waving away a big part of the big sell of a relational database as proposed by Codd, which is that the user need not "know" the structure of the data in order to formulate operations on it because there's a consistent set-oriented model that can be used with a bunch of different physical storage forms but also the very sequence of relational operations against it can be re-ordered / restructured without the user knowing. And that the same data can be accessed in N number of ways that don't require changing the underlying storage. In theory. In practice SQL databases are only sort-of there.
Contrast that if I create a class/object/field structure/hierarchy in Java, or put a HashMap somewhere with a certain set of keys, I've written something in stone which requires significant refactoring if the data needs to be accessed from a different direction.
Imperative languages such as C/C++ specify "microtransactions" - an ordering over memory accesses (including (de)allocations) within some statement or group of statements.
Compilers are free to rearrange these accesses if the final result is same as if executed by these ordered microtransactions.
On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
Eh. It's sort of like saying FreeDOS is laughable because DOSBox exists. I think that's missing the point.
reply