HN user
kbr2000
The article sums up quite well which principles are at play here. The fun part it's suggesting (without words), is either to pick it apart and see what each part does, play around with the constants in there, or start from scratch and roll your own... (all with the Shadertoy linked below the article maybe?)
I would say most interesting texts (articles, books, school, ...) should leave stuff up to the reader's mind to figure out. That's how someone really learns. Versus pre-baked stuff like television etc.
If something does not resonate at first that's pretty normal. You could still take it apart and start investigating words or concepts that ring no bell, for example: waves, interference, demoscene, owls, Feynman.
Enjoy! ;)
The delta-transfer algorithm [0] is about detecting which chunks of a file differ on source and target [1], and limiting the transfer to those chunks. The savings depend on how and where they differ, and ofcourse there's tradeoffs...
You seem to be referring to the selection of candidates of files to transfer (along several possible criteria like modification time, file size or file contents using checksumming) [2]
Rsync is great. However for huge filesystems (many files and directories) with relatively less change, you'll need to think about "assisting" it somewhat (by feeding it its candidates obtained in a more efficient way, using --files-from=). For example: in a renderfarm system you would have additions of files, not really updates. Keep a list of frames that have finished rendering (in a cinematic film production this could be eg. 10h/frame), and use it to feed rsync. Otherwise you'll be spending hours for rsync to build its index (both sides) over huge filesystems, instead of transferring relatively few big and new files.
In workloads where you have many sync candidates (files) that have a majority of differing chunks, it might be worth rather disabling the delta-transfer algorithm (--whole-file) and saving on the tradeoffs.
[0] https://www.andrew.cmu.edu/course/15-749/READINGS/required/c...
[1] https://en.wikipedia.org/wiki/Rsync#Determining_which_parts_...
[2] https://en.wikipedia.org/wiki/Rsync#Determining_which_files_...
"It was able to squeak, but not to speak. Experts and professors wrestled with it in vain. It refused to transmit one intelligible sentence." [0]
"A translation of Legat's article on Reis' invention was obtained by Thomas Edison prior to his filing his patent application on a telephone in 1877. In correspondence of 1885, Edison credits Reis as having invented "the first telephone", with the limitation that it was "only musical not articulating"." [1]
Fascinating stuff nonetheless, these inventors and their ideas... See also previous experimenters [2]
[0] https://en.wikipedia.org/wiki/Johann_Philipp_Reis
[1] https://en.wikipedia.org/wiki/Reis_telephone
[2] https://en.wikipedia.org/wiki/Johann_Philipp_Reis#Previous_e...
Or rather:
You must have a filesystem, located on the /dev/sda4 device, mounted at /mnt/lfs.
The /dev/sda4 device represents the fourth (primary) partition on the /dev/sda block device, which represents the first SCSI disk.
Seems like a good fit for Expect.
Ralph Griswold (also known for the Icon programming language [0]), started the On-Line Digital Archive of Documents on Weaving and Related Topics [1] at the time, a gem.
batshit?
lol, reminds me of this Monkey Dust one: https://www.youtube.com/watch?v=o2j_hXHEjX4
It permits you to config more complicated backups more easily. You can inherit and override rules, which is handy if you need to do for example hundreds of similar style backups, with little exceptions. The same with include/exclude patterns, quickly gets complicated with just rsync.
It generates indices for its backups that allow you to search for files over all snapshots taken (which gives you an overview of which snapshots contain some file for you to retrieve/inspect). See dirvish-locate.
Does expiration of snapshots, given your retention strategy (encoded in rules, see dirvish.conf and dirvish-expire).
It consistently creates long rsync commandlines you would otherwise need to do by hand.
In the end you get one directory per snapshot, giving a complete view over what got backed up. Unchanged files are hard-linked thus limiting backup storage consumption. Changed files are stored. But each snapshot has the whole backed up structure in it so you could rsync it back at restore time (or pick selectively individual files if needed). Hence the "virtual".
Furthermore: backup reporting (summary files) which you could be piped into an E-mail or turned into a webpage, good and simple documentation, pre/post scripts (this turns out to be really useful to do DB dumps before taking a backup etc.)
You'll still need to take care of all other aspects of designing your backup storage (SAS controllers/backplanes/cabling, disks, RAID, LVM2, XFS, ...) and networking (10 GbE, switching, routing if needed, ...) if you need that (works too for only local though). Used this successfully in animation film development as an example, where it backed up hundreds of machines and centralized storage for a renderfarm, about 2 PBytes worth (with Coraid and SuperMicro hardware). Rsync traversing the filesystem to find out changes could be challenging at times with enormous FS (even based on only the metadata), but for that we created other backup jobs that where fed with specific file-lists generated by the renderfarm processes, thus skipping the search for changes...
Dirvish [0] is worth looking at, light-weight and providing a good set of functionality (rotation, incremental backups, retention, pre/post scripts). It is a scripted wrapper around rsync [1] so you profit from all that functionality too (remote backups, compression for limited links, metadata/xattr support, various sync criteria, etc.)
This has been a lifesaver for 20+ years, thanks to JW Schultz!
The questions/topics in the article go really well along with it.
LCAL[0]: The Moon Phase Calendar Program
A PostScript program to visualize a calendar of moon phases (skip down to "LCAL PostScript Calendar Examples" for just that). Did some nice PS prints recently for the next 10 years, adapted to fit in a frame I had laying around.
Cool indeed. A spin on it (also using POV-Ray), but using a photo (texture on an object) and animated (rotating that object, the texture, or the mirrors -- I forgot) in [0] and [1].
[0] https://www.youtube.com/watch?v=UJaBspDXgzs [1] https://www.youtube.com/watch?v=Zc5uEwwr6S8
Delay/disruption tolerant networking (DTN) seeks to address these kind of problems, using alternative techniques and protocols: store-and-forward, Bundle protocols and Licklider Transmission Protocol. Interesting stuff, enjoy!
Awk: Aho, Weinberger & Kernighan [0]
Tcl: (an embeddable) Tool Command Language [1]
Forth: FOURTH as in "4th generation software", "successor to 3rd generation compile-link-go languages", or "software for 4rd generation hardware", but IBM 1130 naming cut it short one char [2]
PostScript: after the postfix notation it uses and because it was to be the last thing that happened to an image before it was printed [3]
[0] https://en.wikipedia.org/wiki/AWK
[1] https://wiki.tcl-lang.org/page/Tcl+vs%2E+TCL
[2] https://en.wikipedia.org/wiki/Forth_(programming_language)
There's another guide [0] for wire wrap technique (solderless, cold welded connections to square posts [1]). Used extensively in telephony switching/patching in the past, as well as digital circuit construction like computers. Quite nice for prototyping, although qualitative sockets/posts can be hard to acquire at a reasonable price nowadays.
[0] https://workmanship.nasa.gov/lib/insp/2%20books/links/sectio... [1] https://en.wikipedia.org/wiki/Wire_wrap
Well done!
For those interested: a predecessor called the "Jesusonic" was once made by Justin Frankel (of Winamp and REAPER fame): https://www.cockos.com/jsfx/ https://wiki.cockos.com/wiki/index.php/Jesusonic_Documentati...
:)
The exmh E-mail client frontend used this: https://rand-mh.sourceforge.io/book/exmh/thexmdi.html
I came up with:
gawk 'BEGIN {IGNORECASE=1} ((length($1) == 6) && /^[a-fois]+$/) {gsub(/o/,0);gsub(/i/,1);gsub(/s/,5); print toupper("#"$1)}' /usr/share/dict/words
(caveat: it does not filter out duplicates)The title lured me into thinking it would be another Project Orion [https://en.wikipedia.org/wiki/Project_Orion_(nuclear_propuls...] :)
Indeed, bsd-games were not mentioned. Here's a list: https://github.com/msharov/bsd-games
There was Sleuth also: https://en.wikipedia.org/wiki/Sleuth_(video_game)
Personally I enjoyed IF like TATCTAE (Time: All Things Come To An End), Jigsaw and Curses! which where included in early GNU/Linux distributions (unbeknownst to me at that time that much other int-fiction was being created, since we were exploring the OS distributions offline, InfoMagic CDs etc.)
Before that, BBS door games existed (much avoided because exhuberant dialup costs). Typing in BASIC source code from books lent from the library (mostly text-based games). My interest was piqued by MUDs at one point afterwards, but never really got active (again because of dialup costs to connect to the Internet).
Great, thanks for the info! I used Tgif for exactly that, designing SNMP monitoring with network maps/dashboard like pages. Forgot exactly which combinations I implemented, but it envolved Tgif, Tkined [0], Scotty [1], Big Brother [2] and later Netsaint [3] (now known as Nagios).
[0] https://www.ibr.cs.tu-bs.de/projects/nm/tkined/welcome.html.... [1] https://www.ibr.cs.tu-bs.de/projects/nm/scotty/tcl+snmp.html [2] https://www.linuxjournal.com/article/2225 [3] http://netsaint.sourceforge.net/
Well found ;) I remember crossing this multiple times since the 90s while looking for Tgif-related info, but always in Japanese I think... and every time with marvel for his technique applied with both excellent software.
Don Hopkins, NeWS, Tcl/Tk, ...! Excellent ideas all around.
Tgif [0] is interesting too, Prolog-based, with Hyper-Structured-Graphics [1]
Not really a joke, rather a term we didn't know yet :)
The 'Graphics Programming in Icon' book is also a gem (available for free here [0]). It's written in the same (readable) form and style as the other books, and uses the added power of Icon to demonstrate how quick you can get going (take a look at their L-systems demo). There's also information on UI design.
I remember a whole library with demo programs was available with the interpreter. It included a 'caricature generator' you should check out if you can find it back, that was fun.
Apart from that, there's a treasure trove of information available in articles and newsletters (The Icon Analyst [1], and The Icon Newsletter [2]), which are filled with little projects that please the mind.
[0] https://www2.cs.arizona.edu/icon/gb/index.htm
Check Lazarus [0] for Free Pascal [1].
Another viable option would be Visual Tcl [2] for Tcl/Tk [3]. Given the event-based nature of Tcl and Tk, I find it matches well for a methodology like VB provided.
And it's far from the only one I remember (although you'll need to do some research here [4]). For example, Komodo IDE used to have a Tk GUI builder that provided for the same kind of methodology, which has been split off in [5].
Enjoy!
[0] https://www.lazarus-ide.org/
[1] https://www.freepascal.org/
[2] http://vtcl.sourceforge.net/