Kvrocks (under Apache foundation umbrella) is another interesting Redis-compatible alternative, this one is targeting memory and SSD/NVME storage since it is implemented on top of RocksDB. So depending on your needs it may be a more efficient choice compared to Valkey.
That's a cool one, thanks, I find RockDB-like solutions a very nice niche for performance computing (e.g. ClickHouse, erigon), but I think with all the backing by huge corporations, Valkey will be the replacement for Redis.
> btw is it normal for families to call appraisers?
Well, sorry to say but no, it is not "normal" in the sense every family does this - something only seen for rich people or those who have problems dividing wealth
You have to do it any time there are more than one child, because then the estate needs to be divided up accurately. You also have to do it any time there is anything significant in the inherited properties, because this needs to be taxed.
It’s something a notary require to execute the deceased’s will, you cannot not do it in general. You need it also for houses and buildings, in which case an assessment from an estate agent is usually enough.
I use slides.com, I find it perfect for my needs. The solution to go with plain text and Pandoc and git is ok for software guys but if you want to make nice slides easily I find slides.com to be very effective. Just my 2 cents!
I do not know Slate JS (yet), but I think it is worth
mentioning react-draft-wysiwyg[1], a rich text editor
made on top of React and Draft. I used it in one of
my projects and it was really cool.
Thanks for your reply. So even at Microsoft developers have to write documentation themselves ? There are no technical writers to help ? I do not know how to catch up with the documentation now there are tons of undocumented code - your ideas are great for ensuring the situation won't reproduce but I need to catch up too. Thanks.
So for public facing documentation on an API there are technical writers (like for support docs) but for internal documentation we are expected to keep code well documented. Yeah it might be good to just start having these safeguards and as the code base churns it will gradually get fixed.
Thanks for your reply. I have another question though : how would you do if there were already a lot of undocumented code ? Would you organise a "documentation retreat" to catch up then doing as you say, documenting before coding ?
Paying down the technical debt is a tricky one, especially if your application is large. If you have the cash, it might be worth it to bite the bullet and hire a consultant/freelance technical writer. Get them to build up the documentation that you are missing, and then make sure your workflow enforces that it stays up to date.
How does Nix compare with conda[0] ? I could not find any useful resource, in my team we were hesitating between the two, for packages management ; finally we went for conda because it (seems)is better documented and package description is easier to write for newbies. And also we are a Python shop, so other devs felt more comfortable with conda. Personally I prefer Nix, though, and I wanted to advocate for it but the only main difference I could find is that Nix sits on top of the kernel (including libc...) whereas conda uses the system libc.
Not to put down Nix, but some of the arguments about other systems have counterexamples. For instance, it's common in rpm or dpkg distributions to have multiple versions and implementations of things, and richer dependencies than simply on packages. You can also do unprivileged installation into a separate root with, say, fakechroot or PRoot, and you need something like that to install and run Nix unprivileged, don't you?
There are comparisons with alternatives in at least the propaganda for Spack and 0install, though the same criticism might apply to those -- I don't remember.
You can install Nix in a totally unprivileged fashion, without having to use hacks such as PRoot, you just need to configure it to use a directory you have write access to instead of /nix. But doing so breaks the ability to use the official binary caches (because relocating the store requires recompiling packages), and this isn't particular to nix (I remember that portage at least does this too, and probably some others).
The interesting part is that with an installed deamon, the admin can allow users to install packages in their own profile, while still benefiting from sharing of dependencies and other niceties.
About the multiple versions, the problem with "classical" package managers is that you have to do some manual renaming to ensure that both versions won't be installed in the same place in the file-system, which is tedious and doesn't scale well. Furthermore you may encounter some problems because both will be visible at the same time if the packager isn't careful enough. For example, if a software X has a dependency of libfoo2.1 and you happen to have libfoo3.1 also installed, the installation script for X may use libfoo3.1 instead of libfoo2.1, in which case you risk to encounter bugs because X hasn't been tested against libfoo3.1.
rpm and dpkg don't support having multiple versions and implementations of things simultaneously installed. Not sure what you mean by richer dependencies.
>You can also do unprivileged installation into a separate root with, say, fakechroot or PRoot
Yes, but that's the only way to (safely) use such package managers without privileges; so that's not viable to do for production.
>and you need something like that to install and run Nix unprivileged, don't you?
Install, yes. Run, no. Setting up Nix does require root, but once it's installed on a system it can be safely used without privileges by all the users on the system. That's very valuable in itself, but it's especially interesting when you consider providing access to a single Nix store over a network filesystem, or providing it to multiple different virtual machines or containers.
On RHEL 6 I count eight different packages implementing the MPI standard -- multiple versions of three implementations of essentially the same API -- which can be installed together. The richness is that dependencies are not generally simply on packages; MPI packages provide things like "mpi", "openmpi(x86-64) = 1.10.3-3.el7", "libmpi.so.12", and config(openmpi) = 1.10.3-3.el7".
My Guix installation runs using a with privileged access to the store, and Nix is the same as far as I know. I don't know why Nix would be a particular advantage on our HPC networked filesystems, and it's not clear it's tenable for users to be able to DoS the store by installing an arbitrary amount of software in limited shared space.
It may well be that Nix makes the right set of trades-off against other possibilities for a given situation, but thta seems at least not completely clear cut.
You claim that conda "isn't very well supported by Unix as a whole" and "doesn't really work." Can you provide some evidence or examples to back up your claim?
Sorry, I guess it basically requires you already know the ways in which Conda doesn't work. The basic problem is that Unix has a lot of hardcoded paths and no way to override them all at runtime. So you need to do lots of patching and hacks.
I use conda every day in my professional deep learning practice and it's a HUGE time saver. I can't press enough how I'm sure it's already saved me weeks if not months of package butfucking.
Really awesome. I wonder which JS library is used for the
plotting itself ? Is it made by you guys ? Is it open
source ?
Thanks and keep on with the good work !
We just use canvas for drawing. SVG is tempting because it would help with things like figuring out which curve a user clicked on, but we've been disappointed by SVG performance and cross browser differences every time we've tried it.
