Yikes. I also just noticed that all the plugins (part of the pro feature set) rely on separate apk downloads from the Play Store, which all appear to be dead/delisted. This is really a shame, I too have thought of this as "the best" Android SSH client in the past.
Yes, it is enabled by default (in fact this caused problems earlier on). Licensed hams (in the US) can increase transmit power (and theoretically use additional spectrum outside of ISM) but even the default "public" channel was encrypted with a known, publicized key. There was some debate whether this ran afoul of amateur radio rules against encryption, even if the key is known, since it cannot be disabled. I believe there was some progress in fixing this and allowing truly unencrypted channels for licensed operators, but I haven't checked back recently.
We frequently get juniors or interns who are perfectly capable of pumping out many LoC with the use of AI in various forms - the issue is that they _don't_ actually ever learn how to think for themselves, and can't fix problems when something goes wrong or the LLM paints itself into a corner. I have found myself doing a lot more shepherding and pairing with juniors when they can't figure something out recently, because they just have not had the space to build their own skills.
A few years later but similarly - I am still running a machine built spur-of-the-moment in a single trip to Micro Center for about $500 in late 2019 (little did we know what was coming in a few months!). I made one small upgrade in probably ~2022 to a Ryzen 5800X w/ 64GB of RAM but otherwise untouched. It still flies through basically anything & does everything I need, but I'm dreading when any of the major parts go and I have to fork out double or triple the original cost for replacements...
How can I take your comment seriously if you didn't read the article? It looks like someone didn't actually make an effort to understand the context of the images.
> Moore's law is supposed to drive down the cost of electronics
The core of the article is this complete misunderstanding of Moore's law. From there, all the rest of the confusion follows, unsurprisingly leading to the author's claim that ~$100 for a long-lasting device is unreasonably expensive.
A human working on an existing codebase does not have any special signal about what is _not_ in a codebase. Instead, a (good) human engineer can look at how a problem is handled and consider why it might have been done that way vs other options, then make an educated decision about whether that alternative would be an improvement. To me this seems like yet another piece of evidence that these models are not doing any "reasoning" or problem-solving.
I had a coworker making very similar claims recently - one of the more AI-positive engineers on my team (a big part of my department's job is assessing new/novel tech for real-world value vs just hype). I was stunned when I actually saw the output of this process, which was a multi-page report describing the architecture of an internal system that arguably needed an overhaul. I try to keep an open mind, but this report was full of factual mistakes, misunderstandings, and when it did manage to accurately describe aspects of this system's design/architecture, it made only the most surface-level comments about boilerplate code and common idioms, without displaying any understanding of the actual architecture or implications of the decisions being made. Not only this coworker but several other more junior engineers on my team proclaimed this to be an example of the amazing advancement of AI ... which made me realize that the people claiming that LLMs have some superhuman ability to understand and design computer systems are those who have never really understood it themselves. In many cases these are people who have built their careers on copying and pasting code snippets from stack overflow, etc., and now find LLMs impressive because they're a quicker and easier way to do the same.
Oops..... we are currently trying to sell an elixir-based greenfield project internally. This doesn't affect elixir by default as other commenters pointed out, but still might make our project a bit harder to pitch to management...
If your organization is looking for "the language ecosystem that never has any security vulnerabilities", pack it in and close up shop because you're not going to find one. How many, how often, and how they are handled is far more important.
While the Erlang/Elixir ecosystem won't stop you from writing a network server that takes in a string and just blithely passes it along to a shell without analysis, overall the Erlang/Elixir ecosystem is very strong and lacks most of the footguns like an "eval" statement that get people. Though I will ding it a point for the most obvious way to run a shell command [1] taking just a string that goes to a shell rather than an array of parameters to a shell command.
It is on the higher end of secure languages to write a network server in.
> overall the Erlang/Elixir ecosystem is very strong and lacks most of the footguns like an "eval" statement that get people
Erlang has erl_eval [1] if you're looking for more ability to shoot yourself in the foot. You can call that from Elixir, but I guess that'd be weird; I'm not an Elixir person, but I'd bet you can shoot yourself in the foot if you try!
There's always fun with dist and proc_lib:spawn(Node, Fun) [2], which you can put in a list comprehension with erlang:nodes() [3] if you want to shot yourself in many feet rapidly ;)
All this foot shooting - this is the problem with permissive gun laws. We should ideally lock down all firearms to prevent any civilian doing harm. Only the select few government agents should own firearms.
I’ve seen more horrendous code using macros in elixir even despite by brief foray than I have seen ever in decades of working in languages with eval. Like using them when normal functions would suffice.
Using macros when a function would do is a legit anti-pattern (and documented as such [1]) but unrelated to the security aspect as they are compile-time constructs.
The reason they were added to the language was precisely so meta and dynamic programming is done at compile time, which you can introspect before you deploy, versus doing it at runtime, which is how most dynamic languages tackle this. And those languages are most likely not using eval either, but intrinsic features that allow you to define classes, attributes, methods, and so on programmatically.
I’d say eval is discouraged in most languages, although it is useful for building things like REPLs and interactive environments.
That is quite the wrong way of looking at it. The vulnerability is in a implementation of SSH and not with the language/runtime itself; And it has already been patched. Erlang is a "managed" language and is quite secure compared to others.
You should definitely "sell" Elixir/Erlang/BEAM based languages to your management for a greenfield project; The opportunity is too good to pass up.
Nevertheless, if you would like to learn how to "harden" your Elixir/Erlang system, see the guidelines from the "Security Working Group" of EEF which i have linked to here - https://news.ycombinator.com/item?id=43717633
Nothing they do makes sense until you accept that hypocrisy is a feature, not a bug, for them and their base. They know that what they're asking for is impossible to meaningfully comply with...
