Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keeping a debugging journal

steverydz.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Keeping a debugging journal

#21

Post by taspeotis »

a_bonobo wrote: post #20
taspeotis wrote: post #18

Earlier quoted context omitted.

This one stuck out for me: * Time sharing is very slow today, so I'm mostly reading technical reports while waiting three hours for compiler, editor, and loading routine. * I'm not counting this as debugging time! * (Came back in the evening.) For reference, you can compile the Linux kernel in as few as eight minutes [1]. [1] http://askubuntu.com/a/244148

By time-sharing, does he mean sharing computing time on a cluster? I work on my university's cluster and on bad days, my jobs are queued for 4 hours and then run for 20 minutes...

I didn't know time sharing was still a thing.

Re: Keeping a debugging journal

#22

Post by mattstreet »

taspeotis wrote: post #21
a_bonobo wrote: post #20

Earlier quoted context omitted.

By time-sharing, does he mean sharing computing time on a cluster? I work on my university's cluster and on bad days, my jobs are queued for 4 hours and then run for 20 minutes...

I didn't know time sharing was still a thing.

Yeah for clusters/super computers...I mean you'd think more than one person wants to use them right?

Re: Keeping a debugging journal

#23

Post by pseut »

a_bonobo wrote: post #20
taspeotis wrote: post #18

Earlier quoted context omitted.

This one stuck out for me: * Time sharing is very slow today, so I'm mostly reading technical reports while waiting three hours for compiler, editor, and loading routine. * I'm not counting this as debugging time! * (Came back in the evening.) For reference, you can compile the Linux kernel in as few as eight minutes [1]. [1] http://askubuntu.com/a/244148

By time-sharing, does he mean sharing computing time on a cluster? I work on my university's cluster and on bad days, my jobs are queued for 4 hours and then run for 20 minutes...

Dude, you didn't even look at the pdf did you. That was the entry for 13 Mar 1978

Re: Keeping a debugging journal

#24

Post by a_bonobo »

pseut wrote: post #23
a_bonobo wrote: post #20

Earlier quoted context omitted.

By time-sharing, does he mean sharing computing time on a cluster? I work on my university's cluster and on bad days, my jobs are queued for 4 hours and then run for 20 minutes...

Dude, you didn't even look at the pdf did you. That was the entry for 13 Mar 1978

I'm pretty sure clusters changed in their architecture and their processing power, but you still have to stand in line

Re: Keeping a debugging journal

#25

Post by timtadh »

a_bonobo wrote: post #24
pseut wrote: post #23

Earlier quoted context omitted.

Dude, you didn't even look at the pdf did you. That was the entry for 13 Mar 1978

I'm pretty sure clusters changed in their architecture and their processing power, but you still have to stand in line

In 1978 Time Sharing Machines refers to single machines with multi-tasking. ex. the terminal you are using right now. So you don't have to "wait in line" you have to share resources. Just like your web-browser shares resources with your editor.

https://en.wikipedia.org/wiki/Time-sharing

esr also has a good article: http://catb.org/jargon/html/T/timesharing.html

Re: Keeping a debugging journal

#26

Post by thejosh »

Yep, and if you post it to say tumblr, or your blog then people searching for the same problem you have will also run across it.

Great way to help others, and keep the "Just Google It!" mantra alive.

Re: Keeping a debugging journal

#27

Post by rohamg »

Why not use GitHub? You can file and look up commit histories, write comments, track Issues/bug reports, collaborate with others.. all in one place.

If you want a public debugging journal for a private or self-hosted project, I think Evernote combined with http://postach.io would work beautifully.

Re: Keeping a debugging journal

#28

Post by leerodgers »

I think this is a helpful action in some cases as well. Especially on teams where its less of a bug and more of a FAQ. Various questions about an application that are common and where to look for the answers. Saves everyone time.

For actual bugs. A lot of times they are one off, but if it is say an issue with a configuration or deployment that could come up again I definetly see the value there.

Post reply on HN