@geniusmusing Given the large number of programs that use #Node.js under the hood, one may not know that anything is being pulled in from #npm. Huge potential for system compromise.
He did, but he kept control of them, so when his funds ran short, most of them disappeared. I've thought about deploying a Federati #Pump.io instance, but it runs atop #Node.js. I'd want to rent a completely separate server ( #VPS ) for it, so nothing else is affected if a poorly understood #JavaScript engine goes haywire.
I know one of Secure ScuttleButt’s features is not needing Internet at all, but if you’re not connecting via LAN occasionally, you need a way for #peer-to-peer software to bootstrap a pool of connections into the network overlay over the Internet. I think pubs (and the new implementation that is just getting started) are a sign that a P2P project is not designed for real life usage.
I realize that many “Butts”, including the developers, are leftish anarchists, so when things work, they are able to discuss the dream world they hope to implement. But the majority of people are not breathing such rarified air, and #Secure_ScuttleButt needs to just work for regular people also.
Probably needs some concepts from Jami … and to be implementable without using Node.js … which I’ve seen people saying is not currently possible.
An aside: I do wonder whether it depends on peculiarities of #JavaScript or of #Node.JS itself. If the first is true, one may be able to implement SSB with #Deno or #JSI / #JSISH.
I'm also still a little leery of letting WASM run in my browsers. Not that people can read obfuscated minified #JavaScript, but if you could obtain the pre-minified source, you might be able to tell what it was doing. With WASM, you're totally just letting unauditable and untrusted code run in your browser.
(I know this has a "Get off my lawn" flavor, but that's not what is happening here. Just wait until a GRU-sponsored malware gang starts inserting malicious WASM into popular sites around the Web.)
Role: JavaScript Solutions Architect ( #AngularJS)
Location: Minneapolis, MN, Burlington, MA, Louisville, CO, Alameda, CA or Remote for the Candidate
Position Summary:
Perforce is seeking an Open Source Software Support Engineer (with deep AngularJS experience) to join our OpenLogic team, responsible for providing support and services on Open Source technologies to our OpenLogic customers.
This critical position demands a software engineer with a strong programming skills and some networking capabilities. You would be responsible for ensuring the success of our customers by effectively providing dependable and timely resolutions related to open source software. The ideal candidate is expected to be self-motivated, proactive, results-oriented and able to provide a high level of customer satisfaction through the delivery of world-class technical support service
Responsibilities:
Interact with end users on technical problems
Tier 4 support for open source JavaScript products and tangential technologies
Drive resolution of those problems, which include:
Open source software issues
Questions around open source software usage
Questions around use and best practices
Review of the architecture and design where software is implemented
Conduct professional services and training engagements
Research, understand, and advocate open source software
Interact with various open source communities
Drive early resolution of issues
Present knowledge via articles, blogs, and conference presentations
Requirements:
Minimum of 10 years of software development and design, systems administration, or level 3-4 technical support experience
Minimum 5 years development, design, implementation, and troubleshooting experience on AngularJS
At least 2 years in a senior position ( senior/lead developer, engineer, or software architect)
Experience resolving remotely exploitable CVEs & cross-site scripting vulnerabilities
10+ years of hands on experience working w/ JavaScript technologies:
Highly-skilled JavaScript developer with extensive knowledge of theoretical Angular software engineering
Understanding of AJAX and #JavaScript DOM manipulation Techniques
Experience w/ RESTful services
Experience in JavaScript build tools like #Gulp or #Grunt
Familiar with JavaScript testing frameworks
Virtualization and cloud experience with qemu/kvm, #Azure, #AWS, VirtualBox, #Vagrant
Experience working in production environments, especially enterprise/carrier environments
Technical knowledge, skills & expertise in complex infrastructure, web-based software and enterprise software
Preference given to candidates with
implementation and troubleshooting experience on one or more of the following: #Node.js, #npm, #React, #Redux, Vue.js, Aurelia, Apache Cassandra, Jenkins CI, #DockerCE, #ElasticSearch, #Kubernetes, or #MongoDB
Experience migrating AngularJS to Angular
Experience transitioning AngularJS to other modern JavaScript solutions
Committer status on AngularJS product
Configured, installed, & maintained JavaScript applications at scale in a production environment
Experience tuning JavaScript for reliability & speed
If you’re interested in !TclTk, then you may find #jsish interesting, because its internals are designed based on some of Tcl’s internals, and because it integrates the #Fossil #DVCS and can be updated using standard Fossil commands.
I had just started an exploration push with “Deno”:{https://deno.land/} and “JSI/jsish”:{https://jsish.org/} ... but despite being interesting (as interesting as #JavaScript gets, IMO, but with seemingly less of the security nightmare that is Node.js and the NPM package repository), I think it is better to pause it along with the other learning projects.
The speaker I'm currently watching is working on a #Rust version that should be compatible and interchangeable with the #Node.js version. Not finished yet, obviously. There are a lot of pieces.
@musicman @geniusmusing That’s mostly #Node.js, which is a somewhat outdated fork of Chrome’s V8 engine. Considering that the browser is the least secure part of modern computers, and the #JavaScript engine is a key part of that insecurity, it is up to each person to decide whether to accept the risk.
Personally, I’m willing to accept Node, but only in a completely separate VM or VPS from other server-side software. Which explains why I never have hosted a Pump.io instance.