fleventynine

There are lots of better word processors than Google Docs, but most of the docs I contribute to are hosted on it because it requires zero friction for a newcomer to collaborate.

What I want is the equivalent of Google Docs for audio and MIDI, with a thriving ecosystem of plugins and softsynths that everyone can use in any project with zero friction (and none of this "let me bounce that track to audio since you don't have that plugin" nonsense).

For collaboration between "bedroom producers", a wasm-based plugin ecosystem would be a huge upgrade from a native DAW. I hate trying to share a project and having to worry about "do they have the right plugins/softsynths installed" and other tedious technical distractions. I'd be happy to give up 50% performance (of a native DAW) for the collaboration benefits alone.

This has never been a problem in practice. The ~90dB of dynamic range in 16-bit audio is far more than any analog format, and the noise floor after dithering to 16-bits is pretty much always well below the floor of the recording environment.

I want to program my electric car to charge whenever the instantaneous market rate is below $0.10/kwH. If the instantaneous market rate of power goes above $1/kwH, I want my air conditioner to shut off. If everyone else did the same thing, the price would never get much above that.

Shielding people from the realities of supply and demand is what leads to overconsumption. Give them tools to control their consumption based on true market rates and everything will sort itself out.

I doubt that commercial generators are making anywhere close to 22 cents a kilowatt hour at noon on a sunny summer day. They'll turn on their gas turbines later in the day when solar output has dropped and the instantaneous market rate increases.

Homeowners should be paid lots of money if they can produce power at peak demand times, incentivizing the installation of storage. This is what it will take if we really want to turn down the natural gas generators.

Regardless of the racism argument, it seems obvious to me that NEM 2.0 is forcing those who can't afford a solar system to purchase overpriced power from those who can.

I wish we'd just charge/pay people the instantaneous market rate of power. And at noon on a sunny summer day in California, the market rate should be pretty close to zero. Nowadays, the grid needs more storage and peaking generation than it does more solar panels, so we should stop artificially incentivizing rooftop solar panels.

> "just do yourself a favor and get the 4 layers boards so you can make ground and power planes"

In general, you should avoid power planes on 4 layer boards if you can. They tend to cause a lot of trouble with return currents when signals jump from the top layer to the bottom layer through a via. Prefer using ground planes for both inner layers and make sure you have ground return vias near every signal via.

https://youtu.be/kdCJxdR7L_I goes into more detail.

How is a host with a 32-bit address supposed to communicate with a host with a 128-bit address when it can only send packets with a 32-bit address?

> Even the most trivial singly linked lists....

Uh, a singly linked list is trivial to implement...

  struct LinkedListNode<T> {
    value: T,
    next: Option<Box<LinkedListNode<T>>>,
  }

Any data structure where chunks of heap memory are owned by a single pointer (red black trees, singly-linked lists, vectors, deques, circular queues, etc) can be represented easily in safe rust.

Implementing a double-linked list is where things get tricky, as the nodes don't have a singular owner.

Almost every large tech company that uses C++ heavily is jumping onto the Rust train.

The language itself is lightweight enough to use on tiny microcontrollers. Most bloat on the host side comes down to your choice of dependencies (clap is one of the worst offenders in my experience, bloating a simple command line tool by as much as 10x in both size and compile time).

> Which FPGA models support _attestation_ of the loaded bitstream? Do any?

I haven't seen this feature yet, but I desperately want it on every FPGA I use. NVCM eliminates most of the benefits of using an FPGA...

I'm not sure what you mean by multi-entry, but it's hard to beat a busybox-style binary for code-size, especially with LTO. If you're building everything into a single filesystem image anyways, this is almost always smaller than dynamic linking.

From the photo, that looks like a stock iCE40 FPGA, which does not support hardware attestation of the loaded bitstream. How does the user verify that the FPGA loaded the expected bitstream instead of something with a backdoor? A DICE chain that is not rooted in physical, immutable hardware isn't very useful.

There are millennials who are less than 25 years from retirement age.

Yes, a computer with a good low-noise ad/da converter can be an excellent compressor. But it's likely to be much more expensive than a used RNC.

Sure, but my TV can't run Audacity :)

The best thing I ever did for my den was put one of these between the TV and the speakers: https://www.fmraudio.com/rnc.html

Twiddle a few knobs and now everything is the same volume and I can keep it at a nice low level and not wake the kids, but still hear everything.

I've spent much of my career writing C++, which I consider an even more difficult language to work with than Rust. But even so, it gets used a lot for problems where performance or a low memory footprint are more important than developer productivity or memory safety.

Rust excites me because programs written in it can have similar memory safety to GC'd languages, but have similar runtime characteristics to C++ programs. I can use it to solve the same problems I previously needed C++ to solve, and also new problems where bullet-proof memory safety is a requirement.

I've been a quiet cheerleader for the language for the past 10 years because it's been the only language with community momentum that fits the niche that I care about. But I won't be hurt if some other language with similar runtime and safety characteristics to Rust replaces C++; I'll consider that a win.

Wouldn't such a law stop Google from releasing Android as open source? AOSP cost hundreds of millions of dollars to develop, but it doesn't cost anything to use.

In such a world, could companies even contribute patches to Linux? Making Linux better without expectation of profit could be considered predatory pricing against Microsoft.

If I want to buy a device that can generate a proof I can share with others to increase their trust in me, you shouldn't be able to stop me. Implemented properly, these machines can still boot whatever custom software you want; you don't have to share the proof of what booted with anyone.

Admittedly it is a simplified scenario for the sake of argument. You'd need to have a full attestation of everything that controls access to the data (including ACLs) to get much of a guarantee.

But in a future world it's not hard to imagine the vendor software running in some sort of SGX-like environment that is very difficult to manually extract the data from.

Implemented properly, the idea is that you have a chain of certificates (rooted by the CPU vendor's public key) that can identify all the different bits of software that have executed on the machine, along with a ephemeral public key. The hardware guarantees that the associated private key can only be wielded by the software versions that the chain attested to. So when you initiate your TLS connection with this machine, you can validate the cert chain and understand exactly what software the machine is running, assuming that you trust the CPU vendor and all the versions of the software that were attested to.

So how do you solve this? Get the government to ban CPU vendors from implementing hardware-rooted remote attestation? I can assure you that this technology is used inside corporations for their own internal security, and such a ban would weaken our ability to survive a cyberwar.

Right, but if they aren't going to follow best security practices and prove it (via a signed a hardware attestation of the running software that includes the transport key they want me to use to send them the data), then I'm not going to send them the data. That's my choice.

Unfortunately, it does seem likely that many services will require that your machine run a kernel/web browser signed by an entity they trust before they give you access to what they consider sensitive data. That will suck for those of us who want to build our own kernels/web browsers and use that software to interact with sensitive data from large corporations, but that's their choice to make (IMHO). And it's my choice not to use their service.

Unpopular opinion:

Hardware-based attestation of the running software is an important security feature, especially in a world where data leaks and identity theft are rampant. Let's say I'm a healthcare provider, and I'm about to send sensitive medical data to a third party vendor. Wouldn't you prefer that this data only be able to be decrypted by a computer that can prove to the world it booted a clean OS image with all the latest security patches installed?

If the vendor wants to install some self-built OS that they trust on their computer and not update it for 5 years, that's their business, but I may not want to trust their computer to have access to my personal data.

Remote attestation gives more control to the owners of data to dictate how that data is processed on third-party machines (or even their own machines that may have been compromised). This is useful for more than just DRM.

Hardware-based attestation of the running software is an important security feature, especially in a world where data leaks and identity theft are rampant.

Let's say I'm a healthcare provider, and I'm about to send your medical data to a third party vendor. Wouldn't you prefer that your data only be able to be decrypted by a computer can prove to the world it booted a clean OS image with all the latest security patches installed?

If the vendor wants to install some self-built OS that they trust on their computer and not update it for 5 years, that's their business, but I may not want to trust their computer to have access to my data.

Remote attestation gives more control to the owners of data to dictate how that data is processed on third-party machines (or even their own machines that may have been compromised). This is useful for more than just DRM.

Surface mount isn't that big of a deal. A cheap hot air gun, a soldering iron, flux, and some solder paste are all you need to work with most BGAs, QFN, and other modern packages. PCB prototype manufacturing has never been cheaper thanks to companies like JLCPCB. With all the fantastic learning material on YouTube, open source tools like KiCad, and inexpensive chinese test equipment, the kids these days can do WAY more than I could dream of back in the 90s.

Reviewing commits for a security-critical project written in C or C++ can be incredibly tedious. I've spent an entire day trying to validate that the assumptions made by a 10-line change are memory-safe in the context of the larger program. These reviews are incredibly mentally draining, and even when I'm done I'm not 100% sure that I didn't miss something and let a vulnerability into the codebase.

Rust is a breath of fresh air in comparison. Worrying about memory safety isn't even a concern for the vast majority of commits that don't touch modules with unsafe code. All assumptions made about the lifetimes of references are made explicit in the code, and checked by the compiler. On rust projects I find I have much more mental energy to use against other aspects of the problem.