@snowdusk_ Say what you will, but the disco was awesome.

Liking the 80s synth/new wave night. First time listening; do you have 80s synth/new wave frequently? If not, why not? ;)

LB: Every few years, people rediscover that the ham radio community isn't an open source/maker community, like how ARRL presents it.

Making/elmering doesn't end with Yet Another YAGI, a few articles in QST about the same old stuff year over year, and the occasional trap or two.

@h I can be reached via Github, Mastodon, Twitter (@samuelafalvoii) and via personal e-mail at kc5tja /at\ arrl.net.

@jjg Embedded development, San Francisco bay area required. Familiar with C, Forth, assembly language. Have C++ experience, but far from expert level. Have Lisp/Scheme experience, but again, far from expert level.

Just an update. Looks like the start-up I'm working for, while it's given a hard and earnest attempt at profitability, is spiraling down the drain due to unforeseen overheads in our supply-chain's (lack of) quality.

So, I'll probably be going dark here while I focus on employment opportunities. Also, GUARANTEED, no work on Kestrel-3 until at least next year. I'm so sorry. But, I gotta focus on priorities. :(

@jjg @LinuxSocist @h Artix 7 series, or Zynq 7 series chips are known to work, iirc.

@clacke @klaatu @archer72 This is why AmigaOS doesn't have any concept of "fsync" or "shutdown" commands. You literally just waited five seconds (with all programs closed, save for Workbench), after which any disks with unflushed buffers would do their thing. After they all came to a stop, you literally just flipped the power off.

@clacke This is why I think the formal methods industry and research communities have it all wrong. They should not be looking to make their systems tighter (this is always a good thing to do regardless), but rather they need to be making their contributions more approachable to knuckle-dragging grunts in the field like me.

R&D into type systems falls into this latter category, which is why Haskell monads and Rust's ownership ideas are ground-breaking. We need more of *this*, and less of Z.

@jjg @h I've been invited to participate at the C3 conference, but I just can't afford to go. At least their talks are on a more diverse subject matter where Kestrel-related things would fit a lot better.

But, then again, over on Twitter, there was some accusations of rape culture enabling behaviors that had not been addressed yet; while I'm privileged enough to not have been exposed to that kind of stuff, I certainly don't want to directly or indirectly support that either. So....

I better get crackin' on my Forth presentation for this week's SVFIG. I present on this-coming Saturday!

@h @jjg I will not be attending the RISC-V workshops in the future. When I attended the 5th workshop, I was really treated write poorly, and in one case quite hostilely, by some attendees. I refuse to further support a venue that attracts bro-anything.

They cater to people on cutting edge of embedded or supercomputing only, for the most part. My talks on the Kestrel has been rejected 3 times in a row. The poster sessions were fun, I did those instead.

@clacke @lobsters Back in the days of 2 MIPS processors running C code (e.g., 68000, 8086), this sort of byte-order-specific code made a real difference, especially when pushing pixels around (e.g., as in GUI code).

Today, not so much. Accelerated graphics hardware takes care of endian issues for you, OSes have abstract views of the screen anyway, and so the only thing to really worry about is file and network stream I/O.

@drpeeper @jjg Some thoughts:

1. Rust isn't OO, although it has OO-like capabilities. Code bloat mostly comes from parametric polymorphism.

2. You can build binaries without the standard library, just as you can in C.

3. I find rust pretty compelling even as an "expert-level" C coder (been using C since 1985). It catches mistakes that I still make in C today. In fact, I'd explicitly state that rust is *not* for beginners.

So, I think I'm going to lose my job; either they will lay me off, or I will walk from it, next fiscal half.

Anyone looking for a 40+-year old *programmer* (please PLEASE do not mistake me for a "software engineer")?

Le sigh.

@h Kestrel-3.

Since my current CPU lacks any MMU, the kernel would not support "safe" binaries. It'd be shared-memory, single address space, just like Kickstart 1.3.

*After* I build the MMU for it (OR, after I switch the CPU out for a Rocket core), then I can upgrade the kernel to add support for "safe" binaries and implement the new system calls needed to make communicable regions of memory.

@h When you think about it, IBM's System/360 was just like the Amiga when it was first introduced: a shared, single address space environment. They had 2KB quasi-pages which prevented one task from writing into another task's memory, but *nothing* stopped tasks from *reading* other tasks memory. Today, z/OS is fully memory protected.

So, somehow, there must be a way to evolve an AmigaOS-like environment without breaking compatibility.

@h I don't think it was lack of vision; it was the vision of putting computers in the hands of untrained masses that drove the interfaces we have today. There inlies the problem: untrained.

The untrained masses became either complacent, or worse, actively reveled in their ignorance. This is literally their point of view: "Why should I learn how to type these god-awful cryptic gobbledygook when I can just drag and drop these pretty pictures? Reading is hard! Let's go shopping!"

@jjg @clacke I feel the need to stand on a soap-box here. :)

We need to remember that RISC-V is an instruction set architecture. It's a specification, and therefore, has nothing to say about whether or not instructions are speculatively executed, in what order they're executed (within reason, of course), etc.

Specific implementations may or may not be affected. KCP53000, my own RV64I CPU, is not affected. Reports today confirm neither are cores built around Rocket. BOOM remains uncertain.

@clacke I'm just reading the Google Project Zero page and as well https://meltdownattack.com/ .

@clacke However, Spectre still works inside a completely user-space program (e.g., Javascript breaching its sandbox to read browser internal state). This is still a hardware-level bug that should not happen, and it's caused by the interaction between the memory hierarchy; this is actually not CPU specific (AMD, Intel, ARM, and most likely, RISC-V) all would/could suffer from it. It's caused by speculation leaving breadcrumbs of sorts in the cache controllers off-core.