Back
[03:41:25] <cradek> yay, frank committed his AXIS fix on trunk
[03:42:01] <jepler> I saw that
[03:42:04] <jepler> I should test it
[03:42:15] <jepler> .. but not tonight
[03:42:20] <cradek> same here
[03:42:27] <cradek> I should sleep a full night for once
[03:42:28] <jepler> gdepth ate my energy
[03:42:33] <jepler> sounds nice, me too
[03:42:34] <cradek> gdepth is cool
[03:42:35] <jepler> thanks
[03:42:54] <cradek> that gdepth6-arcspiral looks JUST like the aluminum one
[03:42:54] <jepler> I was just getting a bit tingly looking at the screenshots on the axis blog
[03:43:03] <cradek> heh
[03:43:13] <cradek> it's even cut off the side on two sides like that
[03:43:17] <jepler> funny
[03:43:18] <cradek> I'll bring it to work
[03:44:26] <cradek> well, all 4 sides
[03:44:42] <jepler> we will have to get a preview "right"
[03:44:57] <cradek> yeah it would be funny to show it that way (with a photo)
[03:47:39] <cradek> hmm, I/we desperately need to get g76 docs in the manual
[03:49:23] <jmkasunich> hi guys
[03:49:34] <cradek> hey
[03:49:40] <jmkasunich> you are in print!
[03:49:48] <cradek> eh?
[03:49:56] <jmkasunich> I just got a copy of "Digital Machinist", a new mag
[03:50:13] <cradek> I've seen #2 I think
[03:50:18] <jmkasunich> Ray had an article in there about tool diameter comp, and used an Axis screenshot
[03:50:24] <jepler> oh cool
[03:50:26] <jepler> is this online?
[03:50:28] <jmkasunich> and SWPadnos had an article too
[03:50:33] <jmkasunich> dunno, doubt it
[03:50:43] <cradek> yeah that's the one I saw
[03:50:48] <cradek> fell out of the sky, wasn't addressed to me
[03:50:51] <jmkasunich> the magazine folks like to sell the deat tree version, so they don't give nuttin away
[03:51:04] <jmkasunich> mine was addressed to me - didn't request it or anything
[03:51:12] <cradek> strange
[03:51:25] <jmkasunich> but at one time I had a home shop machinist subscription, maybe they sent copies to former subscribers
[03:51:30] <cradek> ahhh
[03:51:38] <jmkasunich> either that or Roland shared his list from the workshop
[03:51:39] <cradek> that may/would explain it
[03:51:39] <jmkasunich> (he
[03:51:55] <jmkasunich> (roland is involved in the mag too...)
[03:52:03] <cradek> did you get episode 1?
[03:52:06] <jmkasunich> no
[03:53:53] <jmkasunich> heh, I managed to do something usefull sitting in the airport this evening
[03:53:56] <jmkasunich> (finished the pid manpage)
[03:54:01] <cradek> you home already?
[03:54:19] <jmkasunich> yeah
[03:54:22] <cradek> that was fast
[03:54:22] <jmkasunich> one day trip
[03:54:28] <cradek> sounds tiring
[03:54:33] <jmkasunich> left home at 5:30am, back at 10pm
[03:54:37] <cradek> ugh
[03:54:41] <jmkasunich> three meetings
[03:54:44] <cradek> hope work doesn't start at 8 tomorrow
[03:55:01] <jmkasunich> I usually wander in around 8:30-8:45 (flextime)
[03:55:15] <cradek> I usually wander in around 8:15 (late)
[03:56:03] <cradek> although I don't really recall ever leaving on time either...
[03:57:30] <jmkasunich> strange - I have a file called "e ???q?" in my docs/man directory
[04:07:46] <jmkasunich> well, I'm tired
[04:07:57] <jmkasunich> I think I'll go to bed before midnight just this once
[14:35:11] <jepler> I haven't tested it yet, but the patch from Frank Jungclaus looks plausible except for one accidental change (default DTG to on)
[14:35:42] <cradek> cool
[14:38:49] <jepler> usrmotintf: ERROR: could not open shared memory
[14:38:53] <jepler> hm, my emc2 isn't running
[14:48:01] <awallin> what's the patch about?
[14:48:20] <SWPadnos> jog increments
[14:49:28] <awallin> ok...
[14:49:47] <SWPadnos> ie, setting them from the ini (or so I gathered from the commit message)
[14:49:56] <jepler> right
[14:50:08] <jepler> apparently I got bored implementing it halfway through, pressing "i" to change increments didn't work right anymore
[17:51:08] <alex_joni> question: now that AXIS is part of the emc2 release.. I wonder if we shouldn't have some of the default configs with AXIS as the interface.. or is sim/axis enough to show it off?
[17:54:10] <awallin> if you ask me, AXIS could and should be the default ui for all configs
[17:55:03] <alex_joni> * alex_joni wonders if this was the wrong box to open
[17:57:09] <awallin> you think there are vocal opponents to this idea?
[17:57:26] <SWPLinux> lots of people are used to the other interfaces, specifically tkemc and mini
[17:57:41] <alex_joni> yes, that's my concearn
[17:58:03] <SWPLinux> axis is somewhat more demanding on the CPU and video subsystems as well
[17:58:15] <alex_joni> SWPLinux: so is ubuntu..
[17:58:23] <SWPLinux> (since it basically always does a backplot)
[17:58:26] <SWPLinux> true
[17:58:27] <alex_joni> we can't expect users running on 100MHz puters anymore
[17:58:49] <alex_joni> or if they do, they know how to fix it :)
[17:58:59] <SWPLinux> it may make sense to have some "minimal" sample configs but switch the others to AXIS
[17:59:19] <alex_joni> * alex_joni sees there can't be a real answer
[17:59:50] <SWPLinux> here's a tricky thought. (unrelated) can configure run the latency tests and choose a lower BASE_PERIOD based on the results?
[18:00:21] <SWPLinux> hmmm - nevermind. that would only help people who compile for themselves
[18:02:16] <alex_joni> yes and no
[18:02:37] <alex_joni> the numbers in BASE_PERIOD and latency test are not really equal
[18:02:47] <alex_joni> I mean I ran with BASE at 6500 and latency at 12000
[18:02:51] <SWPLinux> no, but 2x max_latency should be safe
[18:03:18] <SWPLinux> sure. latency and tmax aren't really related
[18:03:23] <alex_joni> I mean a really well tuned system can be below latency
[18:03:41] <SWPLinux> yes, though the error bar is wider than the execution time
[18:03:42] <alex_joni> but lets leave this to people who need the extra steps/sec
[18:04:01] <SWPLinux> ok. 50000 is very safe but not very fast (and has bad resolution)
[18:04:26] <SWPLinux> 25000 is probably pretty safe, but has better speed and resolution ...
[18:08:14] <rayh> For M2CW we are rapidly approaching a need for a do-it-all config program that saves it's result in XML.
[18:08:28] <alex_joni> M2CW?
[18:08:30] <awallin> has anyone tried how low TRAJ_PERIOD and SERVO_PERIOD can be set?
[18:08:33] <alex_joni> hi ray :)
[18:08:40] <rayh> Then each subsystem has it's own parser to produce a result for that subsystem.
[18:08:51] <rayh> My Two Cents Worth.
[18:08:55] <rayh> Hi guys.
[18:10:04] <alex_joni> that would be nice.. but it's a long way till there I think
[18:10:11] <rayh> The pyvcp already has the XML parser in place and makes a good system.
[18:10:19] <alex_joni> pyvcp might be a small step in that direction :)
[18:10:21] <alex_joni> right
[18:11:04] <rayh> How much work would it be to add a second subsystem, say HAL?
[18:11:07] <awallin> the parser is included as a standard python module, I wrote zero lines of actual parsing code - just learned to use the api
[18:11:20] <SWPLinux> there's going to be at least one issue with that (I agree with the need though)
[18:11:37] <rayh> * rayh is all eyes
[18:11:57] <SWPLinux> jmkasunich wants to keep HAL as generic as possible. that implies that soem things will need to be in two places in the config file
[18:12:12] <SWPLinux> or, EMC will need to read from the HAL data areas
[18:12:20] <SWPLinux> or, EMC will need a fork of HAL
[18:12:32] <SWPLinux> (ie, generic HAL will need to become a separate project)
[18:12:51] <rayh> or two parsers will need to read the same XML data.
[18:13:14] <SWPLinux> it's not the parser that's the problem. consider INPUT_SCALE (which should be OUTPUT_SCALE for stepper systems ...)
[18:13:27] <SWPLinux> EMC needs to know about it, and HAL needs to know about it
[18:14:01] <SWPLinux> so either the number is in two areas, or something has to tell everyone where to get it (which is non-generic in the HAL case, I think)
[18:14:02] <rayh> Sure.
[18:14:05] <awallin> my terminology might be off, but lets try anyway: I think XML is really good at representing directed graphs ("trees"), but might be less good for cyclic graphs ("circuits" "loops")
[18:14:24] <SWPLinux> I think everything we need can be in tree form
[18:14:57] <SWPLinux> a HAL/XML configuration program would probably be about 30 lines of python, like vcpparse
[18:15:10] <rayh> There will certainly need to be some sort of knowledge base.
[18:15:16] <SWPLinux> (not a GUI, just the thing that reads the XML and does HAL configuration)
[18:15:46] <awallin> SWPLinux: yes, it would use the existing linksp, newsig, etc. commands to build the HAL connections/blocks
[18:15:50] <rayh> That XML to HAL would be a great second step.
[18:15:53] <SWPLinux> actually, the ideal is to have the parser need no knowledge
[18:16:01] <SWPLinux> awallin: exactly
[18:16:02] <rayh> Right.
[18:16:17] <SWPLinux> read the HAL subtree (or one specified on the command line)
[18:16:26] <alex_joni> ore one specified on halgui
[18:16:54] <rayh> But some knowledge file will be needed before we finish up a complete configurator...
[18:17:03] <SWPLinux> I hope not :)
[18:17:17] <SWPLinux> just blindly try things, and report errors
[18:17:34] <rayh> xylotex pinout could be considered such a knowledge file
[18:17:38] <alex_joni> that might be a problem with the way emc runs now
[18:17:49] <alex_joni> restarting emc a lot is not nice
[18:18:14] <SWPLinux> ie, <HAL><STEPGEN><TAG>0</TAG><PARAMS><MAXVEL>50</MAXVEL></PARAMS></STEPGEN></HAL>
[18:18:39] <SWPLinux> that's Hal -> stepgen -> 0 -> param -> "maxvel" set to 50
[18:18:59] <SWPLinux> the only thing the parser needs to know is how to put those parts together, and that's pretty generic
[18:19:13] <awallin> SWPLinux: and how is this better than what halcmd save outputs?
[18:19:24] <rayh> I would like to see a sample XML file that built both a pyvcp and a HAL.
[18:19:33] <SWPLinux> it can go in the same file as a pyvcp panel ...
[18:19:43] <alex_joni> I think ray was thinking about the utility to create/adapt the XML config
[18:19:56] <awallin> so we are reducing the number of required 'ini' files
[18:19:59] <rayh> I tried halcmd save outputs with halconf so I've had a bit of experience.
[18:19:59] <SWPLinux> the XML parser should be able to ignore sections of the data that aren't relevant to a particular function
[18:20:07] <SWPLinux> yes - ideallly to one
[18:20:28] <awallin> that is easy, vcpparse now ignores anything not inside <pyvcp>
[18:20:30] <rayh> Once you save a netlist, it no longer looks for variables in the ini file.
[18:21:10] <rayh> awallin: That's the trick, section with pyvcp, hal, ini
[18:21:14] <SWPLinux> awallin: right, and the halxml reader would ignore aything not in <HAL>
[18:21:21] <SWPLinux> then there's <EMC>
[18:21:28] <awallin> still I think defining aribitrary signal topology with a tree-like model is not the easiest thing
[18:21:27] <SWPLinux> <AXIS><TKEMC> ...
[18:21:50] <rayh> Eventually we could get clear up to Interpreter pre and post conditions.
[18:21:57] <SWPLinux> it's all flat connections though
[18:23:21] <SWPLinux> <net><name>flintstones</name><out>fred</out><in>wilma</in><in>barney</in></net>
[18:23:26] <awallin> SWPLinux: but if you want to make the XML a bit 'smart' not just a series of "halcmd xx", it would use the XML tree topology for connections somehow?
[18:23:40] <SWPLinux> hmmm - I don't know about that at first
[18:23:53] <awallin> maybe you are right...
[18:24:15] <SWPLinux> you could have a series of signals, and each pin can have a connection to some signal (and the parser ignores signals that have no pins connected)
[18:24:29] <rayh> The tree typology could be a part of the graphical front end.
[18:24:30] <alex_joni> or the other way around..
[18:24:41] <alex_joni> you have components, pins and connections
[18:24:47] <SWPLinux> alex_joni: no - I think you want to name signals
[18:24:53] <awallin> rayh: but there are no good tree-widgets for tkinter...
[18:24:56] <SWPLinux> that was the problem with linkpp
[18:24:59] <alex_joni> SWPLinux: this doesn't prevent it
[18:25:02] <SWPLinux> then don't use tkinter
[18:25:14] <rayh> * rayh knows nothing of tkinter
[18:25:19] <SWPLinux> you can use kate to edit an XML file
[18:25:23] <awallin> that means one more dependency
[18:25:35] <SWPLinux> rayh: tkinter = python <-> tk interface
[18:25:45] <SWPLinux> gedit may also do it
[18:25:58] <alex_joni> even cat does it
[18:25:59] <rayh> AXIS uses bwidget and there is a tree there.
[18:26:35] <awallin> yes, but it's not easy to use, wxpython is probably the best python ui toolkit
[18:26:49] <rayh> although I'm leaning toward qt4 for a commercial project.
[18:27:38] <SWPLinux> qt is a bit of a dependency for the standard gnome-based Ubuntu
[18:28:03] <rayh> Are we thinking of replacing graphical front ends like axis, tkemc, mini with some sort of py-gui that is XML generated and manipulated.
[18:28:16] <SWPLinux> I don't think so
[18:28:22] <awallin> no
[18:28:34] <SWPLinux> but axis has the ability to load up a pyvcp panel and integrate it onto the main screen
[18:28:50] <SWPLinux> so having all the info in one place would be a good thing
[18:30:18] <awallin> I'm going now, might look into creating HAL stuff with XML during the weekend...
[18:30:29] <SWPLinux> see you ...
[19:38:01] <cradek> rayh: seems like jon E feels that the tkemc work offset solution is still not very good. do you have any thoughts about what we should do?
[19:38:26] <SWPLinux> ask Tom H
[19:38:31] <SWPLinux> * SWPLinux runs for shelter
[19:39:16] <cradek> whozzat?
[19:39:25] <SWPLinux> ask Ray at Fest ;)
[19:39:26] <alex_joni> wish I could say something about that..unfortunately I only used offset once a couple of days ago :D
[19:39:44] <cradek> SWPLinux: I sense I'm missing an inside joke here, but that's ok
[19:40:10] <rayh> Hi guys.
[19:40:16] <SWPLinux> let's just say they have a very heated difference of opinion on how offsets should work and how they should be used
[19:40:29] <rayh> I was really dissatisfied with the tkemc solution as well.
[19:40:30] <cradek> oh, I don't want any heat
[19:40:56] <alex_joni> we need a peltier element
[19:41:02] <rayh> It is not a display specific issue. It is a problem of pre and post abort things.
[19:41:02] <SWPLinux> o
[19:41:10] <alex_joni> get the heat out of here .. put it somehwere else :)
[19:41:11] <cradek> rayh: me too actually. but it is consistent now which is good (I think the offset display is always right)
[19:41:17] <SWPLinux> just bring your coffee cup near, and it'll never get cold :)
[19:41:47] <rayh> IMO we would still have the issue if there were a way to get to g92 in mini.
[19:42:06] <alex_joni> mini uses something else?
[19:42:06] <cradek> if M2 and abort unapply G92, the gui offset jump is disorienting
[19:42:11] <cradek> yes what does mini do?
[19:42:24] <alex_joni> rayh: excuse our ignorance :)
[19:42:30] <cradek> and for that matter how do you teach people to use tkemc? I think I've heard you say jon is using it wrong :-)
[19:42:37] <rayh> excludes the operator from getting to g92 easily.
[19:43:25] <cradek> does that work because mini is often used without home switches (so you can just hit home?)
[19:43:40] <rayh> When Matt and Fred implemented g92 it was late at night and the machine was do to be delivered the next day.
[19:43:55] <cradek> (if you don't need a real home position using home probably works great)
[19:43:56] <rayh> Short answer, g92 was not real well thought out.
[19:44:14] <cradek> I'm afraid I agree
[19:44:17] <rayh> IMO the coordinate systems handle offsets correctly.
[19:44:38] <rayh> set em turn em on or off.
[19:46:36] <rayh> Probably abort ought to preserve the current g92 values so that they can be re-asserted.
[19:47:14] <cradek> part of me thinks M2 (and abort) should not nuke G92
[19:47:33] <cradek> but it bothers me that the spec says so
[19:47:51] <jepler_> cradek: but remember it's not just M2/abort that are the problem
[19:47:55] <cradek> we have departed from the spec in other places where we think it's bogus though.
[19:48:10] <SWPLinux> they should, from the perspective that it's a modal thing that will modify where the machine goes with normal commands (such as G0-G3)
[19:48:18] <cradek> jepler_: the base problem is the offsets are combined so the gui can't tell them apart?
[19:48:18] <jepler_> cradek: the GUIs will be out of synch if a G55 is in the middle of the program and has been parsed but not reached in movement
[19:48:50] <jepler_> cradek: the problem is that time the offset changes in the interpreter differs from the time it changes in the stat buffer
[19:49:04] <jepler_> (the former happens at parse time, the latter happens when that point is reached for motion)
[19:49:06] <rayh> a g92 offset was supposed to be very temporary.
[19:49:59] <rayh> sort of a one-shot that reset whenever the program ended or quit for some reason.
[19:50:49] <cradek> rayh: so using it in the gui for things like touch-off or edgefinder is just a misuse?
[19:51:08] <rayh> I think so.
[19:51:42] <rayh> But for folk that use it, like jon, it would be a lot simpler to make it persist.
[19:51:48] <rayh> and simply change the spec.
[19:52:10] <alex_joni> I think Jon only uses it because tkemc uses it
[19:52:21] <rayh> using a 92 with other offsets is a real problem.
[19:52:31] <rayh> right click is easy.
[19:52:32] <cradek> yes I'm pretty sure he only wants to rightclick and doesn't really care what it does
[19:52:48] <alex_joni> * alex_joni obviously doesn't know squat about offsets.. but I head G54 is somehow better
[19:53:01] <rayh> menu ->scripts->SetCoordiantes is hard.
[19:53:15] <cradek> to be honest I'm not entirely happy with tkemc or AXIS's schemes
[19:53:21] <jepler_> alex_joni: that's probably FUD from the AXIS camp, since they use G54 and not G92
[19:53:36] <rayh> No doubt!
[19:53:50] <alex_joni> * alex_joni goes back to blissfull ignorance
[19:53:54] <cradek> jepler_: the fear/distrust of G92 predates AXIS by many years
[19:53:59] <jepler_> <jepler> whatever we do in AXIS is 100% right
[19:54:03] <jepler_> jepler_ is now known as jepler
[19:54:05] <cradek> haha
[19:54:08] <rayh> There is a slightly larger issue of EMC global var vs var file values.
[19:54:35] <rayh> jeppler is know known as JEPPLER?
[19:54:50] <cradek> I've called him many things, but not that
[19:54:56] <jepler> I've never been known as JEPPLER
[19:55:14] <rayh> The issue of 92 has been around for a long time.
[19:55:44] <rayh> The reason jon falls into it is that he's only used tkemc and used it since it was born.
[19:56:03] <rayh> He doesn't use the coordinate system offsets at all.
[19:56:51] <rayh> jepler: How does axis handle coordinate offsets?
[19:58:15] <cradek> just like the tkemc right click, except it's a button "Touch Off" and it moves G54
[19:58:19] <jepler> rayh: axis uses g54 for everything.
[19:58:32] <jepler> so among other advantages, it's not affected by M2 or abort
[19:58:42] <cradek> it calculates the right number so it works just like G92 (you give the new desired value)
[19:58:49] <rayh> Okay I've got axis 2.0.5 running and see just an offset button.
[19:58:58] <jepler> you'd need to try it in 2.1
[19:59:03] <jepler> "touch off" was later than 2.0.5/axis 1.4alpha
[19:59:10] <cradek> "Offset" sets it to 0 instead of a specified value
[19:59:19] <rayh> That changes the g54 value for the axis that is active?
[19:59:24] <cradek> yes
[19:59:34] <cradek> just jog over a ways and push it
[19:59:52] <cradek> you'll see both origins in the preview (machine origin and G54)
[20:00:14] <cradek> if you have a program loaded, you'll see the whole program move
[20:00:22] <rayh> Got it and starting trunk as well
[20:01:05] <rayh> I see the intermediate popup
[20:01:30] <rayh> the 0.0 in there is relative to the current axis position?
[20:01:42] <cradek> that's what you want the current value to become
[20:02:21] <rayh> okay.
[20:02:56] <cradek> you can put an expression in that popup too. if you have a .1" edgefinder you could put .1/2 (but only if you suck at math)
[20:03:01] <rayh> axis works with g54 only in the interface
[20:03:32] <jepler> right
[20:03:35] <cradek> yes to set the other coord systems you would have to use mdi
[20:03:58] <cradek> like jon E, I never used them, so we didn't write it
[20:04:24] <rayh> And the offsets that you set with the touch off button are only written to the var file when emc shuts down?
[20:04:38] <jepler> I think we use some kind of trick to make them be written out immediately
[20:04:47] <cradek> the var file is written out "often"
[20:06:05] <rayh> Ah good. That matches the way that mini and the set coordinate scripts work in tkemc.
[20:06:28] <cradek> only sort of, AXIS sends mdi to the interp to set the offset, then causes the interp to write the varfile itself
[20:06:44] <rayh> Okay.
[20:07:26] <rayh> I don't think that emcsh offers that option to tcl.
[20:07:41] <rayh> or didn't.
[20:07:55] <cradek> I forget what cuases the write - some kind of interp_synch command
[20:08:19] <cradek> it happens pretty often - when you switch modes for instance (I think)
[20:08:35] <alex_joni> right
[20:09:24] <rayh> I restarted axis and don't see the offset it saved in the var.
[20:09:32] <rayh> Is it still there?
[20:10:26] <rayh> ah sure. I see it with machine position.
[20:11:15] <jepler> sim/axis.ini saves the last machine position and restores it when you restart
[20:11:33] <jepler> this is a new feature available in emc2.1.
[20:12:04] <jepler> maybe that's what you saw that surprised you?
[20:12:45] <rayh> Must be. I'm using today's checkout.
[20:14:40] <alex_joni> rayh: we thought it's nice for machine without home switches to just remember the last position
[20:14:48] <alex_joni> between runs
[20:15:28] <rayh> Sure.
[20:15:46] <rayh> I see that g92 persisted in axis after an abort.
[20:16:07] <jepler> it didn't really
[20:16:09] <cradek> rayh: it's probably tricking you
[20:16:10] <jepler> it just looks like it
[20:16:17] <jepler> issues a g1 command and see if it goes to the right place
[20:16:33] <rayh> It did.
[20:16:41] <rayh> Now I'm really confused.
[20:16:45] <cradek> did you abort a program ending in m2?
[20:17:02] <cradek> I think that's what messes things up in jon's case
[20:17:46] <rayh> Is there an m2 at the end of your splash?
[20:18:11] <rayh> Yep.
[20:21:11] <rayh> That is odd. I saw the 92 offset and was able to reset it with g92.3 after abort but it is gone now that I switched to machine actual position display
[20:23:17] <cradek> rayh: I don't know - all I can say is we recommend you not use G92 with AXIS :-)
[20:26:02] <rayh> I recommend that folk not use g92 at all.
[20:27:41] <rayh> Great job with axis, guys.
[20:27:51] <cradek> thanks
[20:29:27] <alex_joni> * alex_joni agrees
[20:30:00] <jepler> thanks
[21:10:25] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[21:14:44] <rayh> kde had a man page lister/reader. Is such a thing available with ubuntu without the whole kde system.
[21:15:17] <SWPLinux> the system help will do that on gnome
[21:15:46] <SWPLinux> system -> help -> system documentation
[21:16:20] <SWPLinux> click "command line help", then "Manual Pages" (or Info pages ...)
[21:16:44] <rayh> thanks.
[21:16:53] <SWPLinux> sure
[21:39:38] <SWPLinux> out of curiosity, does anyone have an idea of how much more work it would be make an EMC2 live DVD?
[21:40:00] <SWPLinux> specifically, so there would be room for all the compilers and other packages needed for development, plus other conveniences ...
[21:40:02] <cradek> why would we do that if it fits on a CD?
[21:40:06] <cradek> ah
[21:40:22] <alex_joni> SWPLinux: little
[21:40:26] <cradek> probably no harder than the CD, assuming it's not tricky to make them bootable
[21:40:40] <alex_joni> grab the iso, set up the chroot
[21:40:45] <alex_joni> apt-get build-dep
[21:40:48] <alex_joni> rebuild the iso
[21:40:51] <alex_joni> burn on dvd
[21:41:01] <SWPLinux> ok - that should be easy enough
[21:41:09] <cradek> the one I made has nearly 50MB available
[21:41:16] <alex_joni> SWPLinux: I skipped a few steps.. but that's it
[21:41:19] <SWPLinux> ok
[21:41:31] <SWPLinux> the build tools should probably be added then, if they fit
[21:41:42] <cradek> I bet they don't :-/
[21:41:47] <alex_joni> they won't fit in 50MB
[21:42:14] <alex_joni> they can be squeezed in there.. but I wouldn't want to start tweaking the CD
[21:42:20] <alex_joni> as in removing some tools/apps
[21:42:31] <SWPLinux> right
[21:42:37] <SWPLinux> hence the DVD idea :)
[21:42:57] <alex_joni> I saw some ubuntu DVD's distributed with magazines
[21:43:07] <SWPLinux> I noticed that as well
[21:43:12] <cradek> that means even more hosting
[21:43:15] <alex_joni> wonder what's on those (size, packages, etc)
[21:43:23] <SWPLinux> hosting is no big deal
[21:43:27] <alex_joni> there's one reason I'm interested in this..
[21:43:40] <SWPLinux> ?
[21:43:42] <cradek> besides, I think ray is the only one in the US without broadband :-)
[21:43:52] <SWPLinux> heh
[21:44:02] <SWPLinux> my mother also has no broadband
[21:44:12] <alex_joni> SWPLinux:
http://dsplabs.cs.utt.ro/~juve/dropbox/lightscribe/
[21:44:17] <SWPLinux> though that's irrelevant to the EMC discussion :)
[21:44:37] <alex_joni> I already have the DVD.. just need to write some data on it :D
[21:44:38] <SWPLinux> you can do that on CDs as well
[21:44:43] <SWPLinux> I think
[21:44:43] <alex_joni> yeah, I know..
[21:44:50] <alex_joni> but I only have DVD blanks now
[21:44:55] <alex_joni> with lightscribe I mean
[21:45:06] <SWPLinux> I see you got it to work :)
[21:45:37] <cradek> my computers generally don't have DVD drives - I would hate for that to be a requirement (say for the discs we hand out at fest)
[21:46:04] <SWPLinux> I don't think it's a good single option, but in addition to the CD, it would be good
[21:47:27] <alex_joni> SWPLinux: it's way easier to make a second CD with the needed apps
[21:47:35] <alex_joni> user only needs to sudo apt-cdrom add
[21:47:37] <cradek> very good idea
[21:48:18] <alex_joni> SWPLinux: the instructions I put on the EMC2.1.0 wiki page would work for a custom CD too
[21:48:30] <SWPLinux> good, but loses the ability to have extra things on the menu for a CD boot
[21:48:50] <alex_joni> it won't boot..
[21:49:02] <SWPLinux> sorry - typed too slowly :)
[21:49:04] <alex_joni> it's only a CD with a repo on it
[21:49:15] <SWPLinux> meant that a second CD lets you install, but not try other apps
[21:49:33] <alex_joni> what other apps?
[21:50:03] <SWPLinux> anything elst that may be of interest: qcad, eagle, synergy, gcam, ($whatever)
[21:50:25] <alex_joni> nothing stops you from packaging those :D
[21:50:27] <SWPLinux> devel packages is one advantage. extra apps is another
[21:50:37] <SWPLinux> (on the live CD/DVD)
[21:51:19] <SWPLinux> I'll fiddle with a live DVD someday
[21:51:33] <cradek> I wouldn't want to redistribute any of that non-Free software without a lot of research
[21:51:50] <SWPLinux> sure - those were jus what I could think of off the top of my head
[21:51:56] <cradek> right
[21:52:14] <SWPLinux> having KDE available on the same disc might also be good (for qt apps, plus for the choice)
[21:52:50] <cradek> I think this is where I stop being interested
[21:52:54] <SWPLinux> heh
[21:53:13] <cradek> I don't want to be in the business of repackaging OSes any more than necessary
[21:53:15] <SWPLinux> it can be called the EMC Bloatware edition
[21:53:57] <cradek> IMO we should concentrate on EMC, not EMbuntuC
[21:54:07] <alex_joni> umbuntu?
[21:54:15] <cradek> umm, buntu
[21:54:29] <alex_joni> ha
[21:54:58] <cradek> the more we repackage, the more we risk people misunderstanding and thinking we have our own OS distribution
[21:55:36] <cradek> I have not heard of someone who wants to help development who is not resourceful enough to get the necessary software installed
[21:55:49] <cradek> resourceful/patient/whatever
[21:57:20] <SWPLinux> connected :)
[21:57:30] <SWPLinux> (not that one can develop without a connection)
[21:57:37] <alex_joni> stubborn
[21:57:39] <cradek> not easily.
[21:58:33] <alex_joni> nuff for today
[21:58:37] <alex_joni> good night all
[21:58:51] <SWPLinux> see you Alex
[21:58:59] <cradek> goodnight
[21:59:22] <alex_joni> http://bash.org/?10937
[22:01:33] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[22:02:41] <SWPLinux> I wish I'd stop leaving like that
[22:04:26] <cradek> * cradek hands SWPLinux a real irc client
[22:04:39] <SWPLinux> SWPLinux has one, apparently :)