It's fine as long as bike paths are physically separated from cars and are maintained to the same standard as roads. My college had a network of pedestrian/bike paths that they plowed in the winter, and I and many others had no problem biking year-round.
Here's Seattle's network of protected bike lanes: <https://i.imgur.com/vEDhqoz.png>. Note that many of them are flawed in one or more ways:
* There are frequent car crossings at blind alleys and driveways, often every 20-30 feet.
* Many are "protected" by flexible posts that are easily driven over.
* When protected bike lanes run next to roads, drivers often turn across them at intersections without looking.
I generated the map with Overpass Turbo: <https://overpass-turbo.eu/s/1mT6>. To make it render nicely, check "Don't display small features as POIs" under settings. If you want to try it for a different city, drag/zoom it into view and hit "Run".
The "trekking bike" and "safety" profiles seem to work pretty well. The safety profile produces routes I would take any time of day and the trekking bike profile produces routes I would take outside of peak road rage hours.
I used to ride as far to the right as possible on roads without bike lanes, but then I got hit by a driver trying to squeeze past me without changing lanes.
It appears to use C3D as its CAD kernel, which is proprietary. You can't build it without a copy of C3D. I'm guessing the source will be available for inspection, but the binary will cost money.
The trackballs are listed as "completely open-source" on their website, but the mouse is listed as "open-source firmware". This is consistent with what's available on their GitHub page—the Altium and STEP files for the trackballs are available on their GitHub page, and the firmware for all their products (including the mouse) has been upstreamed[1].
The website Retraction Watch[1] aggregates these retractions and provides a database that you can query. Reference management software like Zotero[2] can use this to monitor your collection of papers and notify you when one is retracted.
I'm just speculating (and haven't read the paper yet), but it may be possible to achieve similar speedups on GPUs by pruning the smallest 20% of blocks of size ≥K×K to produce block-sparse weights[0], rather than pruning the smallest 20% of weights.
The following instructions are for Linux or macOS. It may work on Windows too, but I'm not very experienced with Windows. No special hardware is required (you can run it on a CPU; no GPU needed).
Install pyenv[0] and pyenv-virtualenv[1]. Clone the repo and set up an environment:
I worked at two small ISPs, each with a fiber network spanning a few US states. They had their own databases to track this information, but as far as I know there was no central database. One of them used OSPInsight backed by a self-hosted SQL Server database. I don't know what the other place used.
It's not the case that malloc always works under Linux. It may return NULL if the memory is not available. Try it out! Write a program that allocates half your memory, fills it with 0xFF, then sleeps. Run two instances of it. The malloc will fail in the second one.
According to [1], the OOM killer is a consequence of the fork syscall, and can't be removed without breaking backward compatibility.
I had the same issue. I disabled them in xmodmap for several years, then eventually decided I was never going to use them and cut out the rubber dome. Here's what it looks like: https://i.imgur.com/Bm6KtIN.jpg
