~samwhited

Atlanta, GA

https://blog.samwhited.com

~samwhited/mellium-devel

Last active 2 months ago

~samwhited/public-inbox

Last active 1 year, 5 months ago

~samwhited/mellium-patches

Last active 1 year, 5 months ago

~samwhited/mellium-announce

Last active 1 year, 5 months ago

~samwhited/mellium-discuss

Last active 1 year, 5 months ago

~samwhited/soquee-announce

Last active 1 year, 5 months ago

~samwhited/soquee-devel

Last active 1 year, 5 months ago

~samwhited/soquee-discuss

Last active 1 year, 5 months ago

~samwhited/patches

Last active 2 years ago

~samwhited/terraform-provider-sourcehut

Last active 2 years ago
View more

Recent activity

Re: [PATCH xmpp] internal/ns: move a few namespaces to correct packages 2 months ago

From Sam Whited to ~samwhited/mellium-devel

Thanks again! Feedback inline:

On 2021-07-31, Dane David wrote:
> diff --git a/internal/xmpptest/session.go b/internal/xmpptest/session.go
> index 093c5ed..9bcff92 100644
> --- a/internal/xmpptest/session.go
> +++ b/internal/xmpptest/session.go
> @@ -8,11 +8,11 @@ package xmpptest // import "mellium.im/xmpp/internal/xmpptest"
>  import (
>  	"context"
>  	"io"
> +	"mellium.im/xmpp/stanza"
>  	"net"
>  	"strings"

[PATCH xmpp] blocklist: add basic client functionality 4 months ago

From Sam Whited to ~samwhited/mellium-devel

Signed-off-by: Sam Whited <sam@samwhited.com>
---
 blocklist/blocking.go      | 139 ++++++++++++++++++++++++++
 blocklist/blocking_test.go | 193 +++++++++++++++++++++++++++++++++++++
 2 files changed, 332 insertions(+)
 create mode 100644 blocklist/blocking.go
 create mode 100644 blocklist/blocking_test.go

diff --git a/blocklist/blocking.go b/blocklist/blocking.go
new file mode 100644
index 000000000000..0dc916d4246b
--- /dev/null
@@ -0,0 +1,139 @@
[message trimmed]

Re: The existing protocol for "What should the next chat app look like?" 6 months ago

From Sam Whited to ~sircmpwn/public-inbox

XMPP is extremely widely  used, has a plethora of working clients and
servers, and meets most of the requirements you outlined in your thread.
If by "failed" you mean "Google Talk doesn't use it anymore", fine, it
failed, but otherwise it seems to be succeeding quite well.

We need something new in terms of the app perhaps, but there's no reason
that can't be built on an existing network that's already good enough
(like Snikket is trying to do, or Quicksy, or any other "future app"
which could be the next thing).

—Sam

On Wed, Apr 7, 2021, at 15:06, Drew DeVault wrote:
> XMPP is a mess, and it has failed. A workable system cannot be pulled

The existing protocol for "What should the next chat app look like?" 6 months ago

From Sam Whited to ~sircmpwn/public-inbox

I know you (Drew) have mentioned that you don't personally love XMPP,
but I'd wanted point out that some systems built on top of it already
meet most of the requirements you outline in this post. In fact, while
reading the post I briefly thought you were specifically describing XMPP
and leading up to mentioning it as the protocol on which to build the
"next chat app".

The protocol itself has its problems (XML is a nightmare, extensibility
causes problems, etc.), and of course it has all the problems that come
with a federated platform (you either become so bloated that there can
only be one or two implementations like Matrix and it ends up defacto
centralized, or you remain distributed but you end up with clients that
support different optional features and the fallback can be difficult)
but overall it's firmly in the category of "good enough" in my opinion

Re: UI Feedback on Builds 10 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

My manifests are all submitted by Git, I don't put them in manually.

—Sam

On Tue, Dec 1, 2020, at 21:48, jack@jpgleeson.com wrote:
>
> Would using the notes box when entering the manifest work for you
> here? It puts the text just below the id of the job, not as
> immediately readable as the headers above, but definitely apparent.
>
>

-- 
Sam Whited

UI Feedback on Builds 10 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

Hi,

I'd like to suggest adding a title to the build pages pulled from
the manifest, or possibly just the build manifest filename somewhere
on the page.

Some of my projects launch several builds that run in parallel and have
similarly named tasks, so the pages appear the same and I can't tell
which builds I'm actually looking at. Having it say "Integration Tests"
or "Unit Tests" at the top (or whatever the case may be) would be
extremely helpful.

I'm posting here for discussion per the instructions on the issue
tracker.

Re: Feature request: Count files containing "LICENSE" in the name as a valid license 11 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

It won't help you with hating having a license at all, but you might be
interested in the Center for Plain Language
(https://centerforplainlanguage.org/). The TL;DR is that there's nothing
magical about legalese, and no reason to continue using it, people just
do because they don't want to risk their words being twisted and used
against them when they could use a tried and true formulation that's
been litigated and is well understood. The Center for Plain Language
advocates for using normal language in the law.

—Sam

On Sun, Nov 8, 2020, at 15:36, ValleyKnight wrote:
> I can't stand license-speak, I can't stand copyright, and I truly
> can't stand having to use a license at all.

Re: Building with multiple language versions 1 year, 1 month ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

FWIW, the last time I caught something like this was very recently. I
always support the last two releases of Go per their support policy, and
recently found a bug that occurred because of a change to the standard
library in Go 1.15. This also isn't a one off, it's fairly common for me
to find minor breakages between versions, especially in more complicated
packages like the net package. The recent preemption changes a version
or two ago also caused a lot of issues to be found that I wouldn't have
seen if I weren't running tests on a version that didn't have the
changes as well.

—Sam

On Mon, Aug 31, 2020, at 09:01, Drew DeVault wrote:
> Another option is to not build for multiple language versions. When

Re: Do not rebuild same commit? 1 year, 3 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

You definitely don't want to prevent a rebuild if the hash has changed
because the underlying source may still be different and the unchanged
patch may react differently with different code in other parts of the
code base causing failures that have now been skipped.

—Sam

On Tue, Jul 14, 2020, at 08:32, Drew DeVault wrote:
> Also, after you merge or rebase commits from your feature branch to
> master, their hash changes. So now we're deep comparing commits, and
> we have to store the full patch somewhere instead of just the sha to
> know that we've already built it.
>

Re: RFC: Antipolitical Software Manifest 1 year, 3 months ago

From Sam Whited to ~sircmpwn/free-writers-club

If you have more than 1 person working together on something, it's
political. Pretending to be a-political is itself a political statement.
You can't escape it by putting something in your license. License
proliferation and using it to enforce your political beliefs (which are
apparently that software should not be a force for change in the world,
which is itself a political belief) is probably much more dangerous than
the Rust team including a BLM banner on their site or whatever it is
that's made you write this.


—Sam

On Sat, Jul 4, 2020, at 08:25, Philipp Stanner wrote:
> Hi!