#emc-devel | Logs for 2009-12-31

[00:39:06] <cradek> ... by rewriting task from scratch
[00:39:14] <SWPadnos> heh
[00:39:28] <SWPadnos> that would fix the "I can't jog while a program is paused" problem as well
[00:39:34] <SWPadnos> in theory at least
[00:39:55] <cradek> yeah it fixes an infinite number of problems right up until the implementation is done
[00:40:17] <SWPadnos> wow. there are 640GB laptop hard drives now
[00:40:28] <cradek> that's alotta porn
[00:40:36] <SWPadnos> portable porn even
[00:41:00] <cradek> I finally think 4G disks are a bit too small, and I've settled on 9 gigs as the "plenty" size for now
[00:41:16] <SWPadnos> for general purpose computing, or specific-use installs?
[00:41:31] <cradek> both
[00:41:44] <SWPadnos> do you have a server with a larger disk?
[00:41:49] <SWPadnos> (and use it from more or less wherever)
[00:42:00] <cradek> oh some of my machines have slightly bigger disks than that
[00:42:11] <cradek> I don't really have a "server" except for timeguy.com
[00:42:31] <SWPadnos> I ask because I couldn't even install half the software I use on a relatively frequent basis in that much space
[00:42:47] <SWPadnos> well, maybe half by count, but not by install size
[00:43:17] <cradek> timeguy.com including all of emc's git and all my email for 15? years is about 6G
[00:43:47] <micges> cradek: I have partially done plan for rewriting task, now I'm working on joints_axes3 required features to see if they fit new design
[00:44:05] <cradek> I back up all my important machines including linuxcnc.org on a 35G tape
[00:44:42] <cradek> micges: I've started too - only 20% done though I bet
[00:45:46] <cradek> SWPadnos: if I took up photography in a big way I can see needing lots more space
[00:45:46] <micges> cool, so we have 50% + 20% = 70% ;)
[00:45:53] <cradek> micges: haha exactly!
[00:45:55] <SWPadnos> oh sure, or video
[00:46:43] <SWPadnos> I've got Altium Designer and FPGA tools, which would mroe or less take up an entire 9G disk
[00:46:47] <cradek> micges: more like 1/(1/50 + 1/20) = 14%
[00:46:59] <SWPadnos> not to mention the dev tools for several DSPs and microcontrollers
[00:47:20] <cradek> SWPadnos: yeah, I only do avrs, plain old gcc cross compiler is tiny
[00:47:32] <SWPadnos> and I keep a local copy of datasheets for components I use, and those are close to 1GB
[00:47:35] <cradek> I'm not saying nobody needs more :-)
[00:47:51] <SWPadnos> I think I finally nuked all the versions of LabView, which I'm sure totaled another 9G :)
[00:47:55] <SWPadnos> yeah - I was just curious
[00:48:07] <cradek> I just can't see how anyone needs terabytes unless the situation is very special
[00:48:21] <SWPadnos> a terabyte would last quite a while
[00:48:27] <SWPadnos> even with photos
[00:48:43] <SWPadnos> I think we've only used up 300GB on the camera array server
[00:49:07] <SWPadnos> in all testing, and 5 jobs with up to 48 cameras on each job
[00:49:16] <cradek> I think on some level I refuse to collect/keep more data than I can back up because if it's not on tape it's transient
[00:49:25] <SWPadnos> yeah, don't remind me
[00:49:45] <SWPadnos> oh. Altium is ~14GB on its own
[00:49:52] <SWPadnos> that's big
[00:49:58] <cradek> yeah but you don't need to back that up - just download it again
[00:50:04] <cradek> your programs/projects, yes
[00:50:15] <cradek> but yeah, that's crazy big
[00:50:41] <SWPadnos> backups serve multiple purposes. one is data protection, which backing up only data accomplishes
[00:50:58] <micges> good night all
[00:51:22] <SWPadnos> the other is minimizing service interruptions in the event of a problem - not backing up programs and system settings (personal preferences, etc.) doesn't accomplish that
[00:52:31] <cradek> raid is somewhat useful for that part (useless for the first)
[00:52:44] <SWPadnos> well, not in the event of a data loss
[00:52:50] <SWPadnos> which implies that the RAID failed
[00:52:56] <cradek> yeah I see what you mean
[00:53:02] <cradek> I was thinking 'hard disk failure'
[00:53:05] <SWPadnos> yep
[00:53:17] <cradek> but yeah, raid is useless as data loss prevention
[00:53:43] <SWPadnos> that's something I was recently thinking about - how to relatively easily record and migrate system settings
[00:54:20] <cradek> back up the dot files in your home directory [in my happy unix place]
[00:55:02] <SWPadnos> on that note, do you know offhand if there are "macros" in .deb packages that expand to the binary directory, examples directory, templates directory, etc. ?
[00:55:18] <SWPadnos> yeah, though that doesn't help for apache or X ... :)
[00:55:36] <SWPadnos> err - s/in/available to/
[00:56:24] <cradek> well the files in a deb are in a tree that's already (or should be) those special directories
[00:56:58] <cradek> usually "make install" with a TARGET arranges them that way, and then they're packaged up
[00:57:10] <cradek> so, I think the answer is no
[00:57:14] <SWPadnos> ok
[00:57:28] <cradek> (I think rpm had that)
[00:58:03] <SWPadnos> I was thinking about how to upgrade a machine from Ubuntu x to Ubuntu Y, and semi-automagically handle changes to where those typed of files should go
[00:58:08] <SWPadnos> types
[00:58:19] <SWPadnos> it's not an easy problem
[00:58:58] <SWPadnos> actually, the idea was to do a fresh install of the new OS on a new HD, and more easily migrate settings from the old one
[00:59:12] <SWPadnos> more easily than trying to figure it all out by hand anyway :)
[01:03:28] <cradek> the solution is the package maintainer for each package makes a new version that honors the new file arrangement rules
[01:04:20] <cradek> you're not going to automatically get inetd to look at /etc/sysconfig/inetd.conf instead of /etc/inetd.conf by any packaging magic
[01:08:15] <SWPadnos> no, certainly not
[01:08:42] <SWPadnos> I was thinking of how to move files, and also how to check for differences between the configs (easier when the diff knows where to look for both files)
[01:20:12] <alex_jon1> you can use preinst/postinst for that
[01:20:16] <alex_jon1> but it's a pita
[01:20:52] <alex_jon1> when you figure out what you want to move from where to where, you can make a small deb which contains the moves in a preinst
[06:24:25] <CIA-62> EMC: 03cmorley 07master * rdf60b2244849 10/src/emc/usr_intf/pncconf/pncconf.py: complete addition of second mesa page
[06:24:27] <CIA-62> EMC: 03cmorley 07master * r662b3dfc920c 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): add Ability to initalise and change second mesa page
[06:24:27] <CIA-62> EMC: 03cmorley 07master * r8b2ac13798fd 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): Add second mesa page -not functional yet
[09:59:07] <kloeri> [Global Notice] Hi everybody. #freenode-newyears is now open for all your new years celebrations. Happy new years from PDPC and the freenode volunteers and thank you for another great year.
[11:39:07] <micges> alex_jon1: yay!! ja3 teleop jogging is working :)
[12:13:06] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[13:33:10] <jepler> micges: congrats
[13:33:46] <micges> thx
[17:48:43] <alex_jon1> micges: cool stuff, too bad I missed you
[17:51:22] <alex_jon1> alex_jon1 is now known as alex_joni
[17:52:08] <skunkworks> it looks like the latest release of the hm2-servo release had the encoder scales hard set in the hal file. Looks to be fixed in trunk though.
[17:52:20] <skunkworks> (2.3.4)
[17:52:48] <skunkworks> through me for a loop wondering why the servo kept running away no mater what sign I make the input scale. ;)
[17:53:35] <alex_joni> heh
[17:53:41] <skunkworks> and also why the encoder scale seemed to stay at 2000 no mater what I did ;)
[17:53:47] <skunkworks> matter
[17:53:50] <alex_joni> is it fixed in v2_3_branch ?
[17:54:00] <skunkworks> I just check git - looks like it
[17:54:14] <skunkworks> setp hm2_[HOSTMOT2](BOARD).0.encoder.00.scale [AXIS_0]INPUT_SCALE
[17:56:09] <alex_joni> http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=0c034355df30cf3c2d0d332bc8d6fe87864d3645
[17:56:13] <alex_joni> that's from may 2009
[17:59:13] <alex_joni> should have been in 2.3.2+
[18:00:48] <skunkworks> hmm - that is odd.. I did a fresh install with the latest livecd - I think
[18:01:04] <jepler> latest live cd is not a very new emc
[18:08:57] <skunkworks> mesa hardware is cool :)
[18:10:32] <alex_joni> but I think it's 2.3.2 at least
[18:10:37] <alex_joni> maybe I'm mistaken though
[18:11:15] <alex_joni> it's from < 29. april, so it certainly doesn't have this fix
[23:12:46] <alex_joni> now those are odd numbers
[23:12:56] <alex_joni> 381MHz and 252MB ram
[23:13:26] <cradek> no kidding
[23:17:09] <alex_joni> wonder how he came up with them
[23:17:23] <alex_joni> 252 could be a 256 with 4MB onboard video
[23:19:03] <alex_joni> found an ARM (Cortex-A8) running at 381