It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated).
With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written.
Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it.
If you want to give back to Pharo in a way that counts, fund improvements to the UI. The font rendering is bad right now and HiDPI screens are not even supported. This makes for a terrible first impression.
Oh but it DOES mean that Rust has no value, at least regarding security. Once you give them the rope, they WILL use it. Let's see if time will prove me right.
Every language has a C FFI that users can use as rope to hang themselves with. `unsafe` code in Rust is just a reified FFI that actually manages to make Rust code safer because it means fewer things need to be written in C, and even unsafe Rust code is safer than C. Furthermore, the strict demarcation of `unsafe` blocks greatly alleviates the burden upon code auditors, allowing them to focus their efforts. Even if an extraordinarily high percentage of your code is contained within unsafe blocks, say 10%, that's ten times less code to audit than an equivalently-sized C codebase.
Unfortunately, this point of view has little merit.
Security is all or nothing. You can't have a little bit of this and a little bit of that. Unless the parts of the web browser that can be "influenced" by external attacker (directly or indirectly) are written 100% in a memory safe language, you simply have no real security but the illusion of such.
And this is how that hypothetical browser fails, and why it will never amount to anything re: security, since it's gonna end up using a gazillion of C libraries, all of them full of bugs and possibly vulnerable to security exploits.
One could say that Rust also fails by allowing "unsafe" code in its core design but it's still too early to see how that will play out.
Security is not all or nothing. You can definitely say that X is more secure than Y even if both have bugs, so long as X's bugs are less critical and less frequent.
As an example, I would happily claim that nginx is more secure than wordpress or the average php website written with mysql_query in the 90s. Does nginx have bugs? Probably somewhere in there. Are they as likely to be found, exploited, or (when exploited) lead to as serious issues? I doubt it.
Security is often about many many levels. A good example of this is Chrome, its sandboxing, operating system memory randomization, and user privileges. When someone finds a bug in v8, to turn it into root on the box requires bugs in all those layers (see writeups for pwn2own).
Generally, an improvement in security at any layer will reduce the impact of bugs at other layers. I'd absolutely rather have a browser written 20% in rust than 0% in rust.
An interesting observation would be for the author to start considering why this is true. Why does the "universe" give you what you seek? Why do you get from life exactly what you think you "deserve"? It seems strange, absurd, doesn't it? As if the whole thing is a circus, a movie being played just for you.
Now what happens if you simply do nothing? Nothing at all, no hopes, no aspirations, no worries, no dreams, no passions, just live in the present moment, forget about the past, forget about the future. Why keep chasing some illusion or other, trying to satisfy meaningless urges, illusionary needs that others have placed upon you? Open your eyes and SEE.
You shouldn't blame him. The truth is that Emacs does a great job at hiding its potential from users. Editors like Atom are ultimately much less powerful but they make it easy to discover and use the features that they provide. When I started using Emacs (after a decade of Vim), it took me two years to make myself fully feel at home in Emacs. Part of the reason was that you can't really use Emacs to its fullest without learning a good deal of Elisp. This is the part were other editors do much better.
Emacs is an outstanding image-based IDE for Elisp, with extensive support for text editing. It's a dynamic environment where you can script your way out of any situation as you go, without restarting and recompilation and so on, which is probably its most powerful feature. No wonder you need to know how to script it to appreciate this power - but I don't think Emacs hides this feature from users. On the contrary, the second thing you see when running vanilla Emacs (after its logo and greeting) is a scratch buffer, so a feature directed at users who want to customize or extend Emacs.
The potential of Emacs comes from the huge number of excellent third-party extensions not from the ability to evaluate lisp code in the scratch buffer. Many of these extensions are not very visible. Did you know that there is a really powerful PDF viewer for Emacs that has extensive support for annotations? It took me a long time to find out about it although reading and annotating PDFs is an important part of my work, which is why I did a fair amount of research into the topic. For some reason, this PDF viewer doesn't have a proper web page or documentation. I had to read the code in order to find out what its capabilities are. I leave it as an exercise to you to find out which extension I'm talking about. Perhaps that makes clearer what I meant when I wrote that Emacs is hiding its potential.
> The potential of Emacs comes from the huge number of excellent third-party extensions
Yes, but you wouldn't have that many excellent extensions without Emacs being a great Elisp IDE. I recently compared PyCharm (I had to purchase it for work) with Emacs and the number of plugins for the former is negligible in comparison. I think that this is because writing extensions/plugins for PyCharm is so much harder than for Emacs: no scratch, no built-in API docs, no full blown book on scripting (like Elisp info), no macro->defun ability, no defadvice, no find-function/find-library and so on and on and on...
Of course, the other reason may be the fact that Emacs has 30 years worth of code written for it :) but I think without matching Emacs extensibility features no editor will ever come close to it in terms of extensions. LightTable looks promising in this regard, so does Atom, but other than these all editors/IDEs look like they don't treat extensibility seriously. Which is why I'm still using Emacs as my primary workspace.
> Did you know that there is a really powerful PDF
You mean with DocView mode? Yes, I knew it (and it's built-in, not 3rd party). I also knew about Calc (http://nullprogram.com/blog/2009/06/23/), about Calendar, about proced, about dired and wdired, about VC, about ediff and emerge, about ctags/etags, about artist-mode, about rmail and gnus, about TRAMP and eshell and ansi-term...
Do you know how I learned about all of them? I just opened this page: https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht... and started reading. You know, cover to cover, as I'd do with any good book. Of course, along the way I switched to reading it inside Emacs, and I skipped some parts I decided I'm very unlikely to ever use, but I can assure you that it's all there. Perhaps a need for such a book is an Emacs failure in itself (because the interface is not discoverable by itself?), but at least it is there. I know of no other editor (Vim comes close in terms of docs coverage, but it's less neatly structured and harder to read cover-to-cover) which is that well documented.
Docview is great, but not enough. He mentioned pdf-tools: https://github.com/politza/pdf-tools, that enhances doc-view with outline for table of contents and annotations.
You can read this as "mainline Guile Emacs is never gonna happen".
Guile is very low quality software (that goes double, hell, triple, for "non free" platforms like OSX and Windows) and Emacs has a reputation for being rock solid on all platforms it runs on.
The Guile fanboys may wish for Guile to replace the current core in mainline but realistically speaking (Guile has what, 1/2 developers?) that's never going to happen.
If I had to guess, I'd say most Emacs users and developers couldn't care less about Scheme/Guile (if not actively hostile).
I'm leaning mostly towards the "couldn't care less" department. Though, I do think it is a shame if there are items we are missing out on because of it.
I am curious on just how many/what features would be on the table with an alternative vm. And then, how hard it would be to just add those features piecemeal instead of moving whole hog?
Where GOD can be anything of significance to you but to those who have experienced it's "the universe", the Void, the Unborn, the Undying and so on.
It's funny how a lot of ppl disregard this and have no clue about the "occult" (magick!) elements of the Art. When "mystical" experiences happen to them, lacking theory/practice and a proper framework to serve as a foundation, they tend to lose the world under their feet.
The presence of a JIT makes things trivially abusable for the attacker and is a big security risk.