Hacker Newsnew | past | comments | ask | show | jobs | submit | ababab's commentslogin

>Also, could we stop using the term 'slave' to refer to distributed compute or storage nodes?

Agreed, I still stick with the old Loadrunner nomenclature "loadgen"


I'd use this if they ever add testing-related docs like JMeter, gatling, taurus, cucumber, selenium, etc.


I'm not a Finder power user, but when I use it I always run into the same problem: I can't ever open Finder and make my way to a specific directory (e.g. ~). I work around it by opening a terminal and navigating there and doing `open .`. Is there something I'm missing? TL;DR: How can I open Finder and go to any specific directory I want?


Type ⌘⇧G or select Go -> Go to Folder... for a field into which to enter a path.


Also supports tab completion!


Try Alfred? https://www.alfredapp.com/

I just open it up, type whatever folder name I need, hit enter and I'm where I'm at.


Taurus sort of does this. http://gettaurus.org/


I'll put it on my list to investigate.


Testing/Quality should be an option.


Shouldn't that explanation be by followed by 'in order to request the termination of the process'?


Not always. The kill system call can be used to send any signal, it's just got a name that implies you're sending something like SIGKILL or SIGTERM. I have written C programs that use kill for harmless inter-process communication.


SIGUSER is quite common for that. Or SIGHUP.


By convention, SIGHUP is used by daemons to signal a change of configuration.


Not necessarily. You can send the CONTinue signal to a process using the kill command. This will not cause the process to terminate.


Or use "kill -0 <pid>" to check if a signal can be sent/the pid exists.


Or use kill -USR1 <pid> to check the progress of dd


Only if you've enabled it. If you've not, the process will terminate unceremoniously (in a mechanism borne entirely out of hatred for users.)

This is my favourite part of dd: The "will I receive a status report or will I terminate my long-running copy?" gamble.


Is that a BSD thing? I've never had to enable it on Linux to avoid killing the process.


Me neither, on debian.


It's SIGINFO on the BSD's, and works with just about any process (though obviously not everything has a customized handler). Also handily mapped to Ctrl-T.


No because only SIGQUIT, SIGABRT, SIGKILL, SIGTERM and often SIGHUP are supposed to do that. All of the other signals have wildly varying meanings. See man 7 signal: http://unixhelp.ed.ac.uk/CGI/man-cgi?signal+7


SIGHUP is also used to tell some certain daemons to re-read their configuration files without quitting.


You can also cancel (sigint, eg ctrl c) processes via kill.

Or use sigchld to a parent to get rid of zombie children.


Could you add installation/setup instructions?


There's no installation, just git clone and move to your www directory.

$ git clone https://github.com/afaqurk/linux-dash.git

$ mv linux-dash/ /var/www/


That assumes you have a web server configured to serve PHP out of /var/www.

At the very least you would want to put some access control in front of this.


> That assumes you have a web server configured to serve PHP out of /var/www.

The example was for Apache webserver.

> At the very least you would want to put some access control in front of this.

You're right, access control would be in order. Though I was merely suggesting the fastest way to try it out.


Here's a big list of readers to try out:

https://github.com/smithbr/rss-readers-list


Could you expand on what you mean by assert-driven testing? I'm not finding any good explanations from a Google search. Sounds interesting.


My GUESS was that he/she means that the code has asserts in it that check if something is not right at runtime. I personally would not call that a replacement/alternative for unit tests. In fact, it may be counterproductive ... a small error in the code would bring down and entire application.


i would counter this by saying that a small error in code SHOULD bring down the entire application.... during development. otherwise the error is not visible to developers when they can best/easiest fix it.

of course, asserts should not crash the app once it's in production. instead they should be channeled to a log that gets sent back to the production support team for analysis.

but during development, I'd say crashing during small errors is a great thing.


Assert driven testing means that the tests are part of the actual code that is running. It's helpful because when an assert fails, the stack trace is right at the position where it failed. In many ways it's an easy way to incorporate testing into your application without the need for an additional framework.

A simple example can be done by writing a single function in the root scope or some global function (javascript)

function assert(assertion, description) { if(!assertion) { console.log(description); //could also have other application error handling code } }

Then in a function in your application:

function myFunc() { var x = 1; assert(x == 1, "x does not equal 1 in myFunc()“);

\\Continue code... }

This is obviously a very simple example and can definitely be iterated upon, but it gets the basic point across and I'm on my phone so writing code isn't the easiest :-P

Some systems have something like this built in, such as node which has more features.

http://nodejs.org/api/assert.html


Sounds like Design by Contract.


i think that's right, but maybe more "agile" in that there is no explicit contract being fulfilled, just what the developer ensuring valid input and output to the functions they implement.


Years ago, Delicious used to have the killer feature. Nowadays, Google's Chrome Sync and Pocket adequately keep my bookmarks alive.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: