The board should have stepped in and fire whoever signed off on it, the designers who have advocated this (because they have no taste thus not fit). I feel like Apple is running on the momentum of Steve Jobs.(The hardware is good though). I cannot realistically expect them to go McMaster Carr but at least rollback these distracting light pollution
So what? compiler should catch bugs as soon as possible, as much as possible, at compile time, if it can do this fast, great! if not, then not that great, but far better than chewing through billions lines of code and do nothing, leaving you all your bugs to the run time.
I find myself in the need of a "lib_download" a few times, a high level library that:
- support HTTP/HTTPS
- support proxy (for by-passing firewall, censorship, etc, http/https/socks5)
- download one large file in parallel (configurable temporary directory)
- download many small files in parallel (seems too high-level to put in a library, not sure this is a good feature)
- configurable retry (maybe too high-level to put in a library)
- resume download
- good error semantics
- an interface with defined behaviour
- progress report (useful for downloading large files)
I tried using a wrapped (in rust) version of libcurl, and in the end I decided to just use the curl cli, and read through the man page and pass about 13 arguments to it to make it's behaviour defined (to me, to a certain confidence level), I also pinned the curl executable to a specific version to avoid unknown changes.
The end result works, but the process is unnecessarily complicated (invoke the cli binary, know what argument to pass, know the meaning of the many error codes), and the resume is not pleasant to use. I guess libcurl is designed to be that way, so that to an curl-master, he can tune all the knobs to do what he want, but to a average library user who just want to download things, it requires more attention than I'm willing to give to.
Used in an interactive context, the issue of defined behaviour is usually overlooked, but when used a library in a program that runs unattended and expensive to upgrade/repair, achievable defined behaviour is a must, and test is not an alternative to it, even experience is not an alternative (experience are time consuming to get, and not transferable to others).
All package managers needs to download packages from internet, often via HTTP, it's good to have a easy-to-use, well-defined, capable download library, many of them uses curl (Archlinux's pacman, rust installation script), many of them use others with varying level of capabilities, I thinks it would be beneficial if we can have a good library (in rust) for download things.
- handles large files effectively (build artifacts, 10-40GiBs each, and other binary dependencies)
- partial checkout of the repo/view
- git style operations (have stage area, can stage parts of a file, can stash changes and reapply later, cherry pick)
- can view the history of an individual file (support file relocation)
- access control on individual files, and partial review of the repository (views are "granted" to developers)
- good tooling
- immutable when it makes sense (e.g. you cannot changed a published commit)
- works offline (if possible)
- large mono repo
I evaluated git annex and git lfs, and finally chosen Perforce, mainly for its large file handling, view for each developer and ACL, but the lack of flexibility makes me don't want to commit, and every time I do a merge, I say to myself, "uuh, this again". The other thing it lacks is the "ease of mind", with git, everything is checksummed, if the content changes, it will be noticed by git, with Perforce, you have to tell it you want to edit it. (Not nit-picking on Perforce, I actually think Perforce is a good software, its server runs flawlessly, and have a good p4v (if you don't mind the friction), I think it just lacks good tooling and git style operations)