meta user
network profile
| bio | website | bit.ly/GFscreener11 |
|---|---|---|
| location | stackoverflow.com@askmarcos.com | |
| age | ||
| visits | member for | 1 year, 5 months |
| seen | May 4 at 12:06 | |
| stats | profile views | 23 |
Pioneers are the ones with arrows in their backs.
Investment Portfolio Software, Trade Automation
Designer of infinite compression algorithms, and other research projects
|
May 3 |
awarded | Famous Question |
|
Apr 4 |
comment |
Linux tool to track directory space over time It's within my reach to hack together user-space scripts to eg. record periodic du snapshots from cron of all/some directories, store them in SQL/CSV for later analysis to narrow down where storage is being consumed when, and make friendly reports to pinpoint this. With ability to zoom into the dir hierarchy, one hopes. But that's time-consuming and I'm hoping something similar exists, even if imperfect (hardlinks etc.). |
|
Apr 4 |
asked | Linux tool to track directory space over time |
|
Jan 5 |
comment |
run a remote process via autossh in backgroundtmux/screen may indeed be viable; xpra proved too resource intensive on my lean 1-2GB PCs in the past (behind the scenes X server). In reality before having this problem I was trying to avoid using an ssh layer altogether, just sticking to classic xhost + over port 6000 (i.e. DISPLAY=otherDYNDNShost:0 geany &) but could still not figure out how to re-enable that network port in Ubuntu's X server, not even with DisallowTCP=false in /etc/gdm/custom.conf as researched elsewhere. |
|
Jan 5 |
revised |
run a remote process via autossh in background title typo |
|
Jan 5 |
comment |
run a remote process via autossh in background Silly me, I tried -f right after posting and that worked, but felt bad about answering myself so fast. Thanks. However what's really annoying (and probably a different question) are its frequent disconnects & restarts, whilst another interactive ssh session seems way more tolerant of network hiccups and stays connected to one session. |
|
Jan 5 |
accepted | run a remote process via autossh in background |
|
Jan 5 |
asked | run a remote process via autossh in background |
|
Dec 20 |
awarded | Yearling |
|
Dec 12 |
accepted | extract last match from logfile till end |
|
Dec 12 |
comment |
extract last match from logfile till end Prefer a regex-based solution (avoiding double- tac on a large file in a fast loop) |
|
Dec 12 |
comment |
extract last match from logfile till end I was trying to avoid that too since the main logfile grows many MB's huge, and the iterations fast (don't want to slow them down by a large fraction), so was looking for a regex-only solution. |
|
Dec 12 |
revised |
extract last match from logfile till end added 106 characters in body |
|
Dec 12 |
asked | extract last match from logfile till end |
|
Nov 8 |
comment |
Tell fs to free space from deleted files NOW Marking as closest answer, although never really "gave back" the space immediately after closing file handles/processes using them. Looking for other kernel/proc/fs-based approaches. |
|
Nov 8 |
accepted | Tell fs to free space from deleted files NOW |
|
Nov 8 |
awarded | Notable Question |
|
Nov 5 |
revised |
crontab and DST disagreement with different timezone Fixed nasty bash error "15 - 09: value too great for base" when 0* numbers treated as octal |
|
Nov 5 |
comment |
crontab and DST disagreement with different timezone In some cases got /bin/bash: 15 - 09: value too great for base (error token is "09")
due to subtle problem of bash treatment of numbers beginning with 0 as octal. Fixed by preceding 10# to numbers. |
|
Nov 4 |
accepted | crontab and DST disagreement with different timezone |
