I agree with these points, as does my wife. My wife occasionally writes in Polish and macOS is much better for this. Windows is woefully poor at inputing accented characters: Alt+nnnn is a ridiculous system and navigating the character map is tedious.
I find the file I/O performance completely kills the appeal of the WSL. Firing up Emacs is noticably slower, even without any init file, and good luck if you have to run find and grep on large-ish directory structures. Builds that touch a lot of files will crawl. If you’re used to speedy file ops, working in a Unix-like way on Windows will make you miss an actual Unix environment. (It’s for this reason that I think my Win10 experiement will be ending soon.)
Would you care to elaborate regarding switching keyboard layout to PL, please? For me, the issue I have is using UK/GB layout and switching to PL as the latter is a modified US layout so @ and “ are swapped.
I’m sorry I can’t provide a lot more information. As far as I know, you have to add the language you want, then add keyboard layouts for those languages. You can switch keyboard layout using Win-Space. I do not know how to view the keyboard layouts that you choose, and there doesn’t seem to be an obvious way to do it.
I’m not a Windows user myself but, AFAICR, this is done in one go and the default layout will be chosen for a selected language.
I do have to agree though - most (all?) things are smoother on macOS :^)
Aah, viewing the layout. I’ve never thought of that, TBH - I usually know it before selecting it. In terms of Polish layout specifically, it’s quite intuitive - all the extra letters are produced by using AltGr as the modifier key + the base letter (bar ź, for which x is repurposed).
P.S. I’ve just done it on macOS and I’m amazed that Polish Programmer’s layout is still not the default and the first one in order is the Typist’s layout. Who uses that layout!?
Regarding character input: I use a Swedish keyboard but most often I use a US layout. When I need Swedish characters I just switch keyboards with Alt-Shift (Windows). I use both Mac and Windows and the process is the same However I’m not familiar with how keyboard support for Polish is in Windows.
Agree 100% with file I/O. I’m trying to learn PowerShell more for remote work where I can’t use Cygwin, and stuff that’s trivial on Unix (grepping through thousands of files) is painfully slow in PS. I adapted one script to essentially summarize large log files and there you have to create a local copy of the file and use System.IO.StreamReader to access them in reasonable time.
The support for Polish language is present since very early days of MS Windows. It is full well possible to use it as one of the Alt-Shift alternative keyboards. As such, I’m really surprised with the grandparent post; is it possible that the author doesn’t know about this feature on Windows? The Polish keyboard layout is based on the US one, with AltGr-a for “ą”, AltGr-l for “ł”, etc. — you get the idea. The only “slight” surprise might be AltGr-x for “ź”, as AltGr-z is already taken by “ż”. Does macOS somehow have it even simpler?
I’m not sure about Polish, but for the longest time Windows didn’t support Bulgarian Phonetic out of the box, only the older State Standard, which I never learnt (I’m not a native Bulgarian Speaker).
I think Windows is roughly fine for internationalization support now, for me the killer feature on macOS is the integration with all my devices and the accessibility. I’m hard of hearing, so the ability for my laptop to ring when my phone does is huge. So, the combination of internationalization and accessibility, in conjunction with a decent Unix setup, keep me on macOS for the time being.
Using the Left Alt key with any character on the Polish language on Win10 just results in either the chime sound or jumping to a menu. Right Alt doesn’t do anything. There is no AltGr key on the keyboard. As far as I can tell there is no keyboard viewer in order to see how the keyboard is mapped, either. The only reliable way we’ve found to get accented characters is to use the character map. (Depending on the keyboard choice, some keys, such as ‘[’, will insert accented characters instead of what one might expect.)
On macOS, you can press and hold a key (such as ‘z’) and you get a popup that lets you select what accent you want for the character using keys ‘1’ through the number of possible accent choices. This works in any native text entry area. You can also bring up the Keyboard Viewer, which shows a hovering keyboard window that displays what keys map to what symbols, including modifier keys. It’s reasonably intuitive to start typing on a different language keyboard layout on macOS. Windows, not so much.
Perhaps there’s a setting I’m missing. I’ve scoured the settings and found nothing that suggests there’s an easier way. You can use the Touch Keyboard to enter symbols in a similar way to a Mac, but it requires using the mouse (or your finger, or a stylus).
I tried some googling, but didn’t manage to find a way to see the keys of the current layout on Win10 quickly. I managed to find some list of Windows keyboard layouts; at letter P there, you can see 2 keyboards for Polish. When I clicked them, I was able to see a JS applet showing the keyboard layout. For Polish (programmers) (which is what you should use), hovering over the AltGr a.k.a. Right Alt on the preview, shows the positions of the accented letters. From what you say, if you’re getting accented letters instead of ] etc, then it’s most probable you’ve got the dreaded Polish (214) (known in older versions as Polish (typist)) layout. Nobody in Poland uses it, really :) I thought it was already removed from Win10, or at least well hidden, but it may well be that it’s still there, and you just stumbled upon it, unknowingly :( I sincerely hope for you it’s possible somehow to remove it, and get back to the standard “Polish (programmers)” one…
One example is CtrlP. It is currently the most recommended way of opening files in Vim. The default setup can be improved by using The Silver Searcher to find the files and using ctrl-py-matcher to match files with your search query. I always had issues with it.
I see ripgrep + fzf recommended much more often nowadays
From having to refresh every time I made a new file, to folders such as node_modules being included in the results unless I refreshed again (although this could be an issue with The Silver Searcher).
Did you set this in your agignore?
One of the settings that really slowed my Vim down, was the relativenumber setting. If you are not familiar with this setting, what it does is instead of displaying the actual line numbers in the file, it displays the how many lines away a line is relative to your current line. If that sounds confusing, just type :set relativenumber and you will see what I mean. Apparently this can make your Vim really slow when moving up and down.
TIL! Looks like :lazyredrawmay help with this? In any case, definitely not the first culprit I would point to for slow down, so thanks.
I understand many of the arguments written by Eduardo. I even agree with some of them. I am an Emacs and Vim user and I have faced a few of the issues stated by the author.
However I don’t agree with the idea behind this sentence:
However, open source, with its potential to bring hundreds (if not thousands) of developers together to help create amazing software, has given us: editors that run slower than what we had available in the 90s.
There are many open source editors that are fast. Anyways, I could agree with the idea that there is not an open source editor without a big learning curve as good as Sublime. However my biggest issue with that sentence is that it somehow express the idea that open source is a waste of time. It express something that was pretty common to hear when I started working for big companies more than 10 years ago: open source is done by junior developers that don’t have the ability to production ready code. OpenBSD, Linux and most compilers are the evidence that the idea behind that sentence is not real.
Going back to the editor discussion, I am pretty sure xi editor will be another counter example to that sentence. In the editor’s area we will have to wait a few years to see if I am right.
in this hn thread jonathan blow speculates on whether text editors would be better off with a keep-it-simple-stupid approach, trusting the cpu to make simple code and data structures fast rather than striving for clever datastructures and algorithmic efficiency.
No, I did not say open source is a waste time. I said that just because something is open source, does not make it good software.
Edit: Also, I am excited to see what becomes of xi editor. Hopefully it can learn from all the editors currently available and bring the best parts from all of them.
I think Sublime is a good example of that and that is why I think that for the moment you have a point. However I think that sentence is worrisome. From my point of view it gives the idea that there is something inherently bad with open source.
There’s something inherently bad with software in general if it’s written by inexperience people, those that don’t care about UX, or those that don’t care much about resource efficiency. That’s a lot of FOSS in the editor or IDE space. If looking more broadly, you’ll find the problem all over the place esp if .NET, Java, or PHP apps. The complex or half-ass platforms that also bring in the masses. ;)
Developers actually think JavaScript is “low level” (I’ve seen multiple people call it ‘the new assembly’) because other languages transpile to it.
Electron developers are essentially front-end web developers and/or nodejs developers.
NodeJS developers by-and-large think npm is “good”. NPM’s dependency management were (and maybe still be, I don’t know) a joke. Every package got a copy of all the packages it depends on.
The authors who create NPM packages are just as guilty. Depending on a hard version of a library seems to be very fucking common.
NPM’s dependency management were (and maybe still be, I don’t know) a joke.
It still is. I work on a small node.js project at work. I was explaining npm to some Haskell programmers. They were horrified when showed the project’s node_modules directory, which contained:
12 copies of readable-stream, which is an implementation of something that’s also in node.js…
I probably shouldn’t say “copies” because for each there’s at least 4 different versions.
npm’s installation is also non-deterministic. You can install the same dependencies twice and get a different layout of packages in your node_modules directory.
npm’s installation is also non-deterministic. You can install the same dependencies twice and get a different layout of packages in your node_modules directory.
That should be fixed with Yarn. It’s just amazing that the JavaScript community took this long to build a solution.
Yeah, npm isn’t so good, that’s why Facebook came up with Yarn, which seems to solve a lot of the shortcomings of npm. We’re transitioning to it at my company and its working great. With npm, we intermittently saw builds fail because of non-deterministic package resolution, which yarn solved.
It’s hard to argue with you. You’re right, but I feel there’s maybe a bit of nuance here.
In the case of Air, one vuln definitely takes out all of the Air apps on the system. A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!
A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!
Unfortunately life shows it’s the other way around.
Take the recent Linux remote UDP vulnerability as a perfect depiction of what usually happens.
You have a ton of systems, devices shipping a different version of the Linux kernel
The situation you are depicting would only work if every security flaw was contained to a single version of the bundled runtime - in reality it’s more likely that it will impact a range of versions and bundled software is less likely to receive security updates.
The only thing that changes is having to patch each and every copy of the runtime in case of a security issue instead of patching the single system wide shared runtime.
Between the time the patch is identified, fixed, and release there is a window of non-zero time. An active maintainer can reduce this time, but in many cases, the user isn’t forced to update, nor is this time 0. Even worse is if the vuln is actively exploited before being disclosed.
It’s bad anyway you look at it. Maybe the Electron model is worse because the number of different versions possible for the runtime increases the likelihood of one being vulnerable. But maybe, just maybe, the track record of Adobe is so bad that the chances of Air having vulnerabilities far exceeds the likelihood of Chrome having vulnerabilities, even when many different versions are installed on the system?
Spotify is only good because they have a huge selection of music. Both their iOS and Mac app is the worst app I have installed on either platform, except maybe iTunes.
So, if you judge the apps in terms of the native Apple ecosystem, sure, I’m with you. But at least for me there is a sense of Good Enough and spotify for me personally at least is Good Enough. I can play my music, I can browse music my friends are listening to, I can enjoy the myriad playlists Spotify and my friends create. It Is Good Enough.
Totally agree. However this is a case where in an ideal world, everyone would develop native clients for every platform and life would be grand.
But, in the real world, every development man hour has to be justified to the bean counters, and for my needs, I would much MUCH rather have a Good Enough client that runs on my Mac, my Linux desktop, my phone, my FireTV, etc etc etc than a deliciously smooth native client that’s Windows only and to heck with everyone else :)
Well yeah, but for someone huge like Spotify, Slack, Github and so on, I don’t think it’s justified at all. And I’d rather use something else. Only problem is that apples native music player is even worse in this particular case :p
Oh boy. “Phoenix on Elixir”. As much as I love Elixir/Erlang/BEAM, it seems inevitable for the language and ecosystem to get stampeded by hyped-up Rails/web developers who think of both as the same thing. Oh well, more users means more chances of getting an Elixir job.
The article never defined what a “modern app” is and how Phoenix makes it easier compared to Rails (which has web sockets). That said, Phoenix has the BEAM behind it and is not a majestic monolith—with umbrella applications, it can just act as your web server and have little to no business logic, so it can make large web applications easier to manage.
This is valid criticism. My main focus was trying to find the parts in Rails that can be easily “translated” into Phoenix and explain those parts. I didn’t write much about BEAM and umbrella applications because there really isn’t an equivalent in Rails.
Sorry if I was too hard on you—the rest of the article is excellent. It just happens that those two things really bug me :-) I definitely think umbrella applications deserve a mention, it’s a major advantage to Rails (or many other languages).
Not really at all. I’m trying to think of any similarities but I’m currently failing; they’re closer to a package of packages. I’ll go through some reasoning:
A Django app is a framework construct, Elixir Umbrella’s are more core to the language itself. Every build of Elixir ships with Mix, a build tool which is capable of creating new Elixir projects. An Umbrella project is simply a root level Elixir project that contains one or more Elixir projects “under its wings”. Each Elixir project keeps it’s own dependencies, version, docs, start-up list, build, test suite, etc. Basically it lets you have a de-coupled per-app isolated layout while keeping the advantages that a single repo can give. Each app within the umbrella is individually deployable.
In Django, it’s quite awkward to create a 3rd-party package that runs alongside your actual project while you’re developing it. Sure it’s possible, but with Python Path and module importing issues - it tends not to happen and you end up syncing with some git remote. This problem is solved with Umbrella projects because you simply create a new Elixir project within your umbrella and list the new project as an “in umbrella” dependency to your existing project; this means that when you’re finished with development and ready to open source on Hex - all you have to do is publish it and change the dependency of your original application to point to Hex instead. And if you never finish it? It can just stay there running as it’s own self-contained app. It reduces the friction completely.
A Django app tends to be tightly related to a set of models and specific Django patterns. An Umbrella project is not really constrained by anything other than the standard layout of an Elixir project - which is defined by the Mix tool in every project anyway. There is no linking it with a set of data and it doesn’t take on any special extras when used with say Phoenix - it’s just a Mix project at the end of day, and any Elixir project can be one.
To end with an example: a common pattern I take when using Phoenix is to start with an Elixir Umbrella app, and then immediately create 2 sub apps: one that contains my business logic and data stores, and the other that deals with interfacing with the web with Phoenix as a dependency. Having the separate apps helps me enforce the separation by providing a clear isolation line, and also means that I’m not glued to Phoenix. Also, while they do have separate things, if I run commands from the root Umbrella, they tend to get run on both - the integration is very nice there.
Edit: I deliberately stayed away from OTP because I think the acronym can be off putting to newcomers but for simplicities sake, 1 Elixir project == 1 OTP app.
I haven’t used Rails Engines in a while so I completely forgot about them. I know they can be used for similar purposes but if I recall correctly they almost become a part of the Rails monolith instead of being treated as a separate application as in Elixir. I could be wrong though.
dtf will delete to next f, if you then realize that was one f before the one you targeted, you need to undo, go back to your initial position, and try again with d2tf
Wouldn’t you just press . to achieve the same effect?
Besides, unlike (n)vi, vim sort-of supports the object-verb model with v (visual selection), and it’s even adjustable in real time. vtf;d is “select until ‘f’, repeat movement (to next ‘f’), delete selection”.
It is the equivilent of using the default operating system that comes on a new laptop without first reading a security audit
No it’s not. An operating system has the power to destroy every file on your computer if programmed to do so. JavaScript in the browser does not. At worst, it can probably spin the CPU to 100% or track what sites you visited.
Hold on. There is a huge difference between arbitrary code (i.e. arbitrary instructions) and arbitrary computations. The latter can be achieved using very few instructions or with other simple systems such as lambda calculus. Though these can be used to perform any computation imaginable within the resource limits, they may yet be completely incapable of speaking the language used by the rest of the system. We need not even introduce the concept of a sandbox (or other externally imposed mitigations) for this to be true. And so the exploitation they can do is entirely dependent on the nature of the vulnerabilities, just as it is with e.g. parser bugs for non-turing complete formats (which can also cascade exploits – if they happen to be of the kind that cascade).
In other words, arbitrary computations are not inherently capable of producing arbitrary code. That power must be granted through a sufficiently severe exploit, if it is not a built-in feature of the language’s implementation.
This is one of the reasons why I think focusing on turing completeness as a security issue is somewhat misguided.
At worst, it can cascade exploits to achieve anything it wants. Arbitrary code running on your computer is arbitrary code running in your computer.
No it really isn’t. Not when we’re talking about an airtight sandbox. A great many document formats are Turing-complete (e.g. PostScript), but we don’t generally see this as a problem.
You’ve described mitigations but are not really disagreeing with what I said. The mitigations may even be effective, but note that they were necessary in the first place. That underscores my point.
Sandbox was a poor choice of term. The difficulty of securely rendering a format has nothing to do with whether that format is Turing-complete or not (provided you’re willing to accept failure as an answer sometimes). Browsers have had far more vulnerabilities in “running” JPEG/PNG/SVG/etc. than in running JavaScript, and will continue to do so, because the code for those things is more likely to be the kind of bit-twiddling C code that’s always full of vulnerabilities. JPEG is not Turing-complete but that fact is just utterly irrelevant.
I think the main issue with PGP is that other people still have bother to check the signature, sometimes the program does it automatically, sometimes it does not. GitHub displays a “Verified” badge next to commits that have been signed by you, so that’s a step in the right direction.
Author here. This blog post is a bit old but I decided to start sharing it on other sites once people started saying that Vim was ruined because of the new Macbook Pros. I stopped using <Esc> when I wrote the blog post and never looked back. Hopefully I have helped fellow Vim users use a better alternative to the <Esc> key.
Good reference for those trying to pay for a new MacBook Pro with touch bar. Literally my first thought when seeing it was, “But wait, how will I Vim?!”
Author here. That is exactly why I started sharing this article on other sites (luckily, it ended up here as well). I wrote it a couple of years ago but it seemed more relevant now because of the new Macbook Pro.
I agree with these points, as does my wife. My wife occasionally writes in Polish and macOS is much better for this. Windows is woefully poor at inputing accented characters: Alt+nnnn is a ridiculous system and navigating the character map is tedious.
I find the file I/O performance completely kills the appeal of the WSL. Firing up Emacs is noticably slower, even without any init file, and good luck if you have to run
findandgrepon large-ish directory structures. Builds that touch a lot of files will crawl. If you’re used to speedy file ops, working in a Unix-like way on Windows will make you miss an actual Unix environment. (It’s for this reason that I think my Win10 experiement will be ending soon.)Would you care to elaborate regarding switching keyboard layout to PL, please? For me, the issue I have is using UK/GB layout and switching to PL as the latter is a modified US layout so @ and “ are swapped.
I’m sorry I can’t provide a lot more information. As far as I know, you have to add the language you want, then add keyboard layouts for those languages. You can switch keyboard layout using Win-Space. I do not know how to view the keyboard layouts that you choose, and there doesn’t seem to be an obvious way to do it.
I’m not a Windows user myself but, AFAICR, this is done in one go and the default layout will be chosen for a selected language.
I do have to agree though - most (all?) things are smoother on macOS :^)
Aah, viewing the layout. I’ve never thought of that, TBH - I usually know it before selecting it. In terms of Polish layout specifically, it’s quite intuitive - all the extra letters are produced by using
AltGras the modifier key + the base letter (bar ź, for which x is repurposed).P.S. I’ve just done it on macOS and I’m amazed that Polish Programmer’s layout is still not the default and the first one in order is the Typist’s layout. Who uses that layout!?
Have you tried the US keyboard with international dead keys?
No, and I didn’t know about that, although I suspect my wife won’t like typing that way.
Regarding character input: I use a Swedish keyboard but most often I use a US layout. When I need Swedish characters I just switch keyboards with Alt-Shift (Windows). I use both Mac and Windows and the process is the same However I’m not familiar with how keyboard support for Polish is in Windows.
Agree 100% with file I/O. I’m trying to learn PowerShell more for remote work where I can’t use Cygwin, and stuff that’s trivial on Unix (grepping through thousands of files) is painfully slow in PS. I adapted one script to essentially summarize large log files and there you have to create a local copy of the file and use System.IO.StreamReader to access them in reasonable time.
The support for Polish language is present since very early days of MS Windows. It is full well possible to use it as one of the Alt-Shift alternative keyboards. As such, I’m really surprised with the grandparent post; is it possible that the author doesn’t know about this feature on Windows? The Polish keyboard layout is based on the US one, with AltGr-a for “ą”, AltGr-l for “ł”, etc. — you get the idea. The only “slight” surprise might be AltGr-x for “ź”, as AltGr-z is already taken by “ż”. Does macOS somehow have it even simpler?
I’m not sure about Polish, but for the longest time Windows didn’t support Bulgarian Phonetic out of the box, only the older State Standard, which I never learnt (I’m not a native Bulgarian Speaker).
I think Windows is roughly fine for internationalization support now, for me the killer feature on macOS is the integration with all my devices and the accessibility. I’m hard of hearing, so the ability for my laptop to ring when my phone does is huge. So, the combination of internationalization and accessibility, in conjunction with a decent Unix setup, keep me on macOS for the time being.
Using the Left Alt key with any character on the Polish language on Win10 just results in either the chime sound or jumping to a menu. Right Alt doesn’t do anything. There is no AltGr key on the keyboard. As far as I can tell there is no keyboard viewer in order to see how the keyboard is mapped, either. The only reliable way we’ve found to get accented characters is to use the character map. (Depending on the keyboard choice, some keys, such as ‘[’, will insert accented characters instead of what one might expect.)
On macOS, you can press and hold a key (such as ‘z’) and you get a popup that lets you select what accent you want for the character using keys ‘1’ through the number of possible accent choices. This works in any native text entry area. You can also bring up the Keyboard Viewer, which shows a hovering keyboard window that displays what keys map to what symbols, including modifier keys. It’s reasonably intuitive to start typing on a different language keyboard layout on macOS. Windows, not so much.
Perhaps there’s a setting I’m missing. I’ve scoured the settings and found nothing that suggests there’s an easier way. You can use the Touch Keyboard to enter symbols in a similar way to a Mac, but it requires using the mouse (or your finger, or a stylus).
I tried some googling, but didn’t manage to find a way to see the keys of the current layout on Win10 quickly. I managed to find some list of Windows keyboard layouts; at letter P there, you can see 2 keyboards for Polish. When I clicked them, I was able to see a JS applet showing the keyboard layout. For Polish (programmers) (which is what you should use), hovering over the AltGr a.k.a. Right Alt on the preview, shows the positions of the accented letters. From what you say, if you’re getting accented letters instead of
]etc, then it’s most probable you’ve got the dreaded Polish (214) (known in older versions as Polish (typist)) layout. Nobody in Poland uses it, really :) I thought it was already removed from Win10, or at least well hidden, but it may well be that it’s still there, and you just stumbled upon it, unknowingly :( I sincerely hope for you it’s possible somehow to remove it, and get back to the standard “Polish (programmers)” one…I see ripgrep + fzf recommended much more often nowadays
Did you set this in your agignore?
TIL! Looks like
:lazyredrawmay help with this? In any case, definitely not the first culprit I would point to for slow down, so thanks.I was not aware of fzf. I will try it out someday.
No, but it was in my gitignore, which ag supposedly used as well. That folder would appear randomly every time I refreshed.
lazyredraw helps a bit but not when you are required to scroll.
Who needs more than 256 colors for syntax highlighting?
Agreed!
vim -u NONEThe fastest editor you will ever use.
Neovim does truecolor fine. I don’t see why you’d want to limit yourself. My colorscheme uses like 4 colors but they’re exactly the ones I want.
I understand many of the arguments written by Eduardo. I even agree with some of them. I am an Emacs and Vim user and I have faced a few of the issues stated by the author.
However I don’t agree with the idea behind this sentence:
There are many open source editors that are fast. Anyways, I could agree with the idea that there is not an open source editor without a big learning curve as good as Sublime. However my biggest issue with that sentence is that it somehow express the idea that open source is a waste of time. It express something that was pretty common to hear when I started working for big companies more than 10 years ago: open source is done by junior developers that don’t have the ability to production ready code. OpenBSD, Linux and most compilers are the evidence that the idea behind that sentence is not real.
Going back to the editor discussion, I am pretty sure xi editor will be another counter example to that sentence. In the editor’s area we will have to wait a few years to see if I am right.
I agree that this is inexcusable. Text editors, of all things, should work faster than we can think in 2017.
in this hn thread jonathan blow speculates on whether text editors would be better off with a keep-it-simple-stupid approach, trusting the cpu to make simple code and data structures fast rather than striving for clever datastructures and algorithmic efficiency.
Even better, Mark gives a specific scheme that worked for him:
http://scienceblogs.com/goodmath/2009/02/18/gap-buffers-or-why-bother-with-1/
No, I did not say open source is a waste time. I said that just because something is open source, does not make it good software.
Edit: Also, I am excited to see what becomes of xi editor. Hopefully it can learn from all the editors currently available and bring the best parts from all of them.
I think Sublime is a good example of that and that is why I think that for the moment you have a point. However I think that sentence is worrisome. From my point of view it gives the idea that there is something inherently bad with open source.
There’s something inherently bad with software in general if it’s written by inexperience people, those that don’t care about UX, or those that don’t care much about resource efficiency. That’s a lot of FOSS in the editor or IDE space. If looking more broadly, you’ll find the problem all over the place esp if .NET, Java, or PHP apps. The complex or half-ass platforms that also bring in the masses. ;)
Electron is not flash.
JavaScript is flash.
Electron is the Adobe Air and that’s far worse than being a modern flash.
Well, with Air you had to have the Air runtime. Electron apps are self contained, right? That makes them at least somewhat better…
You surely mean worse? That means each Electron app potentially packages an old, unpatched runtime with similar complexity to the Chrome browser.
This is the new world.
Developers actually think JavaScript is “low level” (I’ve seen multiple people call it ‘the new assembly’) because other languages transpile to it.
Electron developers are essentially front-end web developers and/or nodejs developers.
NodeJS developers by-and-large think
npmis “good”. NPM’s dependency management were (and maybe still be, I don’t know) a joke. Every package got a copy of all the packages it depends on.The authors who create NPM packages are just as guilty. Depending on a hard version of a library seems to be very fucking common.
The last time I bothered to check on this stuff, I posted about it: https://news.ycombinator.com/item?id=11092772
It still is. I work on a small node.js project at work. I was explaining npm to some Haskell programmers. They were horrified when showed the project’s node_modules directory, which contained:
I probably shouldn’t say “copies” because for each there’s at least 4 different versions.
npm’s installation is also non-deterministic. You can install the same dependencies twice and get a different layout of packages in your node_modules directory.
That should be fixed with Yarn. It’s just amazing that the JavaScript community took this long to build a solution.
There’s also ied, which does a pretty good job.
Yeah, npm isn’t so good, that’s why Facebook came up with Yarn, which seems to solve a lot of the shortcomings of npm. We’re transitioning to it at my company and its working great. With npm, we intermittently saw builds fail because of non-deterministic package resolution, which yarn solved.
It’s hard to argue with you. You’re right, but I feel there’s maybe a bit of nuance here.
In the case of Air, one vuln definitely takes out all of the Air apps on the system. A vuln in Chrome / Electron, is likely targetting one specific version, or a small range of them. In the event all Electron apps have a slightly different version, you might actually get lucky from time to time!
Unfortunately life shows it’s the other way around.
Take the recent Linux remote UDP vulnerability as a perfect depiction of what usually happens.
The situation you are depicting would only work if every security flaw was contained to a single version of the bundled runtime - in reality it’s more likely that it will impact a range of versions and bundled software is less likely to receive security updates.
The only thing that changes is having to patch each and every copy of the runtime in case of a security issue instead of patching the single system wide shared runtime.
It happens both ways. Some versions of Red Hat Enterprise Linux, for instance, weren’t affected by this UDP vulnerability, but your point is taken.
Maybe the thing to agree on is that shipping any software results in some sort of security risk.
I would lean towards: “any shipped software that is not actively maintained and doesn’t receive security patches”.
Between the time the patch is identified, fixed, and release there is a window of non-zero time. An active maintainer can reduce this time, but in many cases, the user isn’t forced to update, nor is this time 0. Even worse is if the vuln is actively exploited before being disclosed.
Given that taking over one app lets you control all the others (you’re now running with users privs) I’d have to say this is a worse position.
It’s bad anyway you look at it. Maybe the Electron model is worse because the number of different versions possible for the runtime increases the likelihood of one being vulnerable. But maybe, just maybe, the track record of Adobe is so bad that the chances of Air having vulnerabilities far exceeds the likelihood of Chrome having vulnerabilities, even when many different versions are installed on the system?
But, I don’t disagree here!
In 2011 AIR shipped an embedded runtime feature, so you could do the “self-contained” route if you wanted to.
I was not aware of this!
I am reading this while listening to Spotify, whose desktop app is Adobe Air. Tool to task people, all this vitriol is misplaced.
Spotify is only good because they have a huge selection of music. Both their iOS and Mac app is the worst app I have installed on either platform, except maybe iTunes.
So, if you judge the apps in terms of the native Apple ecosystem, sure, I’m with you. But at least for me there is a sense of Good Enough and spotify for me personally at least is Good Enough. I can play my music, I can browse music my friends are listening to, I can enjoy the myriad playlists Spotify and my friends create. It Is Good Enough.
Sure but in that sense, CDs are good enough too. Luckily, most aim for better, not just good enough. If they didn’t, the world wouldn’t improve.
Totally agree. However this is a case where in an ideal world, everyone would develop native clients for every platform and life would be grand.
But, in the real world, every development man hour has to be justified to the bean counters, and for my needs, I would much MUCH rather have a Good Enough client that runs on my Mac, my Linux desktop, my phone, my FireTV, etc etc etc than a deliciously smooth native client that’s Windows only and to heck with everyone else :)
Well yeah, but for someone huge like Spotify, Slack, Github and so on, I don’t think it’s justified at all. And I’d rather use something else. Only problem is that apples native music player is even worse in this particular case :p
Oh boy. “Phoenix on Elixir”. As much as I love Elixir/Erlang/BEAM, it seems inevitable for the language and ecosystem to get stampeded by hyped-up Rails/web developers who think of both as the same thing. Oh well, more users means more chances of getting an Elixir job.
The article never defined what a “modern app” is and how Phoenix makes it easier compared to Rails (which has web sockets). That said, Phoenix has the BEAM behind it and is not a majestic monolith—with umbrella applications, it can just act as your web server and have little to no business logic, so it can make large web applications easier to manage.
This is valid criticism. My main focus was trying to find the parts in Rails that can be easily “translated” into Phoenix and explain those parts. I didn’t write much about BEAM and umbrella applications because there really isn’t an equivalent in Rails.
Sorry if I was too hard on you—the rest of the article is excellent. It just happens that those two things really bug me :-) I definitely think umbrella applications deserve a mention, it’s a major advantage to Rails (or many other languages).
No worries. I enjoy honest criticism, it helps me improve. This is my first blog post of this size, so I have plenty to learn still.
For people that used both Elixir and Django: how do the Umbrella Projects relate to what django calls apps?
Not really at all. I’m trying to think of any similarities but I’m currently failing; they’re closer to a package of packages. I’ll go through some reasoning:
A Django app is a framework construct, Elixir Umbrella’s are more core to the language itself. Every build of Elixir ships with Mix, a build tool which is capable of creating new Elixir projects. An Umbrella project is simply a root level Elixir project that contains one or more Elixir projects “under its wings”. Each Elixir project keeps it’s own dependencies, version, docs, start-up list, build, test suite, etc. Basically it lets you have a de-coupled per-app isolated layout while keeping the advantages that a single repo can give. Each app within the umbrella is individually deployable.
In Django, it’s quite awkward to create a 3rd-party package that runs alongside your actual project while you’re developing it. Sure it’s possible, but with Python Path and module importing issues - it tends not to happen and you end up syncing with some git remote. This problem is solved with Umbrella projects because you simply create a new Elixir project within your umbrella and list the new project as an “in umbrella” dependency to your existing project; this means that when you’re finished with development and ready to open source on Hex - all you have to do is publish it and change the dependency of your original application to point to Hex instead. And if you never finish it? It can just stay there running as it’s own self-contained app. It reduces the friction completely.
A Django app tends to be tightly related to a set of models and specific Django patterns. An Umbrella project is not really constrained by anything other than the standard layout of an Elixir project - which is defined by the Mix tool in every project anyway. There is no linking it with a set of data and it doesn’t take on any special extras when used with say Phoenix - it’s just a Mix project at the end of day, and any Elixir project can be one.
To end with an example: a common pattern I take when using Phoenix is to start with an Elixir Umbrella app, and then immediately create 2 sub apps: one that contains my business logic and data stores, and the other that deals with interfacing with the web with Phoenix as a dependency. Having the separate apps helps me enforce the separation by providing a clear isolation line, and also means that I’m not glued to Phoenix. Also, while they do have separate things, if I run commands from the root Umbrella, they tend to get run on both - the integration is very nice there.
Edit: I deliberately stayed away from OTP because I think the acronym can be off putting to newcomers but for simplicities sake, 1 Elixir project == 1 OTP app.
An “umbrella project” is just multiple OTP applications in one project. They are full OTP applications, so more like a generic python package.
While not really used, internal Rails Engines are equivalent to umbrella applications.
I haven’t used Rails Engines in a while so I completely forgot about them. I know they can be used for similar purposes but if I recall correctly they almost become a part of the Rails monolith instead of being treated as a separate application as in Elixir. I could be wrong though.
I just noticed that the title kind of suggests that the name of the framework is “Phoenix on Elixir”, which was not the intention. Sorry about that.
Wouldn’t you just press
.to achieve the same effect?Unless you want to repeat the whole
d2tfwith., in which case you’d have to hit it twice every time you wanted to use it.Besides, unlike (n)vi, vim sort-of supports the object-verb model with
v(visual selection), and it’s even adjustable in real time.vtf;dis “select until ‘f’, repeat movement (to next ‘f’), delete selection”.With
dtfmaybe, but it won’t help withytf.And the result of the paste register will be different, too, with
dtf.No it’s not. An operating system has the power to destroy every file on your computer if programmed to do so. JavaScript in the browser does not. At worst, it can probably spin the CPU to 100% or track what sites you visited.
At worst, it can cascade exploits to achieve anything it wants. Arbitrary code running on your computer is arbitrary code running in your computer.
Hold on. There is a huge difference between arbitrary code (i.e. arbitrary instructions) and arbitrary computations. The latter can be achieved using very few instructions or with other simple systems such as lambda calculus. Though these can be used to perform any computation imaginable within the resource limits, they may yet be completely incapable of speaking the language used by the rest of the system. We need not even introduce the concept of a sandbox (or other externally imposed mitigations) for this to be true. And so the exploitation they can do is entirely dependent on the nature of the vulnerabilities, just as it is with e.g. parser bugs for non-turing complete formats (which can also cascade exploits – if they happen to be of the kind that cascade).
In other words, arbitrary computations are not inherently capable of producing arbitrary code. That power must be granted through a sufficiently severe exploit, if it is not a built-in feature of the language’s implementation.
This is one of the reasons why I think focusing on turing completeness as a security issue is somewhat misguided.
No it really isn’t. Not when we’re talking about an airtight sandbox. A great many document formats are Turing-complete (e.g. PostScript), but we don’t generally see this as a problem.
You’ve described mitigations but are not really disagreeing with what I said. The mitigations may even be effective, but note that they were necessary in the first place. That underscores my point.
Sandbox was a poor choice of term. The difficulty of securely rendering a format has nothing to do with whether that format is Turing-complete or not (provided you’re willing to accept failure as an answer sometimes). Browsers have had far more vulnerabilities in “running” JPEG/PNG/SVG/etc. than in running JavaScript, and will continue to do so, because the code for those things is more likely to be the kind of bit-twiddling C code that’s always full of vulnerabilities. JPEG is not Turing-complete but that fact is just utterly irrelevant.
I think the main issue with PGP is that other people still have bother to check the signature, sometimes the program does it automatically, sometimes it does not. GitHub displays a “Verified” badge next to commits that have been signed by you, so that’s a step in the right direction.
Author here. This blog post is a bit old but I decided to start sharing it on other sites once people started saying that Vim was ruined because of the new Macbook Pros. I stopped using <Esc> when I wrote the blog post and never looked back. Hopefully I have helped fellow Vim users use a better alternative to the <Esc> key.
Good reference for those trying to pay for a new MacBook Pro with touch bar. Literally my first thought when seeing it was, “But wait, how will I Vim?!”
Author here. That is exactly why I started sharing this article on other sites (luckily, it ended up here as well). I wrote it a couple of years ago but it seemed more relevant now because of the new Macbook Pro.