daniel_rh

I've been looking for a really engaging solid intro to number theory course on youtube, including rings, Abelian groups, etc for early teens.

Does anyone have a recommendation here?

Or go for one of these gamified math tutorials.

For instance: this one teaches geometric proofs without mentioning the formalism, just letting you "unlock" the tools from a few "axiom" starter tools.

https://www.euclidea.xyz/

This is similar to the solution we used in Vega Strike https://www.vega-strike.org/ detailed here https://graphics.stanford.edu/~danielh//classes/VegaStrikeBl...

This article mentions the woes of circular imports. I thought MyPy let you work around that by doing if False: around your imports

eg a.py: import c

  if False:
     import b

  class X:

   def x(self):
       #type: () -> b.Y
       from b import something_that_returns_y

       return something_that_returns_y(self)

  from a import X

  class Y:

    pass

  def something_that_returns_y(x : X) -> Y:

    return Y()

I think the newer version of this is https://github.com/bazelbuild/rules_rust which lets you either vendor the dependencies or pull them from your Cargo.toml directly every time.

Per the article: bazel + rules_rust should have the flexibility to override the linker flags that Cargo may take as required since that would be a property of the bazel toolchain used.

It's a nice amalgamation of how cargo works and how bazel works.

In general bazel supports hermetic builds, multiple toolchains, cross complilation, and ways to compile multi-language projects.

I still wish that Cargo.toml didn't support build.rs as it can cause a lot of system-dependent problems that bazel sidesteps entirely by being hermetic.

Does anyone have experience with eBPF on aarch64? How well is it supported? On what kernel revisions was it phased in and well tested there?

I was just experimenting with eBPF and ran into a limitation: Is there a way to load the source IP into a register when working in userspace? When I SO_ATTACH_BPF to a SOCK_DGRAM it only makes the udp header accessible, per https://github.com/danielrh/bpf_buffer_per_source/blob/main/... I would love to be able to run logic based on both IP and port rather than being limited to port alone. Yet it's not worth the inconvenience/danger of running as root to operate with RAW sockets.

Highly recommend http://privateer.sourceforge.net/ Gemini gold

Hi! Just noticed this post :-) I started the game in the late 90’s and open sourced it in 2001 The previous versions were win Mac Linux but the current dev team has been focusing on Linux right now.

At the time there were some mod communities like privateer Gemini gold with a polished release and Vega Trek; those also had windows builds that also work on wine. You might need to install into a folder with read/write permissions.

Ya we briefly corresponded in a mailing list some time back... he liked the multiplayer version, but wasn't interested in opening the source code yet. Maybe one of these years he will--I should reach out again... until them I have some pretty well annotated IDA file

Wow you played begin too! I added multiplayer through DOSbox--

it was interesting that the AI craft were just like player craft but had a different controller. It was possible to splice in keyboard input for that. Then I wrote some screen scraping software to send the commands remotely.

Here's the software project http://begin2.sourceforge.net/

Unfortunately the sourceforge matchmaking server has long gone offline, but you could connect direct to IP addresses too, so it should still be playable

the way you run it is... run a retail copy of WC.EXE with the branch of dosbox3d then do wcnet startserver <port> on one machine and wcnet connect <ip addr> <port> then both machines just run wing commander as normal. and the first one can start the first mission and the other connects in and gets to play as spirit. You can play through the whole campaign this way

the clock rate isn't quite enough--because more enemies do cause it to advance the program counter more... really you do want to measure how long the frame took and sleep the interim

It was WC1 and I disassembled the code and added in a time-dependent limiter in dosbox. I also added multiplayer--it's not quite documented and ready for consumption, but if you're interested in how it works, the code is right now up as a patch to dosbox in the wcmulti branch https://github.com/danielrh/dosbox3d/tree/wcmulti most of the changes are in the src/cpu/core_Normal.cpp and src/cpu/wc_net.cpp

There's the family plan which offers up to 6 members an account for a great monthly price.

https://help.dropbox.com/accounts-billing/plans-upgrades/dro...

With Dropbox Family, each member of the plan has their own Dropbox account. A single person, the Family manager, will manage the billing and memberships for the entire Family plan.

For long term storage of blocks, we compress at much higher compression levels like you mention. These densely compressed blocks are, in turn, served directly to customers when they download their own files.

For uploads you're right: we'd be theoretically better off with high performing zstd, but there are maintenance costs with maintaining 2 separate compression pipelines that are similar, but different, for upload and downloads.

Plus there is no safe rust zstd compressor and the safe rust zstd decompressor linked in this thread is only recently available and is also several times slower than the safe rust brotli decompressor.

We heavily investigated zstd and met with the brilliant inventor, Yann, who provided amazing insights into the design and rationale behind zstd and why it is so fast and such an amazing technology. I also recompiled zstd into rust using https://github.com/immunant/c2rust and tried using various webasm mechanisms to run it (I didn't get webasm quite fast enough, and teaching c2rust to make it safe would be quite a slog).

But the main reason we settled on Brotli was the second order context modeling, which makes a substantial difference in the final size of files stored on Dropbox (several percent on average as I recall, with some files getting much, much smaller). And for the storage of files, especially cold files, every percent improvement imparts a cost savings.

Also, widespread in-browser support of Brotli makes it possible for us to serve the dropbox files directly to browsers in the future (especially since they are concatenatable). Zstd browser support isn't at the same level today.

Great question! We developed and deployed Lepton to losslessly encode JPEG image files. Lepton continues to deliver substantial storage and cost savings every year. You can read more about it here https://dropbox.tech/infrastructure/lepton-image-compression...

if a user has uploaded a file in the past and their desktop client can prove they have access, then they can avoid uploading it again

Savory with a touch of sweetness, Broccoli Bread cooks up like cornbread but offers fiber and calcium. The original name was Brot-cat-li (since files could be concatenated and compressed in parallel), but when we said it fast it sounded like "Broccoli" and the name stuck.

Dropbox uses a similar toolbox as https://chromium.googlesource.com/chromiumos/docs/+/master/s...

And yes, much of the overhead stems from the RPC server that needs to be implemented. For lepton we used a raw TCP server (a simple fork/exec server) to answer compression requests. For Lepton we would establish a connection and send a raw file on the socket and await the compressed file on the same socket. A strict SECCOMP filter was used for lepton. It was nice to avoid this for broccoli since it was implemented in the safe subset of rust.

Hi folks, I'm Daniel from Dropbox, and I am happy to answer any questions about this tech.

2 words: bash reduce

(eg using cut, sort, split -l, nohup, ssh to orchestrate a massive job with only bare unix tools available)

I can't find any information on linux support with KSP2. Does anyone have a link with more linux information? One of the many reasons I loved KSP was robust linux support.

or written in a secure language without undefined behavior and without any "unsafe" code like Rust or Safe Haskell.

IoT probably should be shipping code that uses static compiler checks as the first line of security defense rather than run-time checks like valgrind and asan.

Optometrists and Ophthalmologists both have training to check for disease in the eyes. In fact a dilated eye exam is a non-invasive way to get an actual look into your circulatory system to check for things like diabetes. So even people without glasses should be getting regular checkups.

Ophthalmologists also have specialized training for cutting the eye that they learn in medical school (eg: lasik), but for eye exams, an optometrist has the skill-set necessary to perform these kinds of screenings.

A lot of people just get auto-refracted or a checkup by an optician and assume that's enough to get new glasses, but those people can be among the tens of millions of Americans who don't realize they have pre-diabetes.

Does this abstraction target WebGL as well? I could imagine it being a nice portability layer for web-aware apps since rust can easily target wasm with a few compiler flags.

I love that the relooper can be disabled! I think that option will be really useful while the heuristics are being tuned, since many codebases avoid goto as a matter of style and can probably be translated without it, or with minor tweaks.

I'm a big corrode fan and I used it (plus a really simple python script https://github.com/dropbox/rust-brotli/blob/master/uncorrode... ) to help translate the brotli encoder https://github.com/google/brotli/tree/master/c/enc to safe, almost-idiomatic rust.

My initial attempts used top of tree corrode, but I found that the relooper got in the way of writing idiomatic rust, so I restarted my translation efforts and actually pinned corrode to before the relooper and backported a lot of the improvements that happened since the relooping effort https://github.com/danielrh/corrode/tree/unprocessed_loops

On one hand I'm very glad corrode supported the relooper: it got me excited about the capabilities of corrode, but in the end I think any serious port of a project is going to need to think about idiomatic control flow and will require a minor rewrite of the C code. The improvements to the C brotli encoder happened here https://github.com/danielrh/brotli/commits/corrode to remove the gotos and some negative array access.

All in all, the process to get the brotli encoder into rust was very smooth. Much of it may be due to the google engineers being extremely careful about memory ownership and design.

Anyhow I'm excited about c2rust, but am nervous that corrode may be de-emphasized since I know it worked well for me.

If you want to know more about the experience of porting a large existing project to rust, I posted about the rust brotli decoder here https://blogs.dropbox.com/tech/2016/06/lossless-compression-... (subsection "The Port")

DivANS author here: the compression benchmarks all measure seekability to the nearest 4MB chunk, but the current lib itself doesn't support seekability out of the box, yet. However, it would be trivial to reset the encoder at each 4mb chunk and could even be done without additional library support by just reinitializing the compressor (or decompressor) each 4mb