OmarAssadi

Yeah, I haven't yet taken a serious look into it from that perspective yet, but similar came to mind; while, outside of bootstrapping the JDK from GCJ, Boehm GC hasn't been super relevant to me for "release" builds of anything, it's been useful in leak detection mode on occasion.

I figure even if you cannot use, or do not want to use, something like Fil-C in production, there's solid potential for it to augment whatever existing suite of sanitizers and other tools that one may already build against.

Nothing stopping you from using one with totally modern systems as well, except for the ever increasing prices, I guess. Anyway, yeah, same as some of the others already mentioned, but I don't think I actually owned any sort of standalone display—be it a monitor or television—that wasn't CRT until ~2009 or so?

I used my mom's iMac G3 (CRT) probably until 2004 or so, because I distinctly remember getting stuck on Tutorial Island on RuneScape as a kid, since you had to Right-click -> "Prospect Rock", and at the time, I had no idea how to actually do it with Apple's single-button mice lmao.

Aside from the couple of laptops that came later, I don't think I had moved on [for the worse] until a bit after I put together my first DIY computer (Phenom II 920, etc); I still had a CRT TV in my room long enough to have been using it when Halo Reach came out.

Do you happen to have any examples, if you're allowed to share and comfortable doing so?

Always found differences in teaching styles and curriculum interesting as is, but I am curious about how others are balancing the new additional challenges of combating LLMs without making the material significantly more difficult to understand.

I mean, I agree that you should be able to avoid things like Netflix and make use of libraries and other archives, but that's sort of the point; there is a ton of media that never even gets a physical release anymore; once one of these platforms goes under, or something enters licensing hell, or whatever else and gets removed, all you can do is hope someone out there with both the know-how and access went out of their way to illegally download a copy, illegally decrypt it, and illegally upload it somewhere.

I say "know-how" and "access" because, while I'd still argue decrypting, say, Widevine L3 is not exactly super common knowledge, decrypting things like 4K Netflix content, among other things, generally requires you to have something like a Widevine L1 CDM from one of the Netflix-approved devices, which typically sits in those hardware trusted execution environments, so you need an active valuable exploit or insider leaks from someone at one of the manufacturers.

But also on top of all of that, you also need to hope other people kept the upload alive by the time you decide to access it, and then you also often need to have access to various semi-elitist private trackers to consistently be able to even find some of this stuff.

The legal issues with DRM here are hardly exclusive to Netflix and other streaming services, but at least in the case of things like Blu-rays or whatever — even if it is technically illegal in most countries to actually make use of virtually any backed-up disc due to AACS — you usually don't have the same time-pressure problem nor the significant technical expertise barrier.

If streaming services like Netflix are harmful then we should avoid using them. Thus it should not be important for our freedom-preserving computers to be able to access Netflix.

I generally do avoid them whenever possible, though, yes. And I've explicitly disabled DRM support in Firefox on my computer. But I am just one person and I don't think my behavior reflects the average person, for better or for worse.

Sure, Netflix may not be as important as, say, housing, food, or whatever else, but I think there is something to be said about the cultural importance of [at the very least some] film and television.

There's a lot of media worth studying, analyzing, and preserving. And in that sense, between the constant churn of catalog items, exclusive content, and the egregious DRM, I think these sorts of streaming services are, unfortunately, kind of harmful.

Personally, it is one of the flags, yeah. It's been a while since I've tried ChatGPT or some of the others, but the structure and particular usage felt a lot like what I'd have gotten out of deepseek.

It's not a binary thing, of course, but it's definitely an LLM smell, IMO.

Early into high school, I needed something to take to class, but since I already had a decent desktop at home, plus we were broke, I picked up some cheap Asus K55N; AMD A8-4500M, 4GB DDR3, etc -- nothing particularly fancy; only upgrade I did to it was removing the mechanical hard drive and swapping in my old 120GB Corsair Force GT.

I eventually upgraded, went off to university, etc. When I finally came home, I found out my mom apparently "borrowed" it, figured out how to install Ubuntu, and has been using it ever since for grading papers and what not.

No idea how much longer it will remain in use, but aside from the awful screen, ironically, honestly, I think the browser and the seemingly ever increasing resource requirements of the web will eventually be the only thing that finally causes an upgrade.

Oops, realized too late that I deleted a sentence by accident; I gave the GPU to my younger brother.

I feel that.

It's difficult to justify any new hardware until I'm in a better place; while it'd be nice, I'm not suffering enough to /need/ a new system.

Until the beginning of 2020, during university, I was still on a 3930K from launch-day in ~2011 and GTX 680. Honestly, I'm not sure I would've bothered if it weren't also for the fact that I wanted to be able to test AVX2 implementations of some of my code without relying on an emulator or someone else's machine every time.

It probably helped that I mostly only care about Source games and RuneScape. But I haven't really played anything since my ex-girlfriend and I broke up in ~2022.

I took his RX 480 to have a display-out and gave him my 2070 Super so it wouldn't go to waste.

There is something beautiful about how U.S. news outlets were always going on about how Russia is a dictatorship, with rigged elections, where you'll be beaten, arrested or killed for protesting or speaking out--Russians supposedly have no agency. And yet simultaneously, now, Russians apparently must be held accountable for everything their government ever does, because they "voted him in" or "should overthrow Putin".

We can't have it both ways. Either Russia is a functioning democracy (which I don't personally believe exists anywhere but that is another topic), or perhaps the average person does not actually have very much say in such events.

Sanctions are meant to harm innocent people as much as possible, on purpose, with the idea being that it will cause so much unrest that the government either caves to the pressure or the people revolt. While I find that very sick in and of itself, I would at least appreciate it if we were honest about that rather than making contradictory moral statements.

That said, worse yet, almost hilariously, I cannot think of a single time sanctions have ever truly worked in a situation even remotely similar to that of Russia. Just think about countries like North Korea, Iran, Cuba, Syria, etc -- like it or not, these countries have not toppled as a result of the sanctions. Do they hurt? Yes, of course, but they evidently do not destroy nations the way we believed they would.

Instead, the innocent are hurt, as was the intention, yet the goal never gets achieved. North Korea still has nuclear weapons, and all we've done is force Iran to develop its own industry, such that, ironically, it is now capable of sending weapons to aid Russia.

I did already write my own comment trying to ask about the goals and state of Anvil when compared to Acme. That said, RE: "Emacs/Vim on one end and VS Code on the other" and "... you need to come up with something totally transcends the way we write" -- the latter is actually the reason why I was genuinely curious.

I haven't had the time to give Acme a proper try myself, so who knows whether I'd hate it or love it or what, but it only took a few minutes of Russ Cox's little introduction video [1] on Acme for me to go, "Whoa, that is unique"; half the concepts gave me a near-instant visceral feeling of simultaneously being disturbed yet also somehow delighted.

I am really unhappy with the direction of modern UI design, and much of software in general, but sometimes I wonder how much of my feelings are truly objective, how much is my own bias, and how I would feel if I grew up in a totally different environment with different stuff. I've kind of always been curious in that sense, if you took a group of people who somehow had been totally isolated from not only computers and software, but our various cultural biases, what would they find to be the most intuitive, and what sort of things would they come up with?

In a similar sense, for better or for worse, that is almost how I felt seeing Russ use Acme; it looked like an editor built by aliens for other gremlin-like aliens.

I can't confirm or deny whether the aliens are right about their editing paradigm, but it is at least something much closer to "transcending the way we write (ascii) text" than most, and so it's cool to see Anvil is at least drawing inspiration from that rather than, say, yet another VS Code.

[1] https://www.youtube.com/watch?v=dP1xVpMPn8M

While looking into Acme several months back, I actually bumped into this; there just don't seem to be many editors that draw inspiration from Acme's workflow rather than borrowing from things like Vim, Emacs, or more traditional mouse-based GUI editors -- e.g., Notepad++, Sublime, Kate, VS Code, etc -- so Anvil popped up pretty much instantly while searching around for similar concepts.

However, as someone who hadn't, and unfortunately, still hasn't, spent a load of time using Acme, it wasn't super clear to me how they differentiate from each other. I wasn't totally sure whether it was more of a clone made for fun of it, or whether Anvil was trying to solve a genuine issue that Acme wasn't, or was trying to solve in its own distinct way, or perhaps trying to address a gripe with Acme itself, etc.

If anyone working on the project could highlight some of the differences in features and goals, or if anyone who has used one or the other long enough to notice some stuff at a glance, it'd be super helpful as an outsider to both. Superficially, I do see syntax highlighting, but I figure there's probably more going on than that.

Also, is there any sort of publicly accessible version control? I see the source archives, but I couldn't find any sort of mention of git or any other vcs.

FWIW, by the way, I hope asking about a comparison doesn't come across as some sort of dismissive, "what's the point", comment; it was just cool and interesting enough that this isn't the first time I've wanted to ask.

Bear in mind that "invasive tracking" is also used for protection of the vulnerable.

If we're going to go down the "think of the children" path, I'd argue invasive tracking is used far more often for persecuting the vulnerable. But anyway, if you want an ultra locked-down machine for schools running Apple devices, use MDM, Santa or whatever else, and network filtering like everyone else.

I'm getting very tired of the idea that we need to bend to ad agencies and absurd government abuse in the supposed name of protecting the innocent. It's suffocating for everyone.

Some people online are strange and scary no doubt; I know that better than anyone. But kids will be kids, and they'll do dangerous things without you knowing; people go home and talk to strangers on Discord or whatever else all day and no amount of browser fingerprinting is going to change that.

Maybe I am the crazy one, though, I don't know. But I only learned to program because I wasn't caged up; I couldn't have been older than six years old or so when my friend introduced me to this MMO, RuneScape, which I became obsessed with. And like all dumb kids, I eventually tried to look for cheats, of course, there were none, but I stumbled upon some reverse engineering forums where people were collaborating and trying to build their own server emulators for the game. It was interesting, so I stuck around, and it incrementally forced me to learn just about everything I could really need -- from software to things like "oh gosh, we've suddenly got players, but now we're getting slammed by some dude's botnet; I am twelve and BlackLotus wants $500 a month for a server with any sort of DDoS mitigation, so we need to figure out how to deal with this on our own".

I had good times, and I had many terrifying times, but at the end of the day, my life would be entirely different if I grew up sheltered and shackled to an iPad with no way to truly investigate the things that interested me. I'm very glad I stole my mom's PowerBook to stay up all night in the vBulletin shoutbox with people no sane person would normally want their child hanging around.

I was right about to go to another site and had to do a double-take when my eyes caught the title; I hadn't thought about her in YEARS. I hope it's boxxy on purpose.

I don't reject HTML email, but I always have my client set to read plaintext. 99% of the time, the worst thing that occurs is simply some garbled hyperlinks for a verification email or similar.

Personally, I don't have any need for HTML email in my daily life, and the only emails I occasionally get that are very obviously 'broken' in some way in plaintext mode are usually marketing emails or other messages I don't want to read in the first place.

So, I figure, may as well keep it disabled since plaintext is more consistent and easier to read, and there is significantly less surface area for exploits when you don't need to bundle half a browser to view a couple of paragraphs.

Tangent, but out of curiosity, what was the more important goal in your mind/whoever else was involved? The ability to relink with newer/patched libraries, or simply the ability to inspect/modify the LGPLed code?

I have a love-hate with the ultra-permissive licenses; on the one-hand, philosophically, I think I prefer the idea of trusting the recipient to just not be an asshole, but at the same time, I recognize [1] that corporations [which tend to prefer permissive licenses] don't always have the best interests of everyone in mind.

Even in ideal cases, like how the LLVM community tends to at least see LLVM most of the LLVM forks patches--even if they are not accepted--simply because it's effort to maintain a downstream fork of something so fast moving, community-wise, I feel like Apache 2.0 and friends end up very different, perhaps corporate, in a way that I don't love.

For example, I used to wonder how GCC still had so much backing since LLVM is generally easier to work with, from my experience, no wild autotools insanity, etc. But after doing the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really appreciate the care taken to avoid constant churn to minimum C++ versions, support for obscure platforms, etc; it feels like LLVM sort of disregards anything that doesn't make a ton of visible economic sense [2], which makes the bootstrapping process so much more awful by limiting the number of potential platforms plus requiring even more steps than GCC, which is brutal on its own.

Anyway, I guess I was wondering, if you were doing it all over again, would something like the MPL 2.0 perhaps have fit the bill better? One benefit of the LGPL, to me, of course, is that you should, in theory, be able to link against a different copy. But at the same time, I guess I am more concerned about the ability to allow useful libraries to remain in the hands of the users to modify than I am about them to be able to fix a bug whatever random proprietary program--worst case, if it's something entirely unmaintained, I can often binary patch whatever bug or similar.

I feel like the LGPL, while nice in theory, probably causes more harm [for me] relative to the MPL simply because people are [unnecessarily] afraid of potential implications with static linking, or perhaps cannot be bothered distributing individual object files alongside the static binary to allow relinking. So, we end up with people choosing non-copyleft alternatives or reinventing the wheel as proprietary software.

I have similar feelings with the less-selective GPL; we've ended up with the horrible situation of people distributing images that pull the entirety of the Ubuntu userspace just to emulate static binaries via containers.

Anyway, tangent over. Also, I wish there was a well-accepted CDDL/MPL 2.0-style license with a network distribution clause; I think I've become a fan of file-based copyleft as a good middleground, but it's annoying that there isn't a popular file-based copyleft license that takes into account AWS and similar.

EDIT: Also, I guess similar to what you already touched on RE: iOS. I feel like GPL 3.0 was probably a mistake. Presumably good intentions, but I feel like the hand was overplayed; it simultaneously went too far for companies like Apple to touch it, so we ended up with ancient Bash and GNU Make with gradual replacement of anything GPL, and yet also simultaneously not far enough to deal with cloud services, containerized RPC-style not-technically-linking-but-basically-linking distribution, etc.

[1]: Personal opinion -- I know this is a VC website at the end of the day and people will disagree with me. I don't really care to argue about it.

[2]: Not meant to be an attack against LLVM. And I know there are loads of independent developers and researchers working on it too. I hope my feelings don't get totally misunderstood.

You could still do mostly non-harmful no-JS PoW captchas by making some sort of FOSS external generator executable. Of course, this would be annoying to an extent, require mult-tasking for the user everytime, or custom keybinds, etc.

You could make it less annoying by borrow from TeamSpeak and/or hCaptcha. On TS3, as a server admin, you could set a minimum [pow-style] security-level to prevent spam/flooding. If server had a higher than default number, clients were prompted to improve their security-level or disconnect. And alternatively, as a client, you could pre-emptively generate higher/highest security-level (up to "30"?) over night or whenever you had spare cycles.

You could borrow that concept to allow non-JS clients to generate extra-strong tokens to allow them to bypass the system entirely. Or combinee that concept with what hCaptcha does for their disabled users -- once you solve the special disability captcha [or in this case, generate a stronger token], rather than inflict extra pain on the users, you get granted ~20 tokens or so to allow you to avoid the normal captcha system for a decent period of time.

If you want to go the extra mile and account for no-cookie use in addition to no-JS, allow it to be sent in the auth header or something.

Anyway, I don't know how many things I've seen use the concept, but IMO, it's under-utilized.

As a kid, I was super into reverse engineering RuneScape and writing our own MMORPG servers based on the protocol. Most of us had no idea what we were doing or what the games industry was doing, and we were all mostly kids, so we all had to be our own developers, db admins, sys admins, etc, and DDoS mitigation was effectively non-existent until OVH democratized it (BlackLotus would charge like $550 a month for a mediocre dedicated server, Staminus was similar, AwkNet was cheaper but only did TCP so TeamSpeak etc was still vulnerable, etc - and god knows how much Akamai and similar would've wanted).

One of the billion issues people ran into often was just login flooding; if it was a new username, that'd mean forcing the server to go through the new account and serialization process, and if it were an existing account, it A. opened up bruteforcing but B. forced the server to, at the very least, do password hashing, possibly database queries, or commonly reading a character file from disk, etc.

Rate-limiting by IP isn't super effective, because proxies. Rate-limiting / straight-up banning certain ASNs worked better to deal with VPNs, but you can't exactly grind all of Comcast or Verizion to a halt without disrupting users. And rate-limiting the particular account sucks, because you run into situations where individual players get targeted and effectively locked out of their account because someone is griefing them.

Far more effective than anything else was the idea of just generating some sort of PoW token on login that took a bit of time for the client to generate but was quick for the server to verify. Significantly better was the idea of being able to scale the difficulty globally, per IP/block, and importantly per account -- nearly no difficulty if no flooding is occurring, ~1-3 second logins if a massive flood is ongoing, or a per-account ~1-10 second difficulty if someone is trying to bruteforce a particular account. Even if the latter is mildly annoying, it's better than being totally blocked from playing.

RuneScape itself implemented this a couple of years ago too, I believe. I haven't seen them actually do much with the difficulty factor yet but even their super naive simple version seems to have helped a ton.

[of course this doesn't fix the issue of giant IoT botnets and stuff, but most people didn't (don't?) actually bother -- it was almost always DDoS amplification for volume and one or two servers with proxies doing the layer-7 floods]

It's been mostly fine for me as well, but that has only been the case because of things like Xwayland; there are a large number of styles of program that are either really difficult reimplement or simply can't work without it.

Multi-window programs, for example, are difficult to get working directly on Wayland. The issue has been brought up several times [1][2]. And it's not a particularly uncommon UI-style.

For example, most video production software I've worked with allows you to popout certain components into separate windows so that you can, for example, have your timeline, which may have many tracks taking up lots of vertical space, on a separate monitor from the preview viewport. This is a really nice feature. And the lack of its presence is one of the things I really dislike about DaVinci Resolve, despite it being an otherwise great tool with some of the best, if not the best, colorgrading utilities.

This isn't something unique and niche to video production either, though; lots of photo editing, audio production, 3D modelling, CAD software, and other scientific/engineering applications have similar UI. Wayland makes it difficult, though, because there isn't a good way to request or suggest the kind of positioning these programs need [1].

Anyway, that said, I, too, have lived with a mostly Wayland desktop for a few years without too many issues, even as someone who doesn't have the most "typical" workflows or needs. So, to an extent, I think you're not wrong; the idea that Wayland is *entirely* unusable is, obviously, not true.

But again, key point, *mostly* Wayland; without Xwayland or similar, I think it'd be genuinely unusable for me and likely many others.

While the compatibility layers genenerally work well, and in many ways, still provide many of the benefits of Wayland, like security, I don't think it's unreasonable to want a better, native way to deal with some of these issues so that people can drop the additional legacy abstraction.

---

[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...

[2] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...

Related:

- https://github.com/PCSX2/pcsx2/issues/10065

- https://github.com/mpv-player/mpv/issues/8692

---

EDIT:

I think it's also worth noting that just because /our/ Wayland experiences haven't been too bad doesn't mean that its the case for everyone.

As I, and several others, mentioned in other comments, there are several implementations of Wayland compositors, for example. Our particular choice of components/desktop environments might be fine, but others may be more broken or intentionally lacking support for useful/semi-necessary "optional" extensions to the protocol.

It'd be one thing to intentionally pick a bad implementation as a user and then complain about it. But sometimes, people aren't aware they're using Wayland in the first place, let alone which compositor they're using.

As a developer, even if you don't care for a particular implementation, unless you do as PCSX2 did, you'll still likely need to think about everyone elses' quirks as well, because too many of your users will also be users of whatever is most problematic -- e.g., GNOME is very popular and also has/had been one of the more annoying ones.

As noted by other commenters, there are several compositors available for Wayland (essentially the bit that actually implements Wayland).

Some are developed independently of any particular desktop environment--like wlroots, labwc, hikari, etc--but some are part of a larger project, such as mutter and kwin (GNOME and KDE, respectively). Most of the time you install some sort of GNOME/KDE + Wayland distro, you'll usually also end up with their compositors, and thus potential quirks specific to their implementations.

GNOME's implementation in particular has historically caused a lot of drama relative to some of the others -- be it due to purely accidental, broken support for something, or sometimes intentional opposition to a particular concept that many applications rely/used to rely on, like server-side window decorations [1].

The accidental issues that come with fragmentation of the ecosystem and the intentional decisions by different compositors to not support particular extensions/whatever, like the aforementioned, can cause a fair bit of pain for developers of end-user programs.

Users who may be totally unaware of the inherent differences between Wayland and X, who may not know that different compositors exist, who may not even know they are running Wayland, etc, inevitably run into strange issues, and then, understandably, file bug reports.

This can get old quickly under normal circumstances. But I imagine it sucks even more when you're maintaining software that is relatively understaffed given its importance. Outside of PCSX2, mpv would be a good example:

- It's incredibly popular software on its own, being probably the most popular open-source, cross-platform mediaplayer after VLC.

- It's also embedded and used as a base for other applications on a wide variety of systems, ranging from other open-source players that try to integrate more tightly with a given platform--e.g., IINA (macOS), mpv.net (Windows), etc--to proprietary, commercial software, such as a variety of Android players and, importantly, Plex, which uses mpv as the default backend on at least tvOS/iOS/iPadOS.

- It's software that needs to deal with pretty low-level graphics and audio stuff, so it's inherently a bit complex, and the available pool of potential contributors shrinks.

- It tries to be as lightweight as possible and allow for easy embedding into other applications and porting to different systems, so it has several things working against it:

-- It's mostly written in C, making it very easy to build and embed anywhere, but not only is C not the sexiest language in 2023 to many, it's also a hard language for someone without a good grasp to write safe, quality code, particularly for something like mpv.

-- It doesn't try to enforce a particular rendering backend--e.g., OpenGL, DirectX, Vulkan, Metal, software, etc--nor a particular UI toolkit. Again, great for someone building on top of it. But it makes things like the change from server-side decorations to client-side significantly more annoying / potentially fundamentally incompatiblew ith the project goals.

mpv sits in that perfect anti-goldilocks zone:

It's important enough to be a problem if it were to disappear, yet unlike the Linux kernel, not quite important enough to have the funding and hoardes of patches despite the project complexity. It's also low-level enough to need to worry about every display server and platform on the planet, yet not low-level/general enough to have a say in the design decisions (e.g., Wayland membership, I believe, is pretty much limited to compositors and UI toolkits - like QT/GTK).

All of that, and probably more, adds up to maintaining a surprisingly important, difficult project with relatively few developers but likely many millions of users, many of whom may not even know you exist; it's thankless yet important work.

As a result, unsurprisingly, in addition to the infamous locale rant [2] (unrelated to Wayland), mpv used to have a pretty spicy wiki section entirely dedicated to GNOME's Wayland implementation:

- https://github.com/mpv-player/mpv/wiki/FAQ/ddcbe1b88a99d2568... (2020)

This section still kind of exists, but it has been toned down a fair bit now that certian issues have been addressed [3]; it now mainly focuses on a couple of specific GNOME issues directly and more broadly addresses NVidia's poor Wayland support relative to some other vendors.

-----

[1] https://gitlab.gnome.org/GNOME/mutter/-/issues/217

[2] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...

[3] https://github.com/mpv-player/mpv/wiki/FAQ/a70c96040ad4fa374...

It's not usually hard to do, no, but it is >130K of C alone, excluding whitespace, comments, tests, examples, etc. I don't want it on my system from a security perspective alone.

Add in the bootstrapping pain it imposes due to autoconf and other stuff, I think there are many valid reasons to avoid it and choose another shell that is more auditable yet still has just as many eyeballs on it (e.g., mksh - the default on Android; dash - default on Debian; BusyBox - every embedded system).

Always use [[

While zsh, bash, mksh, ksh93, probably others have it, sure. But many don't -- and not totally irrelevant ones either. Debian's default, dash, for example, does not support `[[`.

IMO, unless you're writing something like shell-specific dotfiles, avoid non-POSIX features.

It's usually pretty trivial to avoid them, especially if you're willing to call other mandated commands like awk, etc. But often, with a bit of creative thinking, most non-standard features can be replicated with some combination of `set`, separate functions and/or subshells.

Shell scripts, in general, have dozens of footguns, are pretty much impossible to statically analyze, difficult to make truly robust, and many of the shells themselves -- e.g., bash -- have huge, borderline inauditable codebases.

I can think of a dozen reasons not to write shell scripts. Yet still, there is incredible value in the fact that some form of POSIX-compliant/compliant-enough shell can usually be found on most systems.

All of that value goes out the window, though, the moment you start relying on non-standard features.

I’m interested how you handle verbally communicating an address?

It depends on how off-guard I'm caught and how important it is to me. I usually have my phone, which has my KeePass and email salt inside, and I usually have at least enough battery to last a conversation, so it's rare that I can't generate the proper email address in <30 seconds in most scenarios.

But yes, having like, 5e5ee440@<domain>.<tld>, has definitely resulted in a few "can you repeat that?" or "just to confirm?" moments (especially over the phone since audio quality often sucks). That said, for whatever reason, people are still seemingly less surprised by "5e5ee440@" vs. "<your place of work>@".

On the rarer occasions where I don't at least have my phone or something, if it's something I know I can update later, I'll tell them whatever is easy to input and remember; I separate emails to unknown recipient addresses, but I don't completely reject them outright, so it's not usually an issue pulling out the confirmation email or whatever later, and then updating the address.

However, if I don't have my phone, and I don't know how easily I could update the email, then it depends more. For example, my doctor wants an email on file for whatever record-keeping reason and for sending appointment confirmations and such. In that scenario, I don't know that I'd necessarily be able to easily change it without going in/calling them.

The first time, I did give them <doctor's practice>@domain.tld, because I figure, despite being an important email, it's unlikely that it'd get abused; if someone somehow knows my GP's full name and practice, and is using it maliciously, I've probably got bigger worries than getting a phishing email sent to it or whatever else.

The second time, though, I just asked her to email me the contact update form and told her I'd send it back with the proper email inside.

I wonder if there could be an easy “word-sounding” generator that could be integrated into something to manage emails?

I figure you could do something similar to like the horse-battery-stapler XKCD meme or bitcoin wallet seed phrases, if you wanted to avoid the "sorry, can you repeat that?" moments.

But it might be slightly more annoying to deterministically generate those, if you care about that aspect, compared to simply salt+hash & truncate. If you find a good method, let me know, though.

I think since I use a password manager anyway, I could just generate a random 6-8 character prefix when signing up for a new account, and since it's saved in my password manager it's easy to look up again later (no need for a true hash).

Yeah, same. I store all the addresses in KeePass.

The main reason I don't just totally randomize them is just that there have been a few moments where I do have my salt somehow, but for whatever reason, it is either inconvenient or impossible to immediately open up the password manager and add a new entry.

In those moments, being able to deterministically generate the address and then add it at my leisure without having to double-check what I used is nice.

It also likely wouldn't happen to me, but should I ever somehow lose/lose access to both my old emails and my password manager, as long as I have my salt, I can still "remember" my email addresses for important services (e.g., PayPal or whatever) to re-generate the addresses and reset my passwords.

Whatever route you go, be it randomized addresses or hashed addresses, even though I think I am more vigilant and careful than most, it's still nice having an extra-layer to the catch-all that can't easily be targeted by someone malicious without first either somehow obtaining your salt, compromising the service, etc; it's handy being able to immediately filter and flag anything relating to my bank or whatever else if it isn't sent to the right address.

While it doesn't stop spam, I have been using a catch-all email system for a while now.

The benefit is that I know where someone got my email from, and I can then try to figure out whether the place has been compromised, or whether they're selling my email, etc. And I can just blacklist that particular address forever as well.

Previously, I just did whatever@mydomain.tld, but I've switched to something similar to blame.email [1].

This makes my emails look a little weirder, but it has stopped the weird looks I'd get when walking into a physical place, like my doctor, and telling them "Yeah, email me at <doctor's name>@<first><last>.com".

It also makes it less obvious that its effectively a throwaway email, particularly combined with my domain; it looks fitting. And since each address is salted and hashed, it pretty much eliminates the risk of someone successfullying trying to phish me by sending me an email to something like `paypal@<first><last>.com`.

Lastly, on my HN profile and elsewhere, I've got my "email", but despite them being unique, I still don't want to have to rotate it if it gets picked up by a spambot, so I've tried to do some plaintext simple "obfuscation" like in the article.

I went for <address> ~АТ~ <domain>.<tld> -- with the "AT" being Cyrillic rather than Latin - I figure at least some will get tripped up by not being able to use purely English regex.

So far, I have yet to receive any spam with that strategy. Maybe I'm lucky or just not getting indexed, or maybe it's working a little.

Still torn about how to handle Git or copyright/license headers, though; those addresses need to last a long time, in case anyone needs to reach out and ask for re-licensing/etc, and I figure it'd be annoying doing different emails for each repo.

[1] https://news.ycombinator.com/item?id=31820502 / https://blame.email/

The whole thing runs on regular servers. Hetzner has become our cloud of choice, along with Backblaze B2 and SQS. It is written in Go. From an architecture perspective I try to keep things simple - want folks to make economical use of their servers.

Cool, glad to see Hetzner, at least presumably for compute, rather than the almost routine, absurdly expensive, mega cloud providers.

I have a few questions if you've got time.

1. What made you pick Hetzner in particular, and did you evaluate any of their primary competitors? (e.g., OVH, etc)

2. In your $100/month figure, did you decide to go with dedicated servers or the "cloud" VPS line? If the latter, was there any particular reason over going with the bare-metal offerings?

3. Are you making use of Hetzner's U.S. servers as well or is everything currently in Europe (or vice-versa)?

4. Was there any particular reason for choosing B2 and SQS as opposed to self-hosting object-storage on the SX servers?

Normally, I wouldn't even wonder why someone wouldn't want the burden of more infrastructure. But given the choice of going with relatively unmanaged Hetzner servers, presumably self-hosting clickhouse, etc, and then with your compute provider also happening to offer fairly large storage servers on the cheap, I might've been tempted to cut out the additional providers and DIY it:

- less costly for large amounts of data

- zero lock-in [1]

- fewer companies to deal with

  - likely better negotiating power with Hetzner when the time comes if a bigger percentage of your overhead is with them as opposed to spread out across three providers

  - fewer points of failure; if the Hetzner servers are down, I would assume you're in trouble anyway, so perhaps keeping [most] of your eggs on the same network might not be as bad as it sounds

  - presumably better latency and bandwidth + the ability to communicate over a private network [2]

Was this just an oversight, or do you intend to be one of the few SaaS companies that really truly is open-source rather than "open-source" [until peopled are locked-in] and then going "open"-core? If the latter, then awesome -- cool to see.

6. Any regrets, disasters, or lessons learned so far? Usually, I find these stories the most interesting but unfortunately too few are willing to share.

---

[1]: I know B2 provides a relatively standard, at this point, S3-compatible API and everything as well. But I think there is also still something to be said about a somewhat Juche-esque approach to infrastructure, wherein should prices rise, contracts change, service degrades, or whatever else, you'd have the ability to almost immediately switch at a moment's notice to literally anyone else who can lease you a box with some hard drives or any colo provider.

[2]: This goes out the window somewhat if you're using the VPS line and American servers, though.

Probably fair about SPARC. I'm not familiar enough to have any real informed opinions about it. I've heard a fair bit of complaints about painful quirks, though. I guess one cool thing SPARC has had for a long time is memory tagging -- not sure if anything else other than ARM does, but I'm not sure how ARM's implementation compares to SPARC ADI [1].

I don't know of anyone really making modern SPARC designs either, though; pretty sure Fujitsu is focused on ARM now, and I don't know if Oracle is doing anything really, and I'm not super sure, but although Elbrus has built-in x86-translation of all things, I'm not sure any of MCST's relatively recent stuff can still run SPARC binaries.

I think SPARC mostly still alive because of legacy enterprise stuff and because there are existing radiation-hardened designs like LEON that get used for satellites and things like that [2], also I think MCST still produces some of their older SPARC stuff for Russian missile systems [3] since I imagine it takes forever for older stuff to get fully phased out and replaced entirely

[1] https://www.kernel.org/doc/html/v5.19/sparc/adi.html / https://docs.oracle.com/cd/E53394_01/html/E54815/gqajs.html

[2] https://en.wikipedia.org/wiki/LEON

[3]: Elbrus 90 used in S-400 - https://web.archive.org/web/20181027225122/http://www.pravda...

I haven't found a system with multiple Pentium 4s (but I think NetBurst Xeons were literally pretty much Pentium 4s without disabled SMP?).

That said, who knows, I almost wouldn't be surprised; there's been loads of weird unique systems. Compaq SystemPro had custom SMP support to allow for dual 386s, which IIRC is even supported by Windows NT 3.1 officially. I think IBM x445s had some custom crazy interconnect for 32-way Xeon MPs, etc.

Too new can be problematic sometimes.

For pure performance per dollar, and even in terms of energy consumption, AMD64 CPUs are still doing great, and you don't have to worry about something not being ported yet because it's the defacto standard outside of phones and certain niches like automotive, etc; I couldn't care less about ARM in terms of compute for a workstation, gaming computer, or server, especially with things like QAT and various other accelerators.

What I really do care about, though, is all modern x86/AMD64 platforms are super complex and super proprietary; I have no way to trust them. And while ARM may not be quite as crazy as x86, it is pretty much just as proprietary, and so it doesn't solve my issue of being able to trust the hardware and firmware, or tinker with design.

RISC-V is cool. But going back to trust, it is a mountain of work to bootstrap from "bare metal" (UEFI or whatever else) on x86/AMD64 alone -- C++ has been my enemy; virtually everything ends up depending upon having a working C++ compiler at some point in the chain, including LLVM and any version of GCC not at least a decade old.

This means either cross-compiling GCC/LLVM for RISC-V from another system [which is problematic if you don't have a way to cross-compile from something already trusted and reproducible], or backporting/implementing RISC-V support into a ton of software.

Meanwhile, POWER has been around; it may not be as well supported as x86, but I think it's still far easier and significantly more realistic if you want to build a more-or-less trustable, reproducible system.

Plus, outside of root of trust paranoia, again, it's just far more realistic IMO as a workstation, server, or whatever else because of that much larger existing catalog of working software; you can get your proprietary Nvidia drivers for POWER if you want them, but I don't think they have any intention of supporting RISC-V.

Also, in general, I'm not totally convinced RISC-V offers significant enough improvements over POWER to really justify it. Maybe someone more familiar with RISC-V could offer compelling reasons that I'm not aware of, though.

EDIT: Lastly, RE: wasting silicon, there is also the aspect of "wasting" money and R&D building competitive designs relative to existing stuff -- I don't know when I'll be able to get my hands on a fast RISC-V system.

Beat me to it. More often than not, every time I run into the run-of-the-mill booter or other super blatantly illegal things, at least some portion of the infrastructure is behind CloudFlare.

I don't have enough fingers and toes to count the number of abuse reports I've personally filed that seemingly go nowhere.

OVH at least takes down the booters and other proper malicious stuff. However, copyright infringement reports go ignored to the point to where I stopped bothering--not that I had any right to care when I torrented loads, but it was a little annoying that ~$10 software, with no DRM, regional discounts, and a dozen ways to pay still ended up pirated to the point to where it wasn't worth selling

(fun story: I still have email records from when a pretty beloved multi-billion dollar tech company launched their ROG-clone sub-brand and pirated our XenForo plugins to use on their site instead of ponying up $10 -- maybe one day I'll have to ask them for a laptop).

CloudFlare, on the other hand, at best, just passed on whatever I send in, and whoever their actual providers were never cared either, so nothing gets done. It can feel like rackeetering; sign-up for protection from the people attacking you ...whom we also protect and refuse to take down.

That said, I think 99% of small sites, personal blogs, etc, really don't need any of the services offered; the most useful offering for most people is literally probably DNS.

Game servers and gaming-related communities, or at the least the ones I am most attracted to, are just about the only thing I think requires DDoS mitigation regardless of size. Our little Garry's Mod TTT server with a max player limit of like ~24 people would get attacked a couple of times a week at least.

And good lord, the RuneScape community is another breed of toxic. The way I learned to program was by reverse engineering the game, and we'd work on private servers that were essentially from-scratch MMORPG servers that just emulated the RuneScape mechanics and protocol.

One aspect of the game, though, is PvP -- when you kill another player in the wilderness, unlike in a lot of other MMOs, you get most, if not all, of their items they have on them.

I could perhaps understand DDoSing another player during combat in order to steal their gear. But what made me stunned beyond belief was that when I hosted a "spawn PKing" server (e.g., PvP-only, but you don't have to work for your gear; everything is free - it's just for fun), they'd literally lure each other into TeamSpeak to grab IP addresses and DDoS each other for.... nothing :)

(and so you can imagine also just how often we'd get hit with massive attacks ourselves)

Do tell, please; stories about "interesting characters" are often the best.