It's not diverse in that case - it's the same compiler source compiled to binaries twice - it's just that with one compiler you've gone via a C intermediate representation. For the purposes of diversity it's the same as compiling rustc with the cranelift/gcc backend.
I use mmap with my SQLite database[1] because I have many concurrent SQLite connections (one per concurrent HTTP request) and I don't want each connection to have its own 2MB cache[2]. It's better that all the connections simply share the page cache.
> The memory map can be used as a read-only or read-write map.
So presumably lmdb writes to the database using the `pwrite` syscall by default, but can optionally write via the mmap instead - if you are willing to accept the increased risk of accidental data corruption.
> A good fix (which is the only acceptable fix in open-source software), is one that speaks for itself.
I disagree. Often if I'm making a PR to an open-source project I'm doing so because I have a use-case that the original author hadn't considered. So the first step in getting the PR merged is explaining my point of view and convincing the maintainer that my use-case is valid. Only when this is done can the "goodness" of the patch be evaluated.
I disagree. An HTML website which uses links, forms, buttons and inputs will by default:
* Have working back/forward buttons
* Have working progress indicator as provided by the browser
* Show errors to the user - even if they are ugly
* Be accessible to keyboard navigation
With SPAs these are all things the developer has to get right.
So often when using a SPA I'll click a button, you get a spinner and then nothing will happen. Is it still in progress? Don't know. Eventually I'll open developer console and trace the network requests to find the JSON HTTP request that returned "ERR_BAD_EMAIL" and fix what I've entered. With a normal form submission at least the user will see the error message and can press back and then fix it.
I design all my services expecting to receive sockets this way. It makes sandboxing easy as the service itself doesn't need network access to have a listening socket.
It's a shame docker never supported it. I feel like if they had got on board all those years ago there would be broad support across the software ecosystem for it and we wouldn't need half of these complicated iptables rules and proxies and service mesh. It would be a step towards a capability based system.
I've implemented something similar in the past, but using inotify. You need to watch the -wal file for IN_MODIFY. To make it work reliably I found I had to run:
BEGIN IMMEDIATE TRANSACTION; ROLLBACK;
Otherwise the new changes weren't guaranteed to be visible to the process. I'm sure there's a more targetted approach that would work instead - maybe flock on a particular byte in the `-shm` file.
SQLite in mmap mode (not the default) will use mmap for reading. It will still use write using `pwrite` so it can detect and recover from write failures.
> The default mechanism by which SQLite accesses and updates database disk files is the xRead() and xWrite() methods of the sqlite3_io_methods VFS object. These methods are typically implemented as "read()" and "write()" system calls which cause the operating system to copy disk content between the kernel buffer cache and user space.
> Beginning with version 3.7.17 (2013-05-20), SQLite has the option of accessing disk content directly using memory-mapped I/O and the new xFetch() and xUnfetch() methods on sqlite3_io_methods.
The principal advantage to mmap in my mind is that the cache is shared among your SQLite connections.
It's a shame that unix tools don't support file descriptors better. The ability to pass a file (or stream, or socket etc) directly into a process is so powerful, but few commands actually support being used this way and require filenames (or hostnames, etc) instead. Shell is so limited in this regard too.
It would be great to be able to open a socket in bash[^1] and pass it to another program to read/write from without having an extra socat process and pipes running (and the buffering, odd flush behaviour, etc.). It would be great if programs expected to receive input file arguments as open fds, rather than providing filenames and having the process open them itself. Sandboxing would be trivial, as would understanding the inputs and outputs of any program.
It's frustrating to me because the underlying unix system supports this so well, it's just the conventions of userspace that get in the way.
[^1]: I know about /dev/tcp, but it's very limited.
I guess that means you're using the colloquial meaning of the word safety/unsafe rather than the rust definition. It's worth being explicit about that (or choosing a different word) in these discussions to prevent confusion.
For Rust safety (meaning no UB) most definitely is a property of the language. If a module does not contain unsafe and the modules it uses that do contain unsafe are implemented soundly then there is no UB.
> in C only specific language features are unsafe and not all code
Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without:
* Dereferencing pointers
* Array access
* Incrementing signed integers
You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from the ones that can't.
Use a connection per-thread instead. By sharing a connection across threads you’ll be limiting concurrency - and transactions won’t work as you’d expect. SQLite connections are not heavy.
Retries won’t work in that case. Would be better to have two endpoints: get the time in x seconds and wait until time passed. That way retrying the wait endpoint will work fine and if time hasn’t elapsed it can just curl itself with the same arguments.
No, actually the biggest difference is removing the `filter` property from the `.wave2` class which is used for rendering the background. With that removed the page is responsive even with the backdrop-filter - and it makes no visual difference AFAICS.
Discussed here: https://news.ycombinator.com/item?id=31249823
But it would be a lot better if it were built in.