My take on this is that we need both, because the market is cyclical. It’s just that it’s hard to perceive any of those cycles if you (a) live them (b) are not experienced enough to introspect.

I absolutely would love an obsessed plumber (and got one!) when it comes to deciding that we’re going to do PTFE tubing in our new house. An obsessed electrician in charge to overinvest into our grid, rather than a 3-month timeframe executive. Otherwise our critical infrastructure gets myopically degraded.

I also want the “working within timeframe” outcome.

And we, as an industry, swing wildly in both direction. The Cambrian explosion of shareware was the the former. We course-corrected into cathedrals of good software (I still love Windows 2000’s stability, the pinnacle of NT line), followed by the “reasonable timeframe” 4GB Electron apps, etc.

It will swing. Every complex system from logistic equation upwards will oscillate .

We're making our law enforcement's job marginally easier, by making the criminals' job infinitely easier by creating millions of juicy PII honeypots.

No, you don't need my phone #, real name, captcha.. if you think you do, realign your incentives, and rethink what else can be used for your real need instead.

Pure insanity.

Google/Microsoft and hosting your own email is a byproduct of how difficult (socially, not technically) hosting your own email has become - mostly because SMTP protocol is inherently broken by spam and patched by social construct (trusted nodes, abuse@, 3+ DNS entries and counting, etc). Purely technical solutions, such HashCash etc, got discontinued in exchange for social ones. Central providers made (sometimes in exchange for, sometimes as excuse of, spam protection) self-hosting socially hard.

Now, I wonder if, and how, once Anthropic and OpenAI need to demonstrate profitability, could hamstring local AI. Which has been /so far/ very valuable for me in doing things that hosted providers don't want liability for, and align against (even if totally lawful and fair use!).

I wish we have agreed on some fp16/fp8 format by now to add to it..

We run "Ordered" - without queueing - so we essentially are trading off some /more/ performance for reliability in this situation. The block layer tends to handle it well in most OS.. I'll be game to test what softraid crypto would do to it (luks actually handles it reasonably!)

In terms of encrypted transport - the value is mostly in HMAC layer. That might die oddly if the ISPs decide to mess around with these packets because they look too cute - but for encrypted FS, it shouldn't be accidental, only malicious. (Accidentally, I've seen ISPs get upset over MPEG streams over netcat!)

You can demo it out on scsipub without having to provision local SAN, and I came up with scsipub idea as a consequence of lack of any public iSCSI hosts to try things out.

Yes, it's ridiculous, but I have plugged my M1 Macbook Air to (LAN based) iSCSI through a Pi4. Works remarkably well.

I'm curious about how you approached handling a lower-level protocol in Elixir. When you began implementation, did you start thinking at the level of packets as structs, or maybe first as just maps that flowed through functions?

Grab a buffer, make sure it's at least as long as BHS, shove into BHS, ok, make sure it's at least as long as what the BHS requires...

Pattern matching is the hidden power of Elixir that's probably the hardest to get fluent with, it's IMHO harder than Rust's equivalent (because of gradual typing!) - but when it works it blows Pythons' match syntax way, way out.

  # Example: Login Request with immediate = 0x03 | 0x40 = 0x43.
  defp parse_lengths(<<
         _reserved::1, _i_bit::1, opcode::6,
         _flags::8,
         _specific1::16,
         ahs_length::8,
         data_length::24,
         _rest::binary
       >>) do
    {:ok, opcode, ahs_length * 4, data_length}
  end

  defp parse_lengths(_), do: {:error, :invalid_bhs}

Overall, it's really cool to see Elixir applied like this. Congrats on the launch!

The short version: it's iSCSI targets on the public internet. Pick an image, get a block device. The free tier doesn't need a signup at all - iscsiadm -m discovery -t sendtargets -p scsipub.com and --login to iqn.2025-01.pub.scsipub:blank lands you a 64 MB scratch disk. There's a small catalog of OS images you can mount the same way.

The paid tier is where it gets less hobby-shaped: sessions survive disconnects, a single target can expose multiple LUNs, and SCSI-3 Persistent Reservations work end-to-end (REGISTER / RESERVE / RELEASE round-trip clean against sg_persist). That last bit is the cluster-storage primitive — Pacemaker, ESXi HA, and Windows MSCS all use PR for fencing — so you can actually back a 2-node failover cluster off a target on the public internet.

The post linked in the submission is the architectural decision log: Ranch 2.x listeners, a BEAM process per session, COW overlays with per-sector bitmaps, Caddy-managed Let's Encrypt for the iSCSI-TLS port without restarting the listener, and the four open-iscsi quirks that each cost me few hours. There's a section on what we're deliberately not solving (multi-region, RDMA, etc.) so you know the scope.

Two companion projects ship as embedded sub-sites on the front page — one turns an ESP32-S3 into a wireless iSCSI-to-USB bridge, one lets a Raspberry Pi 3/4/5 netboot directly from a target. Both linked from the landing page under "Hardware initiators".

Happy to answer any questions about the protocol, the deployment, or the BEAM-side design choices.

Apparently, exposing small USB sticks to industrial equipment that uses it for loading/saving configs and screenshots and being able to 'network' it with shared iSCSI drives.

"The scope writes screen_001.png to “USB”; the file appears in a directory on my desktop, in the iSCSI overlay. Combined with a dropbox-style sync I no longer need to walk over and pull the stick out."

Quite brilliant and clever, if you ask me.

I'm wondering now about using an ESP32 stick and an iSCSI image of Windows install media - that could make for some fun in-house computer imaging setups.

The other one is the Raspberry Pi{3,4,5} iSCSI shim linked there as well - I have a bunch of them for a bunch of paying clients CI/CD kinds of work, and I wanted these to boot from network, not from microSD.

Both of these projects could've benefited from a public demo iSCSI endpoint, we have http://example.com and whateveryouwant@mailinator.com - why not iSCSI

Then again this might still be useful yet - a small 64MB thumb drive with an autounattend.xml streamed to it is also an equally powerful tool for some Windows shenanigans.

That said, this isn't too far from mechanical HDD latencies of the /real/ SCSI drives.

Since I built it, I've started seeing it as a hammer for many nail-like problems - I think that would die down over time;

but.. I have my ESP32 "pendrive" that's net-synced. I have used it to install OS through UEFI-built-in initiator. I have added iSCSI targets to my windows laptop machine (and VMs) - while you need to deal with disconnects and reconnects, it actually works well enough.

It is a terrible idea, that doesn't sound as terrible for odd use-cases. But yes, the ESP32 over 2.4GHz over 3G internet is slow as molasses (20-30kB/s) - but when the alternative is 0.. or walking over there with a laptop, it works OK.

We do suport VPD 0x83 and advertise consistent NAA/WWID, so linux will support multiple iscsiadm sessions to the same device, and it will be stitched across sessions as paths to the same disk.

We currently hardcode MC/S to 1 as part of login negotiations, advertise single portal and dropping a path will require a re-login.

So - theoretically yes, you can support multipath and it won't fall on its face, but without any practical benefits of it (no bandwidth aggregation and no failover - no ALUA) - at this point it's a single boring target.

But the underlying plumbing can support it - if you have a real usecase for it.