SoylentNews is people
SoylentNews
Alleged critical VLC flaw is nothing to worry about -- and is nothing to do with VLC
There has been a degree of confusion over the last few days after news spread of a supposed vulnerability in the media player VLC. Despite being labelled by security experts as "critical", VLC's developers, VideoLAN, denied there was a problem at all.
And they were right. While there is a vulnerability, it was in a third-party library, not VLC itself. On top of this, it is nowhere near as severe as first suggested. Oh -- and it was fixed over a year ago. An older version of Ubuntu Linux was to blame for the confusion.
The problem actually exists in a third-party library called libebml, and the issue was addressed some time ago. The upshot is that if you have updated VLC within the last year, there is no risk whatsoever. VLC's developers are understandably upset at the suggestion that their software was insecure.
Also at Tom's Hardware, Boing Boing, and The Register.
(Score: 2) by c0lo on Friday July 26 2019, @02:03PM (1 child)
Really? I just don't feel this is something so totally out of proportion, would you mind checking it again?
Excluding the docos (docs and man) and legals, here's what my java-11 installation looks like:
364 MB in 158 files.
----
Now, let me try the nodejs installation:
69 MB in 3620 files
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by DannyB on Friday July 26 2019, @03:04PM
Thank you! That is very interesting.
Java runtime: fewer but larger files.
NodeJS: many smaller files
I suspect NodeJS cannot compete with Java on performance.
The Java runtime runs java bytecode. It starts out interpreted. Continuous dynamic profiling identifies functions using disproportionate cpu. Those are immediately compiled to native code by the C1 compiler, and put on a list to soon be recompiled by the C2 compiler. C1 quickly compiles simple code. C2 spends time generating highly optimized code.
C2 aggressively inlines code. C2 has a 'global view' of the entire running application unlike an ahead of time compiler, such as C, or Golang, etc.
If a class is dynamically reloaded during runtime, causing some aggressively inlined code to become stale, then those functions are de-optimized back to being byte code interpreted again. If they still use disproportionate cpu they will get compiled again by C1 then C2.
I was just reading about Vectorised Byte Operations in C2 [github.io].
C2 is also able to use instructions specific to your actual processor model. Unlike an ahead of time compiler.
The lower I set my standards the more accomplishments I have.