back in the day at $bigcorp when someone said ‘backend’ they meant the database. everything was in stored procedures and materialized views and I felt it was very difficult to work with.
I can’t think of any names right now but I’m sure I’ve heard of cases in the past where some project officially declaring itself halted has been sufficient impetus for a fork to emerge with new maintainers, even when a call for maintainers hadn’t succeeded before.
I think there are some libraries that are better than some of the gorilla components, but there are some gorilla libraries that I haven’t seen many other options for. A lot of things use gorilla sessions. I found another session library I like the design of, but the docs are really unhelpful/nonexistent.
That is to say, I can see some parts of gorilla getting forked.
I’ve also seen a situation where declaring a project halted has cased other people to step up as maintainers, avoiding the need for a fork where the original developers are willing to bless the new owners.
I’m sure that could do the same job. Though I’m not a big fan of general purpose mocking libraries. In my view, they add a lot of complexity and often make tests more brittle.
I also don’t like the approach that particularly library takes of modifying net/http‘s DefaultClient. It means it’s impossible to run multiple tests in parallel.
Although apart from that, it’s using the same basic technique I use in the video: Setting the http Transport for testing purposes.
I really wished cities names were written out on this map, as I
live in a large black sea (I live in a rural environment, 100+ km
to my nearest city) with a few green dots in it, of which one
should be where I live. There’s so little detail on the map that I
just can’t find where I live. :-)
It is easy to see where the border to the west goes (Norway) and how much they’ve spent on infrastructure for everybody :D It’s harder to see the border to Finland, and their border to Russia, but at least Murmansk is marked on the map.
This is exactly why I refuse to use npm, pip, etc. I only use the OS’s package manager, which uses a cryptographically signed package repo. I absolutely hate these hacks of workarounds.
I’m sure there are. And I hate that. But at least it’s going through my OS’s package manager, making it easy to use a single interface for auditing potential security issues.
The issue is that sometimes you’re much much behind. For example python-cryptography is still stuck at 3.2.1 on RHEL8…
So either you use pip… or a very old version…
Fortunately, that’s not an issue I have being a BSD user using the nearly-always-up-to-date ports tree. I enjoy up-to-date software on a regular basis. Minimal lag between when a project’s release is published and when the ports tree gets updated to the new version.
The problem with per-language package repos like npm is that anyone and everyone has access to upload their project. That inherently means users must trust the most malicious of developers who upload malware to the repo.
In the case of FreeBSD ports, the ports tree is gated by FreeBSD developers who have the opportunity to audit every single part of creating new ports or updating existing ports. It’s much easier to place trust in a (relatively) small set of developers who ensure sanity before committal.
The package manager I use for my system (FreeBSD’s pkg) makes it incredibly easy to audit packages, even checking something called VuXML to check if any of your installed packages have known vulnerabilities. I can see which files (config, lib, application, etc.) have changed from their default since pkg tracks hashes for each file it installs. Additionally, the package repo itself is cryptographically signed so that it’s not possible to inject malicious code in transit. If the server hosting the package repo is compromised, there’s no problem since the private crypto key material is stored elsewhere. And this bit of crypto is protected by the OS itself.
That’s fine in theory, but when someone packages a program for FreeBSD that uses a language-specific package manager, they use the built-in infrastructure in the ports tree that downloads the dependencies, then packages them in distfiles and records their hash. This is no more secure than pulling from upstream directly. The folks that package things for FreeBSD aren’t auditing the upstream any more than npm / pip / gem / whatever does.
The only thing that the signature gives you is an attestation that the package was built on a FreeBSD build machine and has not been tampered with between there and you by anyone who did not have access to the signing key. It does not give you any assurance that the build machine wasn’t compromised or that there weren’t supply-chain vulnerabilities upstream from the builders.
Most FreeBSD packages don’t use reproduceable builds, so you don’t have any assurance that your packages contain the code that they claimed they did: if you try to rebuild locally from the same port, you may or may not get the same binary. Is the one you got trojaned? Who knows.
pkg audit is great, but npm and friends have similar things that tell you if there are published vulnerabilities in their libraries. They have two problems:
They tell you only about published vulnerabilities. Good projects will go through the process of getting a CVE assigned and doing coordinated disclosure. Others just push out a new version. The auditing tools tell you only about the former.
They are very coarse-grained. They don’t let you know if the vulnerability in a library is on a code path used by anything you have installed and they don’t let you know if that codepath (if it is reachable) is using any data that can be influenced by an attacker. So pkg audit shows a vulnerability in curl’s URL parsing. Does it matter? Is curl used only with trusted URLs? Maybe it’s fine, but can a server-side redirect trigger it?
Sometimes minutes. Sometimes hours. Sometimes days. It depends on the time and resources of a volunteer-run project. For example, I’ve seen FreeBSD update the Tor port just minutes after a new release. FreeBSD generally updates Firefox to RC releases so that we can test what will be the next version before it comes out (which means we have a negative time window in this particular case.)
One person’s “too often” is another’s “they fixed my bug quickly, I didn’t have to wait a year for another release”. In the extreme case, Pipewire gained what feels like most of its functionality and polish over the last year in pretty frequent updates.
Yes, and this brings out a very specific problem. I can’t use an LTS distro if I want some bleeding edge software (and for my work, I often need some), but I also can’t use a bleeding edge distro because I have to update stuff every day.
I think things like NixOS are solving this problem partially, I just can’t get myself to try it. (Plus I suspect there’s a tradeoff to be made even in this case).
Are you actually blocked on some very system-specific issue? Usually software doesn’t really depend on the distro - for specific apps you usually have the choice of: compiling it yourself, private repos, nix, containers, snap, flatpak, appimage, and possibly others.
But when I used a centos version of whatever, I remember some software in the repos being to old versions. I don’t remember it being as pronounced in Ubuntu LTS or mint, but still occasionally this world happen.
Nowadays I mostly run fedora, but that’s on the other side, daily updates.
it’s not clear to me how to open up the editor…
Click on the extension icon.
i prefer
-Eback in the day at $bigcorp when someone said ‘backend’ they meant the database. everything was in stored procedures and materialized views and I felt it was very difficult to work with.
Do you mind sharing what were some of the biggest pains you dealt with? And if possible, some of the things you liked too.
Go, because I felt stuck with supporting old apps written in Perl
I can’t think of any names right now but I’m sure I’ve heard of cases in the past where some project officially declaring itself halted has been sufficient impetus for a fork to emerge with new maintainers, even when a call for maintainers hadn’t succeeded before.
I think there are some libraries that are better than some of the gorilla components, but there are some gorilla libraries that I haven’t seen many other options for. A lot of things use gorilla sessions. I found another session library I like the design of, but the docs are really unhelpful/nonexistent.
That is to say, I can see some parts of gorilla getting forked.
I wouldn’t say
gorilla sessionshas good docs. I found this alternative: https://github.com/alexedwards/scsscsis pretty good. It’s made by the author of the Let’s Go and Let’s Go Further books which are solid books on building web services in Go.Axios I think went through this, and src-d/go-git
Thanks
I’ve also seen a situation where declaring a project halted has cased other people to step up as maintainers, avoiding the need for a fork where the original developers are willing to bless the new owners.
Really cool idea. Do you have plans on supporting custom S3 compatible servers ( like user instances of MinIO)?
We currently support:
In the next update I will include a few more and hopefully an option to enable totally custom ones including MinIO.
Would be interesting to see what the upgrade involves.
how about this library: https://github.com/jarcoal/httpmock
I’m sure that could do the same job. Though I’m not a big fan of general purpose mocking libraries. In my view, they add a lot of complexity and often make tests more brittle.
I also don’t like the approach that particularly library takes of modifying
net/http‘s DefaultClient. It means it’s impossible to run multiple tests in parallel.Although apart from that, it’s using the same basic technique I use in the video: Setting the http Transport for testing purposes.
https://play.battlesnake.com/
I really wished cities names were written out on this map, as I live in a large black sea (I live in a rural environment, 100+ km to my nearest city) with a few green dots in it, of which one should be where I live. There’s so little detail on the map that I just can’t find where I live. :-)
Click on the eye in the legend to toggle the overlay. You’ll see the original map names this way.
It didn’t help :-)
For some context, I live in the circled region in this screenshot, https://imgur.com/a/eOPmAu6
It is easy to see where the border to the west goes (Norway) and how much they’ve spent on infrastructure for everybody :D It’s harder to see the border to Finland, and their border to Russia, but at least Murmansk is marked on the map.
very useful in debugging API calls from a phone, for example
How is the WebSocket support (mentioned on that page)? The protocol I use is based on WebSockets.
phone calls over the internet taste good and go down smooth. just take a SIP.
I wouldn’t consider SIP a small protocol, especially if you include the extensions.
As someone who works in SIP daily and pays my bills, I agree wholeheartedly. It is far from being small.
As someone who will never work with SIP voluntarily again, I completely agree.
This works as a dad joke too. Cheers
shoveling, working on finishing renovating my office room, playing video games
It reminds me of https://litestream.io/
It does, but different! It’s specifically called out in the README.
This is exactly why I refuse to use npm, pip, etc. I only use the OS’s package manager, which uses a cryptographically signed package repo. I absolutely hate these hacks of workarounds.
And you are sure that zero packagers use NPM or pip as a source for the OS packages and not the source repo? (Am I being paranoid now?)
I’m sure there are. And I hate that. But at least it’s going through my OS’s package manager, making it easy to use a single interface for auditing potential security issues.
The issue is that sometimes you’re much much behind. For example python-cryptography is still stuck at 3.2.1 on RHEL8… So either you use pip… or a very old version…
Fortunately, that’s not an issue I have being a BSD user using the nearly-always-up-to-date ports tree. I enjoy up-to-date software on a regular basis. Minimal lag between when a project’s release is published and when the ports tree gets updated to the new version.
How is this different than using pip? You manually download the file?!
The problem with per-language package repos like npm is that anyone and everyone has access to upload their project. That inherently means users must trust the most malicious of developers who upload malware to the repo.
In the case of FreeBSD ports, the ports tree is gated by FreeBSD developers who have the opportunity to audit every single part of creating new ports or updating existing ports. It’s much easier to place trust in a (relatively) small set of developers who ensure sanity before committal.
The package manager I use for my system (FreeBSD’s
pkg) makes it incredibly easy to audit packages, even checking something called VuXML to check if any of your installed packages have known vulnerabilities. I can see which files (config, lib, application, etc.) have changed from their default since pkg tracks hashes for each file it installs. Additionally, the package repo itself is cryptographically signed so that it’s not possible to inject malicious code in transit. If the server hosting the package repo is compromised, there’s no problem since the private crypto key material is stored elsewhere. And this bit of crypto is protected by the OS itself.That’s fine in theory, but when someone packages a program for FreeBSD that uses a language-specific package manager, they use the built-in infrastructure in the ports tree that downloads the dependencies, then packages them in distfiles and records their hash. This is no more secure than pulling from upstream directly. The folks that package things for FreeBSD aren’t auditing the upstream any more than npm / pip / gem / whatever does.
The only thing that the signature gives you is an attestation that the package was built on a FreeBSD build machine and has not been tampered with between there and you by anyone who did not have access to the signing key. It does not give you any assurance that the build machine wasn’t compromised or that there weren’t supply-chain vulnerabilities upstream from the builders.
Most FreeBSD packages don’t use reproduceable builds, so you don’t have any assurance that your packages contain the code that they claimed they did: if you try to rebuild locally from the same port, you may or may not get the same binary. Is the one you got trojaned? Who knows.
pkg auditis great, but npm and friends have similar things that tell you if there are published vulnerabilities in their libraries. They have two problems:pkg auditshows a vulnerability in curl’s URL parsing. Does it matter? Is curl used only with trusted URLs? Maybe it’s fine, but can a server-side redirect trigger it?How minimal?
Sometimes minutes. Sometimes hours. Sometimes days. It depends on the time and resources of a volunteer-run project. For example, I’ve seen FreeBSD update the Tor port just minutes after a new release. FreeBSD generally updates Firefox to RC releases so that we can test what will be the next version before it comes out (which means we have a negative time window in this particular case.)
So basically the same boat as rhel then
Agree, upgrades are annoying. Some software more then other. Like Fedora vs OpenBSD (Fedora’s kernel and other packages are updated too often).
Not sure about this one though:
One person’s “too often” is another’s “they fixed my bug quickly, I didn’t have to wait a year for another release”. In the extreme case, Pipewire gained what feels like most of its functionality and polish over the last year in pretty frequent updates.
Yes, and this brings out a very specific problem. I can’t use an LTS distro if I want some bleeding edge software (and for my work, I often need some), but I also can’t use a bleeding edge distro because I have to update stuff every day.
I think things like NixOS are solving this problem partially, I just can’t get myself to try it. (Plus I suspect there’s a tradeoff to be made even in this case).
Are you actually blocked on some very system-specific issue? Usually software doesn’t really depend on the distro - for specific apps you usually have the choice of: compiling it yourself, private repos, nix, containers, snap, flatpak, appimage, and possibly others.
Nothing specific, just a small rant.
But when I used a centos version of whatever, I remember some software in the repos being to old versions. I don’t remember it being as pronounced in Ubuntu LTS or mint, but still occasionally this world happen. Nowadays I mostly run fedora, but that’s on the other side, daily updates.
New job, onboarding
Long weekend, removing carpet in a bedroom to install hardwood floors and fixing a few things in between.
Let’s read it before it gets removed
I wonder if the post is will be deleted by the powers to be…