| # the following two lines give a two-line status, with the current window highlighted | |
| hardstatus alwayslastline | |
| hardstatus string '%{= kG}[%{G}%H%? %1`%?%{g}][%= %{= kw}%-w%{+b yk} %n*%t%?(%u)%? %{-}%+w %=%{g}][%{B}%m/%d %{W}%C%A%{g}]' | |
| # huge scrollback buffer | |
| defscrollback 5000 | |
| # no welcome message | |
| startup_message off |
| # | |
| # Working with branches | |
| # | |
| # Get the current branch name (not so useful in itself, but used in | |
| # other aliases) | |
| branch-name = "!git rev-parse --abbrev-ref HEAD" | |
| # Push the current branch to the remote "origin", and set it to track | |
| # the upstream branch | |
| publish = "!git push -u origin $(git branch-name)" |
This is a plain-text version of Bret Victor’s reading list. It was requested by hf on Hacker News.
Highly recommended things!
This is my five-star list. These are my favorite things in all the world.
A few of these works have had an extraordinary effect on my life or way of thinking. They get a sixth star. ★
| #include <stdio.h> | |
| #include <string.h> | |
| #include <stdlib.h> | |
| #include <gmp.h> | |
| char * polynomial="-74101463560860539810482394216134472786413399/404009590666424903383979388988167534591844018460526499864038804741201731572423877094984692537474105135297393596654648304117684895744000000000000000000000*x^99 + 1786563401621773217421750502452955853226339781/1943688752347061390850759947022111850270039951356484879070977067483444756705819339975871373032521468004867185688372878439054154137600000000000000000000*x^98 - 27321291157050372775340569532625689973429185264741/12024094960310264981666053243695462339042976739896622019763059664916718201560234437350734896948634081407660523709959770955883479040000000000000000000000*x^97 + 4936870031754926645682423836151042176171669450909/1336493173680525187613977630110369004256312194947800263402124063124652591386915768177479078216982141485276408003996973457735680000000000000000000000*x^96 - 24473118674386691114350902920738421254018653211816783/55093218603941649400531744530105211175454647 |
04/26/2103. From a lecture by Professor John Ousterhout at Stanford, class CS142.
This is my most touchy-feely thought for the weekend. Here’s the basic idea: It’s really hard to build relationships that last for a long time. If you haven’t discovered this, you will discover this sooner or later. And it's hard both for personal relationships and for business relationships. And to me, it's pretty amazing that two people can stay married for 25 years without killing each other.
[Laughter]
> But honestly, most professional relationships don't last anywhere near that long. The best bands always seem to break up after 2 or 3 years. And business partnerships fall apart, and there's all these problems in these relationships that just don't last. So, why is that? Well, in my view, it’s relationships don't fail because there some single catastrophic event to destroy them, although often there is a single catastrophic event around the the end of the relation
From a lecture by Professor John Ousterhout at Stanford.
Programmers tend to worry too much and too soon about performance. Many college-level Computer Science classes focus on fancy algorithms to improve performance, but in real life performance rarely matters. Most real-world programs run plenty fast enough on today's machines without any particular attention to performance. The real challenges are getting programs completed quickly, ensuring their quality, and managing the complexity of large applications. Thus the primary design criterion for software should be simplicity, not speed.
> Occasionally there will be parts of a program where performance matters, but you probably won't be able to predict where the performance issues will occur. If you try to optimize the performance of an application during the initial construction you will add complexity that will impact the timely delivery and quality o
This is the process I followed on my Fedora 23 host machine to build a small/minimal vanilla Linux kernel and test in Qemu (based on this blog post). This will provide a safe sandbox in which to test kernel changes, and is generally faster than developing natively on the host machine. Qemu will boot the kernel image directly in the emulated system.
sudo dnf install ncurses-devel kernel-devel kernel-headers gcc gcc-c++ git qemu openssl-devel glibc-static
Satoshi Nakamoto's development of Bitcoin in 2009 has often been hailed as a radical development in money and currency, being the first example of a digital asset which simultaneously has no backing or "intrinsic value" and no centralized issuer or controller. However, another, arguably more important, part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus, and attention is rapidly starting to shift to this other aspect of Bitcoin. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies and financial instruments ("colored coins"), the ownership of an underlying physic
The easiest way to "convert" MKV to MP4, is to copy the existing video and audio streams and place them into a new container. This avoids any encoding task and hence no quality will be lost, it is also a fairly quick process and requires very little CPU power. The main factor is disk read/write speed.
With ffmpeg this can be achieved with -c copy. Older examples may use -vcodec copy -acodec copy which does the same thing.
These examples assume ffmpeg is in your PATH. If not just substitute with the full path to your ffmpeg binary.