sliken

C, for better or worse, is like a high level assembly language. You can do anything, which pretty much means you are going to have many security and correctness issues. Double free, use after free, off by one errors, buffer overflows, etc. Thus numerous CVEs.

Go has less flexibility, no pointer arithmetic, a healthy package system, and a smaller domain. Mostly consuming or providing network services. My favorite feature is channels. For me they make levering the performance of multi-core CPUs straight forward, and dramatically nicer than the C approaches I've tried like pthreads and mutexes.

I wouldn't rate go as secure as rust, but has a pleasingly developer friendly approach. Seems way more secure than C.

Making a pipeline where each stage is 1 to N threads is pleasingly easy, reliable, and performant.

AM5 is the AMD standard, it's accurate, seems rather pedantic to differentiate between 2 sub channels per dimm and saying 4 32 bit channels for a total of 128 bit.

However the motherboard vendors get annoyingly hide that from you by claiming DDR4 is dual channel (2 x 64 bit which means two outstanding cache misses, one per channel) and just glossing over the difference by saying DDR5 dual channel (4 x 32 bit which means 4 outstanding cache misses).

Yes, because AMD64 has 64-bit words.

It's a bit more complicate than that. First you have 3 levels of cache, the last of which triggers a cache line load, which is 64 bytes (not 64 bits). That goes to one of the 4 channels, there's a long latency for the first 64 bits. Then there's the complications of opening the row, which makes the columns available, which can speed up things if you need more than one row. But the general idea is that you get at the maximum one cache line per channel after waiting for the memory latency.

So DDR4 on a 128 bit system can have 2 cache lines in flight. So 128 bytes * memory latency. On a DDR5 system you can have 4 cache lines in flight per memory latency. Sure you need the bandwidth and 32 bit channels have half the bandwidth per clock, but the trick is the memory bus spends most of it's time waiting on memory to start a transfer. So waiting 50ns then getting 32bit @ 8000 MT/sec isn't that different than waiting 50ns and getting 64 bit @ 8000MT/sec.

Each 32 bit subchannel can handle a unique address, which is turned into a row/column, and a separate transfer when done. So a normal DDR5 system can look up 4 addresses in parallel, wait for the memory latency and return a cache line of 64 bytes.

Even better when you have something like strix halo that actually has a 256 bit wide memory system (twice any normal tablet, laptop, or desktop), but also has 16 channels x 16 bit, so it can handle 16 cache misses in flight. I suspect this is mostly to get it's aggressive iGPU fed.

In computer manufacture speak dual channel = 2 x 64 bit = 128 bits wide.

So with 2 dimms or 4 you still get 128 bit wide memory. With DDR4 that means 2 channels x 64 bit each. With DDR5 that means 4 channels x 32 bit each.

Keep in mind that memory controller is in the CPU, which is where the DDR4/5 memory controller is. The motherboards job is to connect the right pins on the DIMMs to the right pins on the CPU socket. The days of a off chip memory controller/north bridge are long gone.

So if you look at an AM5 CPU it clearly states:

   * Memory Type: DDR5-only (no DDR4 compatibility).

   * Channels: 2 Channel (Dual-Channel).

   * Memory Width: 2x32-bit sub-channels (128-bit total for 2 sticks).

I think there's a standard wiring for the dimm and some parts are shared. Each normal ddr5 dimm has 2 sub channels that are 32 bits each, and the new specification for the HUDIMM which will only enable 1 sub channel and only have half the bandwidth.

I don't think you can wire up DDR5 dimms willy nilly as if they were 2 separate 32 bit dimms.

Sadly motherboards, tech journalist, and many other places confuse the difference between a dimm and channel. The trick is the DDR4 generation they were the same, 64 bits wide. However a standard DDR5 dimm is not 1x64 bit, it's actually 2x32 bit. Thus 2 DDR5 dimms = 4 channels.

For some workloads the extra channels help, despite having the same bandwidth. This is one of the reasons that it's possible for a DDR5 system to be slightly faster than a DDR4 system, even if the memory runs at the same speed.

Quad-channel RAM is common on consumer desktops

Yes, but tablets, laptops, and normal (non-HEDT) desktops have 4 channels, 4x32 bit = 128 bit wide. Modern memory with DDR5 allows two 32 bit channels on a 64 bit dimm. The previous gen DDR4 would allow 1 64 bit channel on a 64 bit dimm.

So strix halo (on laptops, tablets, and desktops) allows for a 256 bit wide memory system, providing twice the memory bandwidth of any ryzen or intel i3/i5/i7/i9. The Apple pro (256 bit), max (512 bit), and ultra (1024 bit) lines of apple silicon have greater than 128 bit wide memory systems. On the AMD size it's just the Threadripper (256 bit) and Threadripper pro (512 bit), but those are typically in expensive workstations that are physically large, expensive, and need substantial cooling.

So the HALO is pretty unique (outside of Apple) for providing twice the memory bandwidth of anything else that fits in the tablet, laptop, or small desktop category.

As you dig deeper I think you'll find a method behind the madness.

Sure modules just play with env variables. But it's easy to inspect (module show), easy to document "use modules load ...", allows admins to change the default when things improve/bug fixed, but also allows users to pin the version. It's very transparent, very discover-able, and very "stale". Research needs dictate that you can reproduce research from years past. It's much easier to look at your output file and see the exact version of compiler, MPI stack, libraries, and application than trying to dig into a container build file or similar. Not to mention it's crazy more efficient to look at a few lines of output than to keep the container around.

As for slurm, I find it quite useful. Your main complaint is no default systemd service files? Not like it's hard to setup systemd and dependencies. Slurms job is scheduling, which involves matching job requests for resources, deciding who to run, and where to run it. It does that well and runs jobs efficiently. Cgroup v2, pinning tasks to the CPU it needs, placing jobs on CPU closest to the GPU it's using, etc. When combined with PMIX2 it allows impressive launch speeds across large clusters. I guess if your biggest complaint is the systemd service files that's actually high praise. You did mention logging, I find it pretty good, you can increase the verbosity and focus on server (slurmctld) or client side (slurmd) and enable turning on just what you are interested, like say +backfill. I've gotten pretty deep into the weeds and basically everything slurm does can be logged, if you ask for it.

Sounds like you've used some poorly run clusters, I don't doubt it, but I wouldn't assume that's HPC in general. I've built HPC clusters and did not use the university's AD, specifically because it wasn't reliable enough. IMO a cluster should continue to schedule and run jobs, even if the uplink is down. Running a past EoL OS on an HPC cluster is definitely a sign that it's not run well and seems common when a heroic student ends up managing a cluster and then graduates leaving the cluster unmanaged. Sadly it's pretty common for IT to run a HPC cluster poorly, it's really a different set of contraints, thus the need for a HPC group.

Plenty of HPC clusters out there a happy to support the tools that helps their users get the most research done.

All. Keep in mind strix != strix halo.

You can get tablets, laptops, and desktops. I think windows is more limited and might require static allocation of video memory, not because it's a separate pool, just because windows isn't as flexible.

With linux you can just select the lowest number in bios (usually 256 or 512MB) then let linux balance the needs of the CPU/GPU. So you could easily run a model that requires 96GB or more.

You won't like it, but the answer is Apple.

Or strix halo.

Seems rather over simplified.

The different levels of quants, for Qwen3.6 it's 10GB to 38.5GB.

Qwen supports a context length of 262,144 natively, but can be extended to 1,010,000 and of course the context length can always be shortened.

Just use one of the calculators and you'll get much more useful number.

Try this one: https://archive.is/UGzzc

Any chance of turning this into a server/client with an API so people could use the language of their choice?

Along similar lines, the double-slit experiment, seems simple. Two slits let light though and you get bands where they constructively or destructively interfere, just like waves.

However I still find it crazy that when you slow down the laser and one photon at a time goes through either slit you still get the bands. Which begs the question, what exactly is it constructively or destructively interfering with?

Still seems like there's much to be learned about the quantum world, gravity, and things like dark energy vs MOND.

Sure, if you are smart enough. Maybe mount a small transmitter on a tree then use a directional antenna at a very low power and use the tree as a repeater.

Or use NVIS, which at least makes triangulation harder.

Not that I have to tell this crowd. Tuxpaint is free, get it from tuxpaint.org, do not buy it, do not download it as part of a "desktop". I was talking to the author, apparently it's sadly often used to trick people into buying or downloading malware.

I set up my kid, I think she was 3 or so, she started out with stamps of butterflies and the like. After awhile she looked at her hand, then mouse, then me, stared at me and said "ouch". I got a "travel" mouse that was half size or so, perfect for her hand and she loved using tux paint.

Don't forget to setup sound, preferably in stereo.

She used the hell out of it for years. One time on a call she was fascinated by fish. I printed out one of her drawings remotely while we were on the phone and she loved it.

Keep in mind the desktop env knows when you are left clicking a link or middle clicking. So on linux, usually it's left click to go to a link or middle click to open link in a new tab.

Middle click to open new tabs is compatible with middle click to paste.

In theory I'd agree as well.

In reality such features are often dropped, no settings in gnome-settings, and non default features are not tested in new builds.

So you end up googling how to get that feature back and the answer is manually navigating the config tree or using gnome-tweaks, both with large disclaimers that any changes might break your system.

No thanks, I'd rather have left click to select and middle click to paste, do we really have to involve the keyboard by default?

Similarly gnome-terminal used to have "new terminal" as the first option in the menu of a terminal. Then it got moved down to 6th item, then in the newer versions removed completely.

Very frustrating.

Sure. But it's a depreciation and there's numerous similar settings that are only available by tweaking settings manually or using gnome-tweaks. Right now nearly every linux app supports select with the left button and paste with the middle. It's fast, useful, doesn't require a keyboard, etc. Amusingly I've seen various logins block control-v, but middle click works. God forbid you use a password safe with your bank login.

When you use gnome-tweaks there's a ton of "WARNING you may break things" and of course anything off the default path is likely to receive zero testing.

Personally I find middle click to paste one of the differentiators between MacOS, Windows, and Linux. I'm pretty surprised it's not more common. I was amused the iterm2 added select without having to type control-c.

Do you have a static IPv4, presumably a single IP?

I find it useful, mine does change periodically, but I just have a script that Updates DNS when it changes:

   nsupdate -v -y "${KEY_ALGO}:${KEY_NAME}:${KEY_SECRET}" <<EOF
   server $DNS_SERVER
   zone $ZONE 
   update delete $RECORD AAAA
   update add $RECORD 300 AAAA $CURRENT_IP
   show
   send
   EOF

No, but they can skip the socket, much like many of the mini-pcs/SFFs that include laptop chips in small desktops. Strix halo already doubled the memory channels and the next gen is supposedly going to move the memory bus from 256 bits wide to 384 bits.

Nice first approximation. The cloth has no momentum, a piece of cloth that clearly would swing down, past vertical, and then swing up just damps down and stops at vertical.

Also the falling pieces don't accelerate downward, which looks unnatural

Just because it's not perfect, does not mean it useless.

A central signal message service receives millions of messages, I've seen claims of 40M active users a month. If each user sends 25 messages a day, that's 12,000 ish a second.

Drawing conclusions about who is talking to each other out of a 12,000 message per second stream is far from trivial since both signal users are just sending and receiving encrypted packets to a central service. Much depends on how much you believe about how signal handles things on the server size.

Not sure federation or pure p2p would improve things, especially since some fraction of the service could be malicious.

Signal seems pretty good, not sure it could be better and have evolved so quickly and gained so many users. Sure it could be more resistant to traffic analysis. What do you use?

I've pondered writing a p2p client that uses the signal encryption (double ratchet) and bounces fixed size packets off 2-3 other clients before delivery. All packets would be the same size, including those for the upkeep of the DHT.

To help make traffic analysis more difficult forwarding would include a random delay, DHT traffic would be indistinguishable from message traffic, and chaff would be added to allow for plausible deniability. Your client would talk to at least 3x as many other peers with similar timings and frequencies.

However the inherent compromises of P2P like increased CPU, network, and battery usage combined with higher latency and startup time seems like the adoption would be lucky to hit 0.1% of signal and then it's less useful since using it would raise flags.

Signal is so valuable because it has good e2e, it's popular, and whoever you want to talk to is likely to have at least heard of signal if not already running it.

Right, but 1€ isn't free. So if you manage to spam 1M people and make less than $0.05 * 1M = $50,000 then you are losing money.

Thus no spam on signal.

Wow, that's a pretty negative take.

Signals mission seems to be something along the lines of helping the most people increase their privacy. Better to help millions resist the dragnet of surveillance by ISPs, governments, and large organizations then to have perfect security for a few. This requires a very easy to use client (i.e. click on signal in the app store and launch), features users want (send receipts, typing notifications, emoji, video, calls, etc), and making wrong choices hard. Like say installing a random compatible with signal client from an untrustworthy source.

So Moxie is fine with people forking the open source client, but wants them to use their own servers.

Distributed/decentralization isn't some magic pixy dust that makes everything better.

So sure federation can work, but it's harder, and you run into things like XMPP. Are there secure XMPP servers out there, sure, but how do you tell? Which XMPP server supports which extension? How many people use XMPP for their chat/calls on a daily basis?

Seems kind of weird to pick on signal for doing things well and getting popular. Could it be more secure/private, sure. Could it do so AND be more popular, not so sure.

The network issue is the windows driver, only relevant if you are running windows. There is a work around by pinning the old version and I believe there's a new driver that works, but isn't the final driver.

Several reviewers have mentioned this.

I got my framework desktop a few weeks ago, I'm quite fond of it.

What's worse is that the email is often delayed at the sender (cheap bulk email services) or the receiver (gray listing), but for no reason I can fathom have a short expiration date.

What's worse they are often unique AND delivered out of order AND have no timestamp or sequence number. So you get to guess which is the newest, using any other fails, and the ones that succeed often time out before they can be used.

Having an expiration date as short as 15 minutes seems insane and counter productive.

Only if you are in a hurry, say an advanced civilization has been around for 1M years (0.07% faster than us). It might well be worth sending out millions of drones to the most promising areas at 1% of the speed of light, their advanced sensors and telescopes and science would likely be able to pick the most likely stars based on metal content, vicinity (i.e. stable of 1B years), water, temp, etc.

Not to mention they could send probes closer and further from the galactic center to take advantage of the slower and faster rotation rate to see new stars.

As for the nuclear fission blast I have my doubts. Ham radio folks brag about 1000 miles a watt, in a lossy atmosphere and multiple bounces that reflect less than 1% for each bounce. Using advanced things like tubes of transistors and a copper cable thrown over a tree branch.

Using the 1 watt per 1000 miles the largest nuclear explosion would be 22 light years, and clear line of sight through space is going to transmit quite a bit better than bouncing off the atmosphere then off the ground several times.

An advanced civilization could make say a square km array (which us lowly humans have managed) and would understand nuclear bombs enough to know their likely signature, decay rate, shape of the curve, etc. Much like how astronomers use supernovas as standard candles for distance, despite crazy different red shifts.

Seems quite reasonable for a civilization to keep track of anything going on in their fraction of the galaxy.

"People for some reason refuse to comprehend just how hard is it to send a speck of dust over light years of distance" It's only hard if you are in a hurry, in fact we have 3 rocks come through our solar system from well more than a light year away.