I meant "spare" in English. English "spare" and german "sparen" have same roots and related meaning. To spare versus to save. Just wanted to point out the translation attempt of data-spare-some-ness is not unreasonable.
The saddest part of this story is that Netflix/Amazon/younameit will continue to ignore and block Linux users as the niche market they are -- even if a future Firefox or Chrome version comes with the new standardized DRM everyone asked for. Lose/lose situation.
Netflix works with EME on Chrome and Firefox. Netflix doesn't block Linux users. They just don't provide customer support for troubleshooting on Linux.
I think we're splitting hairs here. The point cpeterso was trying to make is that while Netflix is a large company that advocated for EME, Netflix is also trying to cater to all audiences. And with their track record of open-sourceing lot she of their internal systems, I feel it's safe to say Netflix as a company isn't nearly as corrupt as some of the other advocates for EME.
I wouldn't be so sure. As Netflix becomes a media giant (it's already bigger than many), they'll adopt their policy for DRM. If not, why don't you have less restrictions on "pure" Netflix Originals content ?
We'll see in the coming months if the Originals mean higher quality on Linux or not. I wouldn't bet on it.
Correct me if I'm wrong, but the new "standardized DRM" is just EME which all major browsers, including Firefox and Chrome, already implement, and which has been used by e.g. Netflix for several years now.
And Netflix works on Linux on Chrome and Firefox already, using those APIs.
The actual Content Decryption Modules are not part of the standard, though. Firefox and Chrome use Google Widevine.
For "simple economic reasons" you believe companies will go out of their way to block Linux users for some reason? If the browser supports it, that's all that really matters.
Given that a NSA dev team was well aware that the spyware would be discovered and disassembled at some point in time, it was reasonable to intentionally leave behind evidence that points to countries other than the US. I'm not saying that's what happened, but I'd not take the cricket references too serious either.
Using that logic, what would constitute evidence? That's like the senator in favor of the Japanese interment camps saying that the fact that no Japanese Americans had committed a crime was just even more evidence they were planning something.
But basically, people have already come to a conclusion. If the comments said "go <Virginia sports team>", that'd be considered evidence of made in the USA. And if the comments say " go English sports team " then that's evidence of have in the USA, because obviously comments are misleading.
Why not go recursive? They wrote about cricket because they wanted to frame the Americans, who always write misleading comments to frame the Brits.
Archaic and impractical. Example: Instead of using Linux' pragmatic approach to function prototypes:
"In function prototypes, include parameter names with their data types.
Although this is not required by the C language, it is preferred in Linux
because it is a simple way to add valuable information for the reader."
OpenBSD enforces this:
"Prototypes should not have variable names associated with the types; i.e.,
void function(int);
not:
void function(int a);"
Instead of letting the code tell the parameters' purposes, this now has to be deduced from informal descriptions, or the function definition in some .c file.
Replying with a CVE is like icing on the cake. :)
It really shows that OpenBSD devs take security seriously.
Funny timing, I was just reading Absolute OpenBSD.
The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT, and of course completely irrelevant because you can make that mistake regardless of what the header says.
Parameters in headers are just documentation, by definition. Documentation can be wrong however you write it, but in general it helps to have it instead of not. Would you seriously argue that function parameters should not be given names in documentation?
> The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT
Actually if you look at the patch to fix this issue, they swap the identifiers in the declarator. Of course when something like this happens, you're free to choose whether the definition or the callers should be changed.
That's the function definition, not its declaration. It's pre-ANSI C, so that semicolon can mislead. I didn't bother to grab the source to check whatever the header said (or, heh, didn't say, per OpenBSD convention), but I'm going to assume it was correct.
It amuses me greatly that we're sitting here arguing over the minutiae of coding standards when this thing is still written in K&R syntax.
But regardless: whatever the header said, it wouldn't have affected this bug, which was just a straightforward transpose thing between compatible types. People get memcpy() reversed all the time too, and frankly I don't know if I've ever looked at its function declaration in a header.
Hm. This is the kind of thing where a compiler warning could be useful. I took a quick look at gcc's manual, but it does not seem to have a warning for this particular mistake (argument names do not match between declaration and definition).
That way, you could repeat yourself safely, since the repetition would be checked by the compiler.
To allow the function definition to serve as the single source of truth. That would be my guess. They simply don't want to have to update the parameter name at N places, if a parameter were to be renamed.
I love how frequently people on HN decry actual real working things people actually work on and use as "impractical". I suspect the combined experience of the entire openbsd team is greater than yours.
"If you're interested in using any of this code in your applications, feel free to do so! You don't need to cite me or this website as a source, though I would appreciate it if you did. However, please don't plagiarize the code here by claiming authorship - that would just be dishonest. I also caution you that while I'm fairly confident that the code on this site is correct, I haven't mercilessly tested every line, and so there may be a lurking bug or two here."
C++'s template-based sorting mechanisms allow for the same optimization without manually special-casing anything. (The compiler "integrates everything", to quote the author, out of the box.) C++ port of Postgresql, anyone?
Only if you actually can special case it automatically during compilation. It could still require a few tricks if your comparison comes from a user-defined query. At a minimum it would have to be something like: figure out which column type are you using, figure out what basic type does it map to, use that type in the template.
PostgreSQL is extensible enough that runtime specialisation would be best, I think. A JIT compiler, or a compiled type-safe multi-stage[1] programming language like MetaOCaml, would give the best performance.
Nice. Please add more GCC versions (3.x and 4.0 through 4.3?) and the most recent clang/clang++ releases! Direct pastebin-style links would also be great.
