hisham hm

🔗 Mounting the SD card from your Android device on Linux over WiFi

Quick-and-dirty notes so I remember how to do it later. This is may all be mostly automatic in some distros (Ubuntu?) but here’s how to do it “by hand”. I may streamline the process myself for my machine in the future, but this is a minimal process that works.

My setup:

  • Samsung Galaxy S3 SGH-T999, not rooted
  • my own hacked up version of GoboLinux, so this should work on any distro

The steps:

  1. Install Droid NAS on your phone. Their description say it “most probably […] won’t work” on Linux, but it is based on Bonjour (aka mDNS protocol) and SMB, and there are Linux clients for that.
  2. Create a directory for your local mount point (mine is /Mount/Phone) and then mount it like this:

    mount -t cifs -o port=7777 //192.168.0.106/"SD Card" /Mount/Phone

    (You can find your phone’s IP with avahi-browse -altr, if avahi-daemon is running).

TODO: convince mount.cifs to use a logical name instead of IP there. Might need to use avahi and nss-dns for that; by the way, if you get an error such as “Connection “:1.10” is not allowed to own the service “org.freedesktop.Avahi” due to security policies in the configuration file” when using avahi-daemon, follow the instructions found here).

🔗 Git Cheat Sheet

I have a hard time memorizing certain unfrequent tasks on Git. I’ll write them down here as I learn them so I can look it up later.

Undo a commit

If you just made a commit (perhaps typing git commit -a too eagerly) and realize you made a mistake, use this to uncommit the modified code, so it shows as “modified:” in git status again and appears again in git diff:

git reset HEAD~

I even added an alias git undo-commit, like this:

git config --global alias.undo-commit 'reset HEAD~'

Getting the last commit from another branch

When working in an alternative branch, you can retrieve the latest commit from another branch with this:

git cherry-pick other-branch

Example:

$ git checkout anotherBranch
$ git branch
* anotherBranch
  master
$ edit some files...
$ git commit -a
$ git checkout master
$ git branch
  anotherBranch
* master
$ git cherry-pick anotherBranch

Interactively select which edits should be committed

After making several edits across files, sometimes you want to add them as separate commits. Committing files separately is easy, but sometimes various edits in the same file should be different commits (or some changes to a file are ready to be committed but others are not). To commit part of the changes to a file, use:

git add -p

From the manual:

“Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index. This effectively runs add –interactive, but bypasses the initial command menu and directly jumps to the patch subcommand.”

🔗 Advice for a beginning Linux programmer

A piece from a private message I posted in a forum, which I thought it could be useful to share.

As advice for somebody just starting out writing system utils, what resources have you found the most useful/valuable over the years? What is worth spending lots of time to understand? Best books? Advice that you wish you knew 8 years ago?

Oh, good questions. I can only think of general pieces of advice; you may already know some, most or all of them, but let’s see:

  • If you want to write system utils, do it in C. Yes, sometimes it’s annoying, pointers, cumbersome string handling, etc. I like other languages better too. But it’s the most portable option and the only thing that’s guaranteed to stay around in Unix in the long run. You’re writing code today but you may end up using it 15 years from now. Today’s Python may be the 90’s Tcl. I do write stuff in other languages (actually, my research work was in the Programming Languages field, so I’m all for language diversity) but if you’re doing system stuff which you want to be as widely available as possible, do it in C.

    • The so-called “pitfalls” of C are more a matter of discipline than anything else. Whenever you allocate a structure to start passing pointers of it around, define which one pointer will be the “owner” of that structure; the one responsible for deleting it. Make sure other pointers don’t outlive the owner and make sure the owner frees the memory. It’s no black magic.

    • One of my motivations for writing htop was actually improving my C skills, which were weak (and some of the early parts of htop still show it, look at the amount of asserts in Vector.c), but nowadays I’m work as a C coder.

    • If you’re writing for Unix only, C99 is fine (and much nicer to write than ANSI C). If you’re planning to support Visual Studio, stick to ANSI C. Depending on what you’re doing you can get away with C99 and using GNU compilers on Windows, too.

  • Learn the GNU Autotools. Same thing: it’s even more annoying than C, but in the end it’s what provides the best experience to end users. You do get a lot of features for free, such as support for cross-compiling, etc. Things you may not need now, but that will pop up as feature requests once you have a user base. And to grow a user base, you want your installation to be just “type in ./configure; make; sudo make install” and not “install this-and-that build tool”. Distro packagers will thank you, and cooperation with them is fundamental to get your app out there.

    • A neat side effect of learning Autotools as a developer is that you develop skills in troubleshooting problems when installing other packages. Autotools is ubiquitous, so being proficient at it is another professionally useful skill.

  • Similarly, if you’re writing libraries, learn Pkgconfig. If you’re using libraries, learn how to use Pkgconfig from within Autotools. Pkgconfig is nice and will make your life much simpler, the more you use it.

  • I haven’t used many physical books, but there are tons of online resources that will help you with the above. The “Autobook” is something you’ll quickly end up in right after your first Google searches for Autotools stuff.

    • man-pages are your friends. You’ll code more efficiently by refering to them (when you need to check the order of the arguments for strncmp for the 1000th time) instead of relying on online search for everything (which is more distracting).

    • I use pinfo as my man reader (with “alias man=pinfo -m” in my shell) because it makes hyperlinks between man-pages. Very efficient.

  • You don’t need to use an IDE, but that doesn’t mean you shouldn’t rely on debugging tools.

    • Valgrind is your best friend. In comparison, C programming was miserable before it.

    • Build with “-g”, run with “ulimit -c unlimited” in your shell at all times. Learn to load core files with gdb and examine backtraces for post-mortem analysis when your program

    • If you decide to open the can of worms of multithreading, you can set custom thread names with the prctl command (and then examine them with nice names in htop)

    • Other tools I use often: strace, lsof.

That’s all I can think of for the moment, I hope that helps!

Happy hacking!

🔗 How to make the Print dialog use PDF by default in Firefox

  1. Go to about:config
  2. Type “print_to_filename” in the search box
  3. For all entries that appear, change their values to .pdf

🔗 Programming language research is a Human Science

Some people often tell me that, due to my various interests, they actually find it weird that I ended up studying Computer Science and not some of the Humanities. I try to explain them that my specific field of interest, programming languages, is actually a Human Science. And that is so for one simple reason: if there was no people, if computing was restricted to computers and there was no human factor, machine language — the binary code that processors actually run — would be enough. Programming languages exist because of people, not because of computers.

This quote puts it rather nicely:

“Programming is a science dressed up as art, because most of us don’t understand the physics of software, and it’s rarely if ever taught. The physics of software is not algorithms, data structures, languages and abstractions. These are just tools we make, use, throw away. The real physics of software is the physics of people.

Specifically, our limitations when it comes to complexity, and our desire to work together to solve large problems in pieces. This is the science of programming: make building blocks that people can understand and use easily, and people will work together to solve the very largest problems.” — Peter Hintjens et al., ØMQ - The Guide

Programming languages are the bridge we use to communicate our ideas to the machine, but also to communicate our ideas among our fellow programmers, and even to ourselves. Like natural languages, programming languages are constantly evolving (at a much faster pace, even!), as we try to balance the tension between being precise and unambiguous and being understandable and eloquent; to be able, in the same piece of prose, to tell a machine what to do and to tell another person what we mean. And this is by no means a matter of numbers.


Follow

🐘 MastodonRSS (English), RSS (português), RSS (todos / all)


Last 10 entries


Search


Admin