datenwolf

> First off, you want to keep both of the pair’s signals close to each other throughout their length. The closer the two signals are, the better external interference cancellation works, and the less noise they radiate (…)

Wrong! This is a myth that's stubbornly difficult to weed out. The coupling between the wires of a pair is only ~12% the amount of coupling to the reference plane.

On a PCB it's best to treat each signal on its own and route it as a single ended, coplanar waveguide surrounded by reference planes. This allows to use far thicker widths, which reduces inductance, which also reduces the coupling to radiating EM fields.

If you want a longer talk on the topic: https://www.youtube.com/watch?v=QG0Apol-oj0

Yes. It's the classic ice skater effect. Climate gets warmer => Ice (on mountains) melts. Molten ice = water flows down into the ocean, moment of inertia of the Earth is reduced => Earth's rotation speeds up.

Just to put things into perspective: The elevation of the land surface at the Earth's south pole is over 2800m above sea level. The highest point in greenland is over 3600m above sea level.

> Currently, sure. Across all time, I'd go with blue-green algae.

I knew that someone were to point this out. Yes, of course across geological timeframes at the moment we're playing second fiddle at best. But over the course of, let's say, that past 10 million years or so, I'd say, we're a firm contender for first place.

> but I think the ability to read and write arbitrarily complex ideas really does set us apart,

I'm not denying that humans, in their current form, as a species are set apart from the rest of life on this planet.

Rather what I'm trying to get at is, that if you'd backtrace the evolution of humans, at no particular point in time you could make a clear desitinction of "this generation of pre homo sapiens species fundamentally differs in their linguistic capabilities from the next evolutionary step".

The linguistic capabilities of hominids and humans more likely than not developed gradually, just like every other feature that makes a distinct species. Eventually you'll be able to clearly tell them apart. But when applying a "derivative" operator on it, you'll find that evolutionary development is smooth and continuous.

And I think that also applies to linguistic capabilities. The proposition I'm making is, that the linguogenesis of homo sapiens can not be explained within the boundaries of that species. Rather I'd say that the roots of our language can be traced back far further than you'd presume by presence of certain vocal anatomical features alone.

There's this one sentence in the article, that – I think – may give a hint on the difficulties explaining linguigenesis if constrained in the way portrayed by the article:

> The authors compared animal and human communication, eliminating the aspects of vocalization that are shared by both, and concluded that one operation alone distinguished human speech: recursion. In the course of working on the article, Fitch grew sympathetic to Chomsky’s ideas and became an articulate defender of the theory of universal grammar.

"(…) distinguished human speech(…)", if you think about it, that's a weird assertion/assumption to make. The idea, that there's a clear line between human and non-human communication, as if this was something binary.

We humans have this weird concept, that there's "something", that makes us fundamentally different from the rest of the animal life on this planet. Yes, we've got the largest impact on the biosphere, we can reason about it. But if you were to track back on the coginitive abilities of our evolutionary ancestors, I'd say it would be very difficult to put a hard threshold in the phylogenetic tree, where suddenly a whole subset of means of communication discretly vanishes.

Just my 2 cents…

There is this recent-ish paper (DOI: 10.1126/science.aba6630) on why it might be, that plants forego the peak of the solar spectrum. Essentially it boils down to being able to regulate the photochemistry of photosynthesis. If it were centered on the peak of the spectrum there's not a lot of regulation possible by means of shifting the reaction energy levels around.

By placing the light absorbing parts of photosynthesis on the slopes of the spectrum, by mere adjustment of the energy levels the reaction undergoes it can shift its activity to parts of the spectrum with more or less light intensity.

It's not an X11 design flaw. The very concept of locking the screen is flawed. A flaw that also haunts Wayland, BTW.

The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.

That's a flawed concept.

What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.

You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.

In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.

With respect to

> 1. Beware of the Curse of Knowledge

I'd like to add, that knowledge can lead to "knowledge paralysis": The more knowledge and experience you have on a certain topic, the more problems and caveats you'll spot right away. Awarenes of those may prevent you from actually engaging in productive activity and instead tiptoeing around the problem at hand, instead of just implementing a "straightforward" solution (that ignores the 0.1% of corner cases, you know about, but won't have to care about).

This is omething I'm struggling more and more these days.

> The current raytracing acceleration is intended to boost some highlights and shadows in practice.

A couple of days ago, while gaming with a few friends and noticing a transparency ordering issue in the game we played and explaining to them, how and why that happens I realized something:

The raytracing accelerators we now have at our disposal can also be used to implement proper primitive level transparency ordering on the GPU; even if you don't spawn secondary rays, just being able to do a sparse ray-triangle hit test through the whole scene building the render order list in situ.

It's the perfect metaphor. Your brain is not a single cell. It's a couple billion. Every day in a healthy body a few million cells die, without any repercussions whatsoever.

> As someone with inside knowledge, can you review my reasoning that it fits, and it probably was?

No idea. I left that particular lab a few months after I graduated which was 8 years ago.

They were using a so called accelerator mass spectrometer (AMS). The main challenge, as I understood it from talking with them, was in the chemistry required to prepare the samples for injection into the AMS. Specifically ensuring that there's no background signal created from the preparation itself. So there was a lot of work done just to get the process right (the less steps to prepare the sample, the less steps that might contaminate it). Then a lot of verification, calibration on the AMS and optimizing the beam transport to reduce losses as far as possible.

EDIT: The AMS was built and used in a lot of experiments before that. Among other things done with that instrument was measuring the neutron flux of the nuclear blast at various locations in Hiroshima, by determining the isotopic composition of the copper on building facade elements. Neutron capture produces some radioactive as well as "unnatural" stable isotopes and by determining their ratio, one can determine the neutron flux and energies.

https://www.researchgate.net/publication/6012967_Neutron-ind...

It saddens me, that the accelerator they (and I for that matter) used for their research, has been decommissioned as of last year and is being dismantled right now :( – I could start a major rant about it, that would touch the subjects of funding, some people's personal pride and good science vs. fashionable science.

They did it, they finally did it!

Context: I did my diploma thesis work at that lab, and shared the office with those guys. This is a result almost 10 years in the making.

Congrats!

As I already mentioned over at https://www.reddit.com/r/vulkan/comments/i2ivzh/new_vulkan_f... I'm going to do that. And will let you know how it goes.

I'm aware of all of that. And yes, we're very synchronization dependent. However we also spent a lot of time tinkering with the launch parameter and properly interleaving all synchronization events and fences due to our demands on achieving low latency.

Find our original publication here: https://doi.org/10.1364/BOE.5.002963

Since then we improved on that. For the resampling and complex tonemapping we determined empirically that a grid of 128 threads, each processing a whole line achieves the best throughput; there's a 2D parameter space of possible launch configurations and we brute force the whole thing (so far I didn't benchmark the RTX20xx and RTX30xx GPUs, but it was consistent between the GTX690 to GTX1080). The FFT plan is what cufftPlan1d is producing for a single axis transform over a 2D array, usually 2048 point FFT, but with up to 4096 lines (well, technically whatever the maximum dimension for 3D textures is).

> Do you launch a big grid that consists of multiple samples combined in a matrix

Of course!

> or you launch each sample separately?

Of course not, that'd be stupid.

The OCT data we process comes in at about 4GSamples/s and my benchmark is for ~5ms of capture data, in the considered dataset 1D-FFT with a length of 2048 points and a block size of 128. It is not a synthetic benchmark, I'm measuring the real life application behavior here (and to eliminate the runtime behavior effects of the other parts I can flip a flag skipping over the DAQ codepath, working on allocated, but uninitialized buffers).

> GPU is a very consistent device.

You'd think that, but I found all GPUs I'm using here to exhibit multimodal distribution of execution times in the FFT (this is for the cuFFT codepath). The GTX980 (not shown in the plot) and the Titan-X even have very prominent outliers. This is a figure that's going to be in the paper I'm currently writing:

https://dl.datenwolf.net/gpu_oct_benchmark_plots.pdf

I'm comparing the OCT processing execution times (with HOT caches, mind you) between a Titan-X and a GTX1080. The difference also shows up very prominently when looking at the kernel scheduling order as reported by NVPP.

Apparently also the reason why plants forgo green light (i.e. the most abundant part of the solar spectrum): https://www.quantamagazine.org/why-are-plants-green-to-reduc...

The author twice mentioned looking for a suitably tiny initrd / initramfs.

FYI: You don't need an initrd / initramfs. Just link the drivers required for mounting the rootfs from IDE statically into the kernel image and you're done.

Initrd used to be a kludge to work around bootloaders not supporting multiboot. And then we normalized that deviation in the form of initramfs.

You forgot WebUSB – I wish I was joking, but I'm not:

https://developer.mozilla.org/en-US/docs/Web/API/USB

> Why not just do a PCI pass through (…)?

Because we're talking about remote desktop over low bandwidth connections. If push comes to shove you can use Xpra over dial-up.

Of course the more elegant solution then is to use some virtio based graphics pass-through driver doing all that, without running MIT-SHM screen grabber X11 clients shoving around frames. I want less kludges, not more.

In those cases I prefer using Xpra, configured to use the regular Xorg server operating on the GPU.

It would be nice if there was a X11 "media" extension to transport encoded image streams (aka video) with server side decoding into Pixmaps, Xv or SHM buffers.

> X also doesn't really work if you UI is implemented with OpenGL or similar.

Depends on how you use the OpenGL API. OpenGL display lists, once compiled, are extremly light on the connection. However they're also deprecreated and no longer supported in (forward compatible) OpenGL-3.3 core. But then again there's no 3.3 GLX specification.

I'm in the same boat. Sometime in late spring 2018 my productivity plummeted. Same did my activity on StackOverflow.

However I think what's a huge contributing factor is gaining experience. With every structure we come up with, every function and/or abstraction we also build a mental picture of all the possible dependencies it comes with. We see the bigger picture. And we see the same (potential) paths of failure again and again and again…

I found that another favorite activity of mine didn't suffer: Designing electronics. I can still (productively) spend hours on tinkering with SPICE simulations, soldering in-situ projects, and so on.

And recently I also discovered that it's not programming itself that has become harder for me. It is programming in domains I am extremely familiar with that I'm less productive in. If it's in an area I'm not familiar with, things are much easier, because I don't see the big picture yet.

One application would be distributed storage systems where the user doesn't trust the service provider.

Using FHE one could implement a distributed storage system, with replication, conflict resolution, error correction and so on, without ever revealing the plaintext to the storage and compute provider.

> Or just get a static tar and xz static build, they must be somewhere.

That is, that you can find them in an uncompressed form. If you fees adventurous you can probably coax the compressed data somehow through the bootloader decompressor, or the xz or deflate implementation found in the Linux kernel. Unfortunately these days modules tend to be compressed as well, but it should be possible to convice libdl to open a .ko file. If not you can always mmap it PROT_READ|PROT_EXEC and follow the symbols entries through the TLD yourself.

Well, the semantics of what constitutes light and what not are a bit murky. CO2 lasers are still considered LIGHT amplification by stimulated emission of radiation. CO2 lasers operate at ~10000nm.

In the optics community we usually consider everything we can manipulate with refractive optics as "light" – and yes, I am fully aware that this goes down well into what's considered microwave radio.

My personal cutoff for where optics begins is, where I no longer can use an antenna that is part of a resonant _circuit_ to emit / receive the radiation, and have to resort to quantum mechanical state transitions.

Laser physicist here, did some work with PCF: Expensive as fuck, highly polarization dependent, almost impossible to splice.

> It is unclear to me whether the C libs include TCP.

The exercise states that you have a Linux kernel and there is a network connection. If the kernel does not have TCP, but only offers a raw socket, well, then you have to write down a very simple TCP stack.

But if the kernel does have TCP, the exercise boils down to writing a very simple HTTP client, a very simple DNS resolver and a bare bones XZ decompressor and tar reader. From there I'd grab myself https://alpha.de.repo.voidlinux.org/static/xbps-static-lates... then execute

./xbps-install -S --repository=https://alpha.de.repo.voidlinux.org/current -r / base-system

and call it a day.