Stallman has done more to safeguard our freedoms than all the critics and corporations that are happy to exploit his work put together.
He’s also been extremely prescient and decades ahead of his time. He stood his ground against relentless attacks where so many others have sold out and betrayed whatever morals they thought they had.
It should become clear to everyone that reads his work that "management theorist" Stafford Beer
can best be characterized without any doubt whatsoever as a charlatan.
Cybernetics came out of the Macy conferences [0] and this is where one needs to go, in order to establish context. I also highly recommend Norbert Wiener's biography "Dark Hero of the Information Age" [1] as a good introduction to one of the greatest geniuses of this age, easily eclipsing Shannon and von Neumann.
Principia Cybernetica [2] is another good resource.
>It should become clear to everyone that reads his work that "management theorist" Stafford Beer can best be characterized without any doubt whatsoever as a charlatan.
Yep.
Over the years I've found a few litmus tests for that sort of thing. Unclear or incomplete explanations; intentional vagueness, weird formatting, "meta" anything, "new language", incomprehensible diagrams. One or two and you're Stephen Wolfram; three or more and you're completely full of shit. Beer's book somehow manages to hit every single one in just a single page. Incredible!
If you claim something grand but can't explain your point clearly, you are almost always full of shit. If Susskind can explain the combined work of centuries of geniuses in The Theoretical Minimum, then you can explain your bullshit in a paragraph.
I always saw VLC as subpar. A typical case of software that's just trying to copy what the pioneers do. As we all know, mediocrity it not antithetical to popularity, and VLC has become very popular indeed.
However, it never pushed the envelope in terms of codecs, features and performance and as a result was never at the forefront of opensource video playing: mplayer got the ball rolling with rapid breakthroughs including hardware acceleration (e.g. /dev/mga_vid) before standards such as xvideo even existed and that spirit of technical excellence has been passed on to Mpv which remains at the pinnacle.
> I always saw VLC as subpar. A typical case of software that's just trying to copy what the pioneers do.
What pioneer is/was VLC trying to copy? Media Player Classic? Windows Media Player? Before VLC, the ecosystem of video players was a mess, and if you came across a format you didn't already had installed codecs for, chances were you couldn't play that file. But VLC always could play it, no matter what file, as long as it said it was a video file.
> However, it never pushed the envelope in terms of codecs
VLC literally took over the world because you could install VLC and VLC only, and stop having to care about codecs at all, at the time at least. Maybe today it's different, because the ideas of VLC already spread, but at the time, things were different.
I personally use mpv most of the times today, but when I got started with computers and didn't understand as much as I do now, installing codecs to be able to view some video I just downloaded was a pretty confusing task. CCCP (Combined Community Codec Pack) for MPC helped a lot, but to even get to that point took some time.
Not that I'm aware of, nor can I find any sources talking about it. Maybe you're confusing it with DivX that did something like that (https://news.ycombinator.com/item?id=6409888)? Both were popular during the same timeframe, so not impossible you're confusing the two.
Folks who find this useful might also be interested in otel-profiling-agent [1] which Elastic recently opensourced and donated to OpenTelemetry. It's a low-overhead eBPF-based continuous profiler which, besides native code, can unwind stacks from other widely used runtimes (Hotspot, V8, Python, .NET, Ruby, Perl, PHP).
Wizards for me falls flat (kinda like "soul of a new machine" that's often recommended but which I found a complete waste of time) while the Dream Machine, Dealers of Lightning [1] and Norbert Wiener's biography [2] are all essential reading.
"The Soul of a New Machine" is not so much a foundational book but a snapshot of the computer industry and might be more interesting to someone who had no idea of the industry as I did when it was published in 1981. For me it was a fascinating glimpse into the tech industry that I would soon join, albeit in software not hardware.
Yeah. I think if I read Dream Machine first I would have enjoyed Wizards less. But some of the history was new to me which meant that I enjoyed Wizards for those aspects and then Dream Machine for the detailed look into why it happened.
What's of greater importance here is not this specific security issue, but the default configuration of MIME handling in Emacs which can turn any unexpected evaluation bug -which we are likely to see more of- into remote code execution. We've had a previous Org security issue in exactly the same vein [1] and the Emacs MIME defaults are still unsafe. Of course, one can change them (non-trivial and related documentation is extremely confusing, see [2] for a possible solution) but really Emacs should not come with these defaults.
The loss of on-by-default functionality such as Org fontification in email message buffers is in no way as important as being wide open to trivial remote code execution.
I don’t fully understand lisp nor emacs internals. Do you anticipate similar bugs would exist across different major and minor modes, or emacs by default?
E.g., is markdown-mode or python-mode likely to have similar bugs? What about web browser modes, or chat modes, etc?
I genuinely like emacs but I’m worried for a future where my client cannot be trusted to not evaluate random data it has in files.
These bugs can be described as the major or minor mode evaluating code that is provided as part of the buffer that the mode is being enabled for. The two semi-recent examples that come to mind include Org (which offers this code evaluation as a feature) and text/enriched (which allowed arbitrary Lisp evaluation through a non-standard extension). In both of these cases, the evaluation was -somewhat- intended and even documented, so these are not bugs in the traditional definition. They become security bugs when one takes into account the exposed attack surface / dynamic interaction with parts of Emacs automatically switching on the mode (e.g. through an email in Gnus) on 3rd party untrusted input.
I don't expect to see code evaluation on untrusted input as intended features in web browser or chat modes.
> I don't expect to see code evaluation on untrusted input as intended features in web browser
I'm not sure whether to laugh or cry at that. Suffice to say that ship has sailed all the way around the world several times, to the great detriment of everyone who isn't a advertising or other malware-development corporation.
But surely someone out there will make a code highlighter for EWW, and maybe that highlighter calls org-mode on some block and that ends up evaluating stuff etc.
But expected evaluation is a feature, and not everyone wants to inject a permissions system that gets in the way every time you open a document. Not everything is a web browser that needs to run arbitrary code from arbitrarily bad actors.
A warning and a prompt would largely be useless in this case anyway. As soon as you'd click the prompt, the evil code would run. What you'd need is an option set in your init file to allow code to execute on opening only if a particular piece of information known only to you is included in the file, like #+runcode: a19ihlkn01nf2n9882n4337974biskjf
Sure, I agree with that behavior assuming the user wants the security. If the user wants to disable it, they should be able to do so. It's awful to assume users can't make the decision for themselves.
To be clear, this bug is about arbitrary code execution on another machine as soon as a user on that machine opens an email with Emacs that has a malicious org atrachment. It is not about the user opening one of their own files and the user has no chance to preview the code before executing it. So it is a perfect remote takeover of any machine that happens to use a default Emacs for email.
Codewise I'd prefer a signaled error in elisp and something like your proposed magic/back-door as a handler you'd have to set up in user(-config) space.
As far as I can tell, Emacs prompts you every time it evaluates code when opening a file, and so does Org Babel. This can be turned off but you need to do it explicitly.
Emacs (besides the lowlevel internals such as the garbage collector, graphics toolkit and virtual machine) is written in Emacs Lisp which means that it's also fully programmable by the user, at runtime, without restarts/loss of state. Moreover, every aspect of Emacs is designed to facilitate runtime modification and live programming. This level of introspection goes beyond anything available today except some Smalltalk environments (which lose on practicality).
VSCode is just another editor with a constrained "API" that limits the modifications one can do. Emacs is clay that one can fully mold to one's own preferences so that it becomes an extension of one's mind.
> This level of introspection goes beyond anything available today except some Smalltalk environments (which lose on practicality).
GNU Emacs has a bunch of user-facing C code which can't be changed live.
Many Lisp systems (and also applications) provide runtime introspection&reflection&modification. See for example Interlisp ( https://interlisp.org ) which was already a full live programming environment with managed source code in the 70s.
It's nice to see Interlisp restored and widely available but it's not Emacs. More a curiosity than something practical and it's looking like it still belongs in the 70s.
There's also Genera (in many ways the best but unfortunately still not widely available), Lispworks (commercial, lacks the features/userbase of Emacs) and a vast number of niche Lisp-based/Smalltalk-based/Forth-based environments that don't come close to the practicality of Emacs.
For all intents and purposes, Emacs is the 'best' freely available and most used Lisp machine we have today, a direct manifestation of Licklider's "Man-Computer Symbiosis".
The recent additions of sqlite3 and native compilation (MPS-based garbage collection is in the works) have significantly expanded the set of problems one can solve. I love Common Lisp but I barely touch it these days, as I tend to reach for Emacs Lisp instead. That's solely down to the evolution and practicality of Emacs.
> More a curiosity than something practical and it's looking like it still belongs in the 70s.
Emacs also belongs to the 70s. The UI basics were from TECO Emacs, mid 70s and many are still there. Stuff like the "Meta" key which no longer exists, or the buffer metaphor.
EINE/ZWEI and Multics Emacs were also developed then. Again, the basic stuff is still in GNU Emacs. Cursor handling in GNU Emacs is like it was in the 70s.
> For all intents and purposes, Emacs is the 'best' freely available and most used Lisp machine we have today
I don't see GNU Emacs as a "Lisp Machine", it's a mostly text-ui based development platform & environment written in C+Lisp and its usage is at the same time limited by its oldish user interface. There is a lot of useful software written in it, but the actual broader use of GNU Emacs is limited to a very nerd-like group. I've used GNU Emacs to read/write mail (for example). But that was long ago. There is a limited appeal of the text-oriented UI, which also has a hard time to adapt to devices like phones or tablets.
> practicality of Emacs
The practicality of GNU Emacs is also limited, because its user interface would not reach larger groups of current users.
> but I barely touch it these days, as I tend to reach for Emacs Lisp instead
It's also funny that many people would like to move GNU Emacs Lisp more towards Common Lisp, but they are not allowed to do so... -> see the repeated discussions (since many many years) on the developer mailing list...
Loop works well, is widely used, also available in Emacs Lisp and comes with zero dependencies. For these reasons, I don't see this gaining much traction.
Anecdote: In almost 20 years of CL usage, I've never needed an extensible iteration construct. I also find 'loop' a lot more readable than 'iterate' [1], another fad that has come and gone.
TIL that there is a whole package for “Common Lisp Emulation”[1] in Emacs that adds functions and control structures from CL “to make Emacs Lisp programming significantly more convenient”. Never developed a package for Emacs myself, but I feel like this can be of great help if I ever wanted to.
I know that there are projects like Lem[2] that try to build some kind of editor (Emacs-like, I guess) on top of CL, which made me wonder if we would have a CL-based Emacs today if it would have been standardized by the time and if this would have been a better choice than creating a custom dialect.
It's the command set (key bindings, extended commands, ...), buffers with modes and minor modes, the user interface for buffers, marks, the "cursor", extensibility, ...
For example in a typical Emacs the "cursor" / current mark is always visible, even in GUI versions. This is very different from other editors, where the current cursor can be non visible.
Basically there are a lot of similarities between the early Emacs editors (EMACS, EINE/ZWEI/ZMACS, Multics Emacs, ... and others).
Does LEM try to be similar to an EMACS editor or is it only emulating one on demand?
GNU Emacs use might also think of Emacs Lisp as an extension language, a GUI version, menubars with menus, self-documentation, ...
Theological questions. The reality is that one "knows an emacs when one sees it." And lem behaves like GNU Emacs in some fundamental respects. Default keybindings, buffer management, macros, etc. Even newer things like lsp support + modes, etc.
It is not clear to me why the marketing for lem is "a Lisp IDE" when it clearly is "an emacs written in Common Lisp"
In what sense is iterate a fad that was gone? I see 1161 systems in Quicklisp (out of 5499 total) that transitively depend on iterate; so about a fifth of the open-source ecosystem.
Transitive dependencies are a poor indicator of actual utilization. How many direct dependencies are there?
For what it's worth, I quit using it since it broke if you ever used the CL function `count` inside an iterate construct. Reportedly it was fixed, but it's still failing to work correctly using the Quicklisp version (just installed CL on and setup QL since it's a new laptop, so it shouldn't be pulling an old version). It was fun for a while, but having to remember "Oh yeah, don't use count" every time I reached for it for something natural was annoying and not worth bothering with.
I find iterate much better on the other hand. Especially the part where I don't have to use :do to switch back to CL syntax and I can use the usual nested if else without having to remember the :end/:then stuff.
He’s also been extremely prescient and decades ahead of his time. He stood his ground against relentless attacks where so many others have sold out and betrayed whatever morals they thought they had.