HN user
hfuchs.net
One particularly mnemonic collection of switches is 'plane':
perl -plane 'my $script'
+ (p)rints every processed line back out
+ deals with (l)ine endings, in and out
+ (a)utosplits every line into @F
[Late reply -- forgot to hit the button. ;]
Thank you for the pointer and, more so, your contributions.
That screenshot of SICP in Emacs -- running side-by-side with the built-in Guile interpreter -- induces peculiar sensations. An echo of how things could've been and possibly still are in some obscure(d) corners of the Net. An interactive learning environment that at least points in the right direction. It certainly looks elegant and somewhat inspirational to me (though my inner Alan Kay is voicing some profound objections ;).
In any case: you carried that torch for a while, don't be hesitant accepting apparently undue credit -- there's too little, in any case, to warrant worry. ;)
If you wanted to delve into the original 1984 LISP/Scheme version by Abelson and Sussman, I recommend you take a look at
https://opendocs.github.io/sicp/sicp.pdf
which is based on the MITPress HTML version, released under a permissive CC-by-SA license.
https://mitpress.mit.edu/sites/default/files/sicp/index.html
(nb. The pdf starts out with a curious little 'texinfo foreword'. Being able to type `info sicp` in one's shell? I wonder ...)
What? Do the docs on the page really say that[0]?
':back' is mapped to 'H' -- in correspondence to the usual Vi/Vim paradigm to move the cursor with the home-row keys, hjkl. ':open' is naturally mapped to 'o' and drops you into a tab-completable shell. ':tabopen' -> 't' and so on.
The key part, as in Vim, are /not/ the mnemonic, highly effective shortcuts. Rather, it's the modal workflow that Vim and it's spritual descendants bring to the table. I'll leave it at that (sounding like a damn preacher already).
[0] Now that I've looked at it, it becomes clear that they're selling rather directly to Vim-acolytes. Pity, perhaps.
Neat, thanks. Works identically with the slightly smaller fork called Pentadactyl (http://5digits.org/pentadactyl/).
FDE: Full Disk Encryption.
Sure, I'll try to elaborate.
Suppose you're reading a biography of Huygens. You may find yourself inspired to memorize a few of the basic facts therein. Dutifully, you feed his life's dates, his major acquaintances and maybe a few places of importance into the SR system of your choice. You are committed and keep repeating those facts in ever-increasing intervals.
After a few years a random conversation touches upon the very subject. To your delight you discover that you are able to hold forth on Huygens, the man and his time.
To your surprise (and this is my contention [and experience]), you also find yourself able to speak with some level of accuracy about tangential matter -- eg. the theories he worked on -- without ever having either added related facts to the database or dealt with the subject matter in the intervening years.
In other words: recall of a whole web of interconnected pieces of knowledge may be strengthened considerably by spaced repetition of just a few of the central facts.
In my experience there's no specific 'encoding' procedure necessary. I never put any thought into carefully selecting facts for the spaced repetition treatment, yet the effect usually manifested itself. So, yes, I would say it's a 'recall' phenomenon inasmuch as the brain does all the heavy lifting.
I wrote a program I fancifully called 'Human Unit Tests' to aid me in my studies (learning a diverse set of constants for biophysics). I can very much attest to the effectiveness of spaced repetition.
But, /boy/, do you need to stay on the ball. You can't really afford a cavalier, let's-see attitude with this (given any non-trivial amount of items-to-be-memorized). The review process needs to be as much part of a daily routine as workouts ... Yeah.
On the other hand, there's one reward that doesn't usually get mentioned (as in the fine article re-submitted here[0]): the strengthening of corollary knowledge (or coordinate terms, for the linguistically inclined).
[0] Previous submission: https://news.ycombinator.com/item?id=5809762
I simply cannot wrap my head around the direction of the Unicode discourse.
We're discussing the appropriate code-point for different smiley faces, obscure electrical symbols[0] or, in the present case, half stars to express film or book ratings, yet we have no complete set of sub- and superscripts!
Am I mistaken in thinking it odd, that there's a complete Klingon alphabet but no representation whatsoever for most Greek or Latin subscripts? Or what if, heaven forbid, I'd want to use a 'b' index/subscript? Tough! Not even the "phonetic extensions", where subscript-i comes from, provides it.
Refer to https://en.wikipedia.org/wiki/Unicode_subscripts_and_supersc... or look for SUBSCRIPT in http://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt
Surely there's the one or two actual scientists on the Unicode consortium? Or even the one odd soul still sporting a notion of consistency who finds it only logical to provide a "subscript b" if there's a "subscript a"?
How am I wrong?
The author states, as regards the interpretation of the Dunning-Kruger diagrams, that
[i]n two of the four cases, there’s an obvious positive correlation between
perceived skill and actual skill, which is the opposite of the pop-sci
conception of Dunning-Kruger.
So, yes, Dunning-Kruger (as evinced from the diagrams sported here) indeed seems to make a weaker claim: that there's no correlation between “perceived ability” and “actual ability”. As such, this claim is as far from the "pop-sci conception" of Dunning-Kruger as it is from the author's.
The word seems entirely appropriate.
As a European, I have not been able to convince family members or friends that aren't intimately acquainted with the US-American situation that there is no universal, legislative framework for paid or unpaid maternity leave.
They usually respond with a variation of "this can't be right; you must be misinformed; it would be horrible if that were the case."
And you (as a populace) aren't even fighting for it! Not visibly, at least. So, honestly, you seem to be the one hurting all sorts of causes with this misdirected attitude of apologism.
It is astonishing to me, how widespread fisher-wife's-tale-level conceptions about fundamental aspects of our existence are.
I devoutly hope that you are not, upon contemplation, equate a well-versedness in general knowledge with mindless memorization. Is emergent behaviour of neural networks really that alien a concept? Is it possible to believe, in all earnestness, that factoids such as these remain isolated and inactive in your memory until recalled?
These questions aren't there to test your ability to learn atomic facts without rhyme or reason. These questions, pitiful as they may seem, try to probe the breadth of your mental landscape.
The author tells me to 'Please enable Javascript!'
I counter: 'Please enable HTML!'
In all seriousness, it's text, images, links. There are no user accounts, no dynamically updated database of 'favourited' sections, no per-paragraph instant chat, the page is remarkably atrocity-free!
Hence, this page seems very much un-Unix-y: Solve problems at the lowest level of complexity, what?
The counter on the kindly linked donation page went from EUR 49.470 to EUR 65.126 in the last 60 minutes (precisely).
The point isn't easily settled, it seems:
I am having a hard time to find financial statements from Debian.
Ubuntu, or rather Canonical, being a private company, doesn't seem to release financial information. The Ubuntu main page doesn't even provide a 'donate' link anymore.
Which leaves RedHat, at last. A public company, of course[0]:
Operating profit 2014: $ 1.3e9
Net total income 2014: $ 178.3e6
Those are some rather interesting documents, thanks!
In 2013 FSF paid $ 689,239 in salaries and, astoundingly!, $ 48,995 in credit card fees.
I freely confess to being flabbergasted by these displays of less-than-rigorous thought processes.
How would a free software project 'pay it forward'?
They are in a very similar position, aren't they?
Edit: For some reason, I can't reply to child comments (probably a cool-off time-out at work?).
Just a short note here, then: $1.25e6 for the FSF translates to 10 developers like Koch being paid (the donation page quotes "120000 EUR").
That's ten. For the whole FSF. As an example of a well-funded project. I'm not going to comment on that. HN would rightly give me months of cool-off time.
You are using Ubuntu, I see from your profile. How much have you paid them?
This is how the stories goes: we haven't figured out how to make good work worthwhile.
Perhaps we can learn something from our vast experience in profitably peddling shit?
Ah, but what is discipline? Shifting the vocabulary burden around doesn't accomplish much. Discipline easily translates to will power (to do even in the face of adverse circumstances).
But haven't we learned recently to consider will power a finite resource? Something that cannot be switched on at will arbitrarily[0]?
The author himself escapes this accusation only by the skin of his teeth in the next-to-last paragraph:
How do you cultivate discipline?
By building habits – [...]
Whenever my thoughts stray to punishing myself for lack of discipline, I try to remember to leave that martial outlook towards life to the Spartans[2] and reflect peacefully on my habits instead.
[0] Except, tongue-in-cheek, if you add sugar.
[1] Lest I leave an opening: It already is in Covey's seminal 1989 'Seven Habits', https://en.wikipedia.org/wiki/The_Seven_Habits_of_Highly_Eff...
[2] In this way, trying to force discipline may easily lead to results that are as devastating as those that the author foresees for motivational strategies.
A monitor like this would be the end-all-be-all for my scientific workflow woes. The paper du jour on the e-ink and the journal and ipython on what I call "the lightbulb" (read: TFT).
I have already been fantasising about and doing a spot of research into building one on my own by using an Arduino (I wouldn't need as high a refresh rate as this little marvel) and one of PervasiveDisplays'[0].
I gave up convinced there was no sane way to actually connect this contraption to my laptop, and the USB solutions mentioned below do not instill hope.
[0] http://www.pervasivedisplays.com/
They seem to be doing a bit of open-source advocacy, too: http://repaper.org
The Gimp has certain, err, noteworthy notions about user interface design.
Nevertheless, single-window mode has been around for years (I think): Select 'Windows'->'Single-Window Mode'. The distinction between Save and Export is one of those measures to gently remove the user's feet from below the barrel, I imagine (only the native xcf-format stores certain information, like layers).
s/odd/sane/: This oddity you've identified is precisely the reason people like me are interested or even invested in the project. Must everyone worship at the altar of smudgy screens and ineffective text input? The N900 is the last phone that was actually usable. And by usable I'm not only referring to the stylus/keyboard input duality, but also to the the fact that it's as trivial extendable as any reasonably open Linux system.
In fact, I'd wager that the two are very closely correlated: the need to tinker and the desire to do so with sane input devices.
As the article referenced here is rather light, here is the actual paper of the mentioned study (open access): http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna..., and a slightly more informative report by the University of Colorado Boulder, http://www.colorado.edu/news/releases/2014/11/20/running-rea....
Conclusion from the paper:
Running mitigates the age-related deterioration of walking
economy whereas walking for exercise appears to have
minimal effect on the age-related deterioration in walking
economy.On Debian (and, I'm sure other distributions of GNU/Linux) the 'bsdgames' package contains a simple program called 'arithmetic' which poses similar challenges, albeit reduced to the most elementary operations: addition and substraction. Call as
arithmetic -o '+-x/'
I find it a handy supplement to 'gtypist' in order to train touch-typing of numbers.
On a side-note: I'm surprised at how scarce such software is - pitiful as it may be. But then, the advancement of the human intellect isn't at the forefront of our cultural conscious, is it?
As with many of Vim's questionable but ultimately effective interface decisions, I have found 'chronological undo' to alleviate all my undo-tree-related pains: Step through the undo tree sequentially with 'g+' and 'g-' until you've found what you're looking for.
Mosh is a truly impressive feat of thought and, perhaps more importantly, engineering. The thinking behind Mosh is substantial, the paradigms are fresh. Reading about mosh on its excellent website, I always leave with a profound feeling of enthusiasm. Mosh belongs a school of software development ethics that I'm sorely missing in the world.
However, I do concur that, perhaps, Mosh solves a deep problem on the wrong level or, even, in the wrong domain. The feeling, already expressed here, that "tmux oughta do it" never leaves me. Why is that?
Because I know that ssh, by itsself, can handle connection loss quite well[0]. Rather, I suspect, ssh can't deal with IP changes or the destruction of the underlying interface.
So, here's the rub: Why is a stable, somehow-abstract, network interface with a local IP, sitting on top of the actual network interfaces, be they wired or wireless, not the answer? Over the years, on and off, I tried to get the Linux ethernet bonding stack (ifenslave) to provide me with just that solution, but was never able to.
Hence, I keep revisiting mosh, then revisiting ifenslave...
[0] On a machine that doesn't dynamically switch network interfaces on demand, just unplug an ethernet cable, wait a while and plug it back in: your ssh session will resume.
I value the Unicode effort so much, I consider its inconsistencies a major pain point in my life.
Why, for the love of Zeus, is there no codepoint for
GREEK SUBSCRIPT SMALL LETTER ALPHA
It doesn't end there, see the article https://en.wikipedia.org/wiki/Unicode_subscripts_and_supersc... which sports a consolidated overview.
Tell me I'm overlooking something very obvious.
Excellent! I was just investigating btrfs[0] and realized that it doesn't offer anything like ZFS's "2nd level storage" (L2ARC) which is doing precisely this: keep what is nowadays referred to as hot data on dedicated (read: solid state) storage; as much as possible.
In the course of this little recherché I hit upon bcache and dm-cache but found (Debian) user-land to be entirely lacking (`modprobe dm-cache` doesn't raise an eyebrow, though).
Having dm-cache support in LVM -- one of those projects that figure centrally in my personal sysadmin lore -- would be just heavenly.
[0] Balanced Tree FS. Similar in outlook and approach to SUN-now-Oracle's ZFS and -- oh, irony of ironies -- also under the Oracle umbrela.
The answer seems to me quite simple: because they have a different coding style. Just as no one is bound to K&R or the GNU style, nothing suggests that crypto code needs to follow Linux kernel conventions.
Value consistency above everything.
Honestly, I am not convinced that the peculiar if-style isn't actually helping readability and refactoring. Note, that a Apple-style "goto break" bug might be harder to construct, when your one-line if's look like this:
some_code;
if (something) die(message);
other_code;
some_code;
if (something)
die(message);
other_code;
You (presumably) and I have beaten ourselves into submission to the Linux style; the authors' haven't.
On a side note: your second example even seems to suggest that the authors made some effort at additional readability by refraining from using the ternary operator construct.
Outstanding! Not only are the slightly mysterious authors of this project not inventing their own crypto, they rely on djb's[0] much acclaimed NaCL/TweetNaCl. The codebase is accordingly small:
$ wc -l source/*/*c | tail -n1
11308 total
$ wc -l source/crypto/*c | tail -n1
1293 total
Incidentally, I am impressed by the spirit of organisation that the source tree permeates. Both crypto/ and tinyssh/ source trees sport corresponding -test directories and a debian/ tree has already been added.
Initially, I felt irritation by the consistent lack of documentation (no README, no AUTHORS, almost no comments, it seems). Browsing the source, however, I grow convinced that this from a conviction that out-dated or redundant documentation is the greater evil.
[0] Daniel J Bernstein - author of qmail, daemontools and long-time promoter of full disclosure. https://en.wikipedia.org/wiki/Daniel_J._Bernstein