he/him/his, cis, gay, husband, Beagle chew-toy, JavaScript jockey, Rustacean

  • 6 Posts
  • 13 Comments
Joined 8M ago
cake
Cake day: Apr 06, 2021

help-circle
rss

I’ve just finished watching some great talks on undefined behaviour in C/Cpp:

And Rust’s own list of undefined behaviour is here, almost entirely do to with humans using unsafe but not taking the necessary care with it: https://doc.rust-lang.org/reference/behavior-considered-undefined.html


new crates from an aspiring-Rustacean: owasp-headers and tower-default-headers

I’ve been trying to skill up in terms of using Rust for developing web services, and it occurred to me that there weren’t any crates available for conveniently adding OWASP’s best-practice HTTP headers to outgoing responses by default …


I was sort of cheeky with my ~/.ssh example, because I’m actually 100% on Yubikeys for my SSH private keys, so there’s only public keys in that directory now

But, with my setup ( https://gitlab.com/jokeyrhyme/dotfiles/-/blob/main/packages/flatpak-update.sh#L66 ) I run flatpak override --user --nofilesystem=home ... for a few things like flatpak web browsers (really, I should run this for everything)

It’s all about defense-in-depth: putting up as many barriers as I can before the getting inconvenienced more than I’d like, and flatpak is so easy for me to use that there isn’t any inconvenience at all


Meh, I’ve been using the official Firefox flatpak, and I love that my web browser has no access whatsoever to my ~/.ssh private keys, or anything else I don’t want it to be able to read


I love it

Having tools that are opinionated about line breaks is amazing for my productivity

I don’t like exactly what it does every time, but overall I spend so much less time fiddling with whitespace


I exclusively run web browsers in flatpak

I love that no firefox or chromium process has access to e.g. ~/.ssh or /etc or any number of other things a web browser has no business accessing

It’s not feasible to read the source code for every application I run now, so anything that makes sandboxing convenient and simple is very much appreciated


Given that Edge is a fork of Chromium, this isn’t likely to be the tectonic “ditching Electron” announcement that people will probably expect, looks like Teams will still be written in TypeScript, etc

Microsoft does have optimisations and other features in Edge that are not (yet) in Chromium and thus not in Electron, so this is still a good move


It’s not a drop-in alternative, it has a drastically different standard library and APIs

It’s still JavaScript/TypeScript, so code that manipulates data structures or parses strings or whatever will be fine, but code that touches I/O or other OS stuff pretty much needs a rewrite

Dependencies work kinda’ similar to in Go: you have full URLs (or relative URLs) in your import ... from ... statements, and the deno runtime goes and fetches them (or reads them from a cache if you’ve instructed it to pre-cache things, like you might if building a docker image or something)


Bundle the needed libraries inside the app package, or otherwise prevent them from being globally visible to other apps, and not make it easy for users to directly install them


I disagree somewhat, but I’ll make a distinction between libraries and directly-executed self-contained packages (e.g. apps, binaries, tools, etc)

I agree with Drew DeVault when it comes to apps, even though I personally prefer to use flatpak as much as possible, and only use a distribution’s package for an app as a last resort

However, I think it’s a mistake for any distribution’s own repository to include library packages that are more “officially” available elsewhere

It is bonkers to me the effort that distributions waste by packaging up libraries from rubygems, npm, pypi, or elsewhere, especially since the distribution’s copy will inevitably take longer to get security fixes than upstream

Not only that, but these distribution copies will be installed globally and can be found by that tooling if it happens to be installed, leading to all sorts of conflicts that new Node.js / Python / Ruby developers trip over time and time again



I’m not a lawyer, but my understanding of GPL is that the requirements are only triggered if you distribute your software

Twitch’s back-end code (server code) is never distributed to customers/users, so it ought to be completely fine to use GPL code in any way they want

Twitch’s front-end code (desktop apps, web apps, mobile apps, etc) would count as distribution, so any use of GPL code here would have to comply with the license

If an open-source developer wants to protect their code from the back-end code loophole (increasingly important as software-as-a-service becomes the dominant software use case) then the Aferro GPL (a.k.a AGPL) is probably what you’re after, as those requirements count network connectivity as distribution


Technology, finance, startup culture — all of these communities have developed their own language, with slang and jargon so common that they’ve passed into wider use. (What is a “platform,” anyway?) …


Pin, Unpin, and why Rust needs them

Using async Rust libraries is usually easy. It’s just like using normal Rust code, with a little async or .await here and there. But writing your own async libraries can be hard. The first time I tried this, I got really confused by arcane, esoteric syntax like T: ?Unpin and Pin<&mut Self>. I had ne…


Those who have opposed climate science’s conclusions—they’re a broad menagerie, including scientists in different fields, politics-obsessed bloggers, and think-tank employees—have also been squawking long enough for predictions to be tested. Despite their alternate-reality insistence that climate …


Not sure why this is tagged “NSFW”, haha


These are good online tips for anyone risking harassment or threats to physical safety…

18

In addition to memory-safe languages like Kotlin and Java, we’re excited to announce that the Android Open Source Project (AOSP) now supports the Rust programming language for developing the OS itself. …