Personal Blog

I'm currently running a program – a.out – that simply prints a string to standard out every second. It's been running for approximately 13 hours.

I want to be able to get the process ID (or PID) of the process. For that I am using ps(1).

              daniel@ubuntu:~$ ps -e | grep a.out
                5306 pts/0    00:00:03 a.out
              daniel@ubuntu:~$
              

The default behavior for ps -e is a bit confusing. If we follow the man page, we come to a snippet that says:

              For example, the normal default output can be produced with this: ps -eo "%p %y %x %c".
              

              daniel@ubuntu:~$ ps -eo "%p %y %x %c" | grep a.out
                5306 pts/0    00:00:03 a.out
              daniel@ubuntu:~$
              

If we look at the table following the man page snippet, we can come up with another way of running the command.

              daniel@ubuntu:~$ ps -eo pid,tty,time,comm | grep a.out
                5306 pts/0    00:00:03 a.out
              daniel@ubuntu:~$
              

(Acknowledgment: http://linuxcommando.blogspot.com/2008/09/how-to-get-process-start-date-and-time.html)

However, it seems that my process has been running for 13 hours, let alone 3 seconds, so I'm experiencing a bit of cognitive dissonance. 'time' does not seem to be the parameter that I want.

If we want the wall clock time for how long the process has been running, we want the 'etime' to be displayed.

              daniel@ubuntu:~$ ps -eo pid,tty,time,etime,comm | grep a.out
                5306 pts/0    00:00:03    13:21:56 a.out
              daniel@ubuntu:~$
              

It appears that 'time' simply counts the time in which the CPU is working on this program. Since my program is sleeping most of the time, it's very likely that it will take another 6 hours for it to get to 4 seconds of CPU time.

Recently, an article came out on Gizmodo about the ethics of self-driving cars. The premise is simple: what should a self-driving car do when a crash is imminent and it can "choose" between running over two sets of people, one of which is greater in number than the other? It is analogous to the problem with the runaway trolley killing one person or five (Wikipedia).

I think that presenting this problem in this way muddies the waters in what should be much more clear and precise understanding of real-life scenarios.

Our brains have a tendency to define self-driving cars as cars that are fully autonomous. I think this is the first key divergence between the thought experiment and reality. As long as the responsibility rests on the vehicle operator, a car cannot be considered fully autonomous. It steers itself, drives itself, etc, but requires a driver at the wheel, and also the responsibility for the rules of the road rests on the driver.

What about when cars become fully autonomous?

The article suggests that people would be apprehensive of purchasing a car like this because the vehicle might "choose" to kill them. On the other hand, a skeptic prospective buyer will probably get over this hurdle with the assurance that there is still a steering wheel, and there is still the option to take over and drive the vehicle yourself.

I think the key point is that we don't know in which direction the technology will progress. We don't know if there will always be a human operator. We don't know if there will always be a steering wheel allowing a human to take over control of the vehicle, or if there will have to be compromises, where, for example, the driver controls the accelerator and brake pedals while the car does the steering.

And if we do end up getting into the point where cars really do become completely autonomous, with responsibility or liability resting on the car manufacturer, do we assume that this ethical problem is particular only to self-driving technology?

I could argue that the same problem exists when a person controls the vehicle, and what most likely will happen when a self-driving car is faced with the trolley problem is the same exact thing that happens when a human being is faced with the same situation. They will put on the brakes as hard as they can.

June 16, 2016 by Daniel

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipisicing Hippokampoer [1] elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur printf adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

If I could go back in the past 10 years and send myself a message on how to start my career in programming, here's what it would be:

Dear young Daniel,

Today, I am writing to you from 10 years into the future. Over the next 10 years, you will always love computers. But in this world, you will find that there is a barrier-to-entry to start a career based on this thing that you love; specifically, there will always seem to be a confounding oversupply of information combined with an utter lack of direction. Hopefully, I can give you a few pointers that I had to find out the hard way. If you’re lucky and work smart, you can make it to a top software development program; but if you don’t (and the simple math is that not everyone can get in), here are some tips that, in my opinion, will help you the most in overcoming this barrier:

1. Low-level programming exercises are your bread and butter.
2. Soft-skills are your greatest learning tool, provided you practice every day doing your low-level programming exercises
3. Use your own customizable IDE
4. Take your time; but the longer you take, the more hours you need to dedicate to programming

Expand.

If you understand low-level programming, you are 25% done. One big fat (with lots of exercises) C programming book is enough. In fact, since you are actually – well – me, I know for sure that you already have that book; but since that book is hard to find online and you may have left it at your mother’s house, here is another book that you can read because your English at this time is good enough: The C Programming Language 2nd Edition ISBN-13: 978–0131103627. Don’t worry, it was released in 1988 (I wouldn’t link you to a book from the future… duh). Make sure you do the exercises.

My next piece of professional advice: soft skills are just as important as low-level programming, if not more; the fastest way to learn is to learn from other people. At the time you receive this message, Twitter will only be 2 weeks old (I checked). Tweeting every day is the best way to start working on your soft-skills and your personal brand. As to the next best thing to practice your soft skills, dedicate your time to polish your front-end as well. Learning HTML and CSS will allow you to make your own website, which you can customize to your liking.

Which brings me to your Integrated Development Environment (or “IDE” for short.) The best way for you to program is to use the Emacs text editor. If you were in the future with me, you’d know that GNU has released a new Emacs website with cool videos explaining its features. But since you don’t have access to it, you can use the hotkey combination Control-h + ‘t’ from an emacs window to bring up the tutorial. The learning curve of Emacs is much easier than the Vim text editor, which I don’t yet use. And the best way for you to use Emacs is to use a Linux terminal. You may not know this, but Linux is not as scary as you think it is. It is actually free and accessible, provided you use a CLI. The best thing is to run a terminal emulator for the exercises; if you want to run performance tests, you can install an LTS linux distribution and dual-boot your PC. I know it will come as a shock to you, you Windows user, but I am using a MacBook these days. The reason is that it is the only OS that will allow me to emulate all the other OSes; and also because it has a native terminal application that supports the Linux commands.

My message would not be complete without some advice on time-management. Here is a good exercise: Leave things alone when time is up and you have to go. And I... have to go.