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: 0) by Anonymous Coward on Thursday July 25 2019, @06:56PM (7 children)
Really, with musl libc, static linking is very attractive nowadays. However, there are quite a few large libraries that are required for major pieces of software that absolutely refuse to play nicely. AppImage/flatpak/containers/etc cgroup shenanigans all have big drawbacks WRT network/filesystem transparency and make it very easy to introduce privelege escalations unless you're very careful and knowledgeable.
(Score: 2) by DannyB on Thursday July 25 2019, @07:17PM (6 children)
There is an effort to build an Open JDK (eg, Java development kit) against musl libc. Actually I think Azul's Zulu offers one, or at least built for Alpine.
Java itself is a gigantical dependency of otherwise small applications that depend on it.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Thursday July 25 2019, @07:27PM (1 child)
Java is a work of the devil!
To be any good, you have to work in straight up binary. No abstractions mean no distractions. You cut to the chase. Do it right, and the kernel will fit on a floppy again, along with VLC, a browser, an email and bittorrent client, and will find cheap tickets to Vegas.
(Score: 4, Informative) by DannyB on Thursday July 25 2019, @07:34PM
That works. As long as development cost is no object.
However businesses are optimizing for dollars, not for bytes and cpu cycles. If I need an extra 64 GB of ram, but can beat my competitor to market, my manager won't even blink.
The lower I set my standards the more accomplishments I have.
(Score: 2) by c0lo on Friday July 26 2019, @05:09AM (3 children)
Now, tell me about Perl, Python, NodeJS and so many others.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by DannyB on Friday July 26 2019, @01:20PM (2 children)
Can Python, NodeJS, and God forbid Perl actually:
1. be as large of a download
2. be as large of an install
3. have the largest number of files on disk
4. have the biggest on disk pawprint
and most importantly
5. use as much memory . . .
. . . as Java ?
IMO, Java has them all beat.
The lower I set my standards the more accomplishments I have.
(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.