| 00:02.02 | *** join/#utah spr (n=spr@c-24-10-236-93.hsd1.ut.comcast.net) |
| 00:03.16 | xbmodder | DuN |
| 00:04.49 | *** join/#utah findlay (n=justin@208.187.181.35) |
| 00:06.53 | *** join/#utah SpecialK (n=sjk36@fruits.cs.byu.edu) |
| 00:10.18 | *** join/#utah dn3e8 (n=dna3e8@71-36-84-210.slkc.qwest.net) |
| 00:19.57 | *** join/#utah SpecialZ (n=Scott@128.187.140.33) |
| 00:30.24 | xbmodder_lappy | sup all |
| 00:36.13 | *** join/#utah emcnabb (n=emcnabb@70-57-89-223.slkc.qwest.net) |
| 00:36.25 | maquis | -lart emcnabb |
| 00:44.32 | xbmodder_lappy | <PROTECTED> |
| 00:45.26 | *** join/#utah sjansen (n=sjansen@h4607608d.area7.spcsdns.net) |
| 00:47.01 | sjansen | ~lart dpkg |
| 00:47.20 | sjansen | dpkg must suffer!!! |
| 00:47.45 | hans | -lart rpm |
| 00:48.26 | sjansen | What's so hard about doing a dependency check before installing? |
| 00:48.44 | sjansen | And how in the world do I examine the pre- and post-install scripts without actually installing the package? |
| 00:49.12 | sjansen | Say what you will, rpm is fast, it has an easy to learn interface, and it's behavior is generally sane. |
| 00:50.25 | sjansen | The only thing dpkg had going for it was apt; aptitude is a nice incremental improvement (of the two steps forward, one step back variety), but with each day Yum comes closer to completely eclipsing it. |
| 00:50.27 | emcnabb | hear hear! |
| 00:50.37 | hans | easy to learn interface? are you talking abouit some API because the commandline interface is anything but easy to learn |
| 00:51.22 | hans | and it's 'generally sane behavior' has bitten me more times than I have heard you complain about dpkg |
| 00:51.37 | sjansen | You can't be serious? rpm has a nice sane set of switches and modifiers, dpkg is a crazy mix of different tools and switches that were apparently inspired by a language other than English. |
| 00:52.00 | sjansen | dpkg -s <-- get information about an installed package |
| 00:52.07 | hans | like -e for remove? -qwersasdf for querying that one thing you need to know? |
| 00:52.11 | sjansen | dpkg-deb -I <-- get information about a package not yet installed |
| 00:52.25 | sjansen | dpkg -L <-- list software in an installed package |
| 00:52.47 | sjansen | dpkg -S <-- give the name of the package that installed a file |
| 00:52.49 | hans | i won't say the one-letter switches in dpkg make any more sense than the ones in rpm |
| 00:53.00 | sjansen | rpm -qi <-- get information about an installed package |
| 00:53.15 | sjansen | rpm -qip <-- get information about a package that hasn't been installed |
| 00:53.25 | hans | yeah, p makes a lot of sense |
| 00:53.36 | sjansen | rpm -ql <-- list files in an installed package |
| 00:53.45 | sjansen | rpm -qf <-- list the package that installed a file |
| 00:53.48 | hans | that makes more sense than -L? |
| 00:54.18 | sjansen | rpm -ql makes more sense, it's a modifier to -q instead of random switch of it's own |
| 00:54.21 | hans | all of which I have used a dozen times and still can't remember. sorry, it doesn't qualify as a good interface |
| 00:54.35 | emcnabb | well, I can't remember the dpkg switches |
| 00:54.47 | sjansen | I don't mind -L so much, it's the inconsistency between -L/-s/-S. There's no apparent relationship there, let alone between the other switches |
| 00:54.50 | hans | and I can't remember the rpm switches. |
| 00:54.50 | xbmodder_lappy | man dpkg usually works |
| 00:55.03 | emcnabb | I guess it just depends on what you use the most |
| 00:55.20 | hans | you're gonna remember the ones you use most. I agree they both are terrible interfaces |
| 00:55.23 | sjansen | As long as you don't try to do something foolish like upgrade an package to a newer version, sure dpkg kinda works most of the time. |
| 00:55.45 | hans | dpkg has always checked dependencies for me |
| 00:55.47 | emcnabb | I do like how rpm has all queries use -q_ |
| 00:56.19 | hans | I think it just hates you. |
| 00:56.28 | sjansen | But woe to you if you try to upgrade a package and a dependency fails. It's do a half-a**** job, then aptitude will decide to uninstall it and the previous version just for good measure. |
| 00:57.20 | sjansen | What's so hard about the idea of software installation being a transaction? Either it succeeds and you commit, or it fails an you roll back. |
| 00:57.29 | emcnabb | maquis, well, you can just look inside of an RPM spec file, or use a --scripts, etc |
| 00:57.35 | sjansen | But no, dpkg has to do some crazy multi-phase thing. |
| 00:57.53 | sjansen | hans: So, how do I do that? |
| 00:58.04 | xbmodder_lappy | Does anyone here have an "owned" linux server? |
| 00:58.13 | maquis | emcnabb: true... i guess... |
| 00:58.15 | hans | a dependency fails, as in ... |
| 00:58.16 | xbmodder_lappy | I want to examine on. |
| 00:58.19 | maquis | xbmodder_lappy: hopefully not |
| 00:58.30 | sjansen | rpm -q --scripts is a nice and easy way to see scripts will run during pre- and post-install or with uninstall. |
| 00:58.31 | xbmodder_lappy | And not put a honeypot up |
| 00:58.34 | hans | I'm imagining your dependency didn't install like it was supposed to |
| 00:58.36 | emcnabb | xbmodder_lappy, there you go with the dumb questions again |
| 00:59.01 | hans | so the first thing is to file a bug on that dependency for not installing, since that shouldn't happen TM |
| 00:59.19 | sjansen | hans: No kidding. I know that. But a decent package management system should leave me with software half-installed. It should roll back, returning the system to its previous state. |
| 00:59.29 | xbmodder_lappy | emcnabb, I would like to examine the nature of Linux based infections. |
| 00:59.52 | xbmodder_lappy | I've seen one infection and its quite interesting. |
| 01:00.02 | sjansen | Frankly, it's an impressive display of stupidity that the dpkg developers apparently decided the proper time to check dependencies is _after_ partially installing the software. |
| 01:00.13 | xbmodder_lappy | lol. |
| 01:00.16 | hans | dependencies are checked before |
| 01:00.46 | sjansen | Not if you do a dpkg -i, they're not. |
| 01:01.13 | hans | what are you talking about? I've had dpkg refuse to install a package due to dependencies not being installed many many times |
| 01:02.17 | sjansen | dpkg starts by recording that the software is being installed, discovers that a depency is missing, stops installing, keeps the failed new version recorded as partially installed and supersceding the previously installed version |
| 01:02.18 | hans | frankly, dpkg is ancient and stupid. what impresses me more is that it took redhat so long to come up with something even as remotely usable as apt-get. |
| 01:02.47 | sjansen | Finally, we agree that dpkg is a piece of trash. |
| 01:02.59 | hans | i never disputed that. :) |
| 01:03.19 | sjansen | Now for my second point: the debian package management system is a mess of too many oddly designed tools. |
| 01:03.29 | sjansen | rpm + yum + rpmbuild == complete system |
| 01:04.17 | sjansen | dpkg + apt-cache + apt-get/aptitude + dpkg-deb + dpkg-several-other-stinking-utilities-each-with-random-switches == complete system |
| 01:04.40 | sjansen | At least dselect can be considered basically dead. |
| 01:04.41 | hans | hindsight is 20/20 |
| 01:05.07 | hans | the same thing can be said about most of posix |
| 01:05.26 | sjansen | Hindsight? Hindsight nothing, you still have to use a random mix of those tools even today. |
| 01:05.55 | sjansen | It'd be hindsight if something had been learned, but nothing has been learned. |
| 01:06.20 | hans | you said rpm+yum+rpmbuild was beauty. I say it benefited from the work of apt |
| 01:06.20 | sjansen | Sure, some nice tools like apt-get and aptitude have been hacked together, but they're only partial solutions. |
| 01:06.43 | hans | so naturally yum can be better designed from the getgo, as a latecomer |
| 01:06.50 | sjansen | And you still haven't answered my question, is there any way I can find out what scripts are run as part of the install process? |
| 01:06.51 | hans | one of these days I need to try yum |
| 01:07.08 | sjansen | yum is the least important of those tools |
| 01:07.16 | hans | ha |
| 01:07.23 | sjansen | rpm is the real killer tool if you learn to use it |
| 01:07.43 | hans | sorry, I've used rpm and rpmbuild, and I am not impressed. compared to dpkg, perhaps, but totally unusable for a user. |
| 01:07.56 | sjansen | and it isn't nearly so hard to learn because everything is mostly concentrated in one tool, meaning one man page, and nice broken out install sections (query, install, upgrade, etc.) |
| 01:08.58 | sjansen | I don't care about users right now. I care about administrators. I'm an experienced administrator, and dpkg makes me hunts and beg to find out information that's easy to track down in rpm. |
| 01:09.42 | sjansen | Sure, it's got more bells and whistles, but it would have been nice if more time had been spent providing resources I actually use and making them easy to access instead of providing hooks for every idea that came along. |
| 01:09.53 | hans | <PROTECTED> |
| 01:10.31 | emcnabb | hans, how about for a package file |
| 01:10.36 | emcnabb | that I'm about ready to install |
| 01:10.40 | sjansen | You're kidding right? I have to install the software to find out what nefarious things it's going to do to my system? |
| 01:10.41 | emcnabb | I've wondered about that before |
| 01:10.51 | hans | i've never bothered to figure it out. |
| 01:11.03 | hans | sjansen: that's what dr. google told me, I've never tried before |
| 01:11.11 | sjansen | Yeah, well I've bothered to try to figure it out a couple of time and I still haven't been able to find the magic tool. |
| 01:11.23 | hans | there's always apt-get source |
| 01:11.27 | hans | then look in debian/ |
| 01:12.00 | hans | and i've tried to build an rpm dozens of times and have yet to succeed. JUST to build a frickin' rpm. dpkg-buildpackage -us -uc may be esoteric, but at least it works. |
| 01:12.15 | sjansen | Assuming the package I want to install comes from an apt repository and that a source package exists. Bzzzzzzzzzt, still the wrong answer. |
| 01:13.00 | sjansen | hans: Define build? Create your .spec file, or just build a .src.rpm |
| 01:13.43 | sjansen | Building a .src.rpm is ridiculously simple, you've either spent zero time learning how or had unbelievably bad luck with google. |
| 01:14.17 | sjansen | As for creating a .spec file, here's a pretty good intro: http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF |
| 01:14.59 | sjansen | Actually, it's rather unbelievable. |
| 01:15.30 | sjansen | The hardest thing to learn is that whereas you could rpm --rebuild you now need to rpmbuild --rebuild. |
| 01:16.14 | sjansen | As for the options to rpmbuild, the man page is nice an straight forward. |
| 01:17.37 | sjansen | rpm -i foo.src.rpm ; cd /usr/src/REDHAT/rpm/SPECS/ ; rpm -bb foo.spec <-- If you want to do things the slightly harder way. |
| 01:18.53 | sjansen | Leave off the REDHAT directory for most other RPM based distros. And to be safe, you really ought to setup a normal user account for building instead, but without learning all of that you can still build a .src.rpm or a .tar.gz with a .spec inside very easily. |
| 01:20.19 | maquis | sjansen: i'm gathering that you can install from both a .src.rpm and from a .tar.gz with a .spec |
| 01:20.34 | maquis | i've never installed directly from either |
| 01:20.57 | sjansen | No, you can build from both. And if the build succeeds, you should be able to install the resulting packages. |
| 01:21.18 | maquis | oh |
| 01:21.25 | maquis | i've built from a src.rpm |
| 01:23.04 | sjansen | hans: I love you man, but it ticks me off when people who have done very little research assume they're right, their favorite toy is perfect and I'm wrong. |
| 01:23.15 | sjansen | Debian users seem to do that an awful lot. |
| 01:25.13 | sjansen | I've been using Ubuntu for almost a year now to learn more about a dpkg-based system. There's some nice things about it, but y'all could do with a bit more awareness of the RPM-based distros. Just because you don't know them, you assume they're inferior. |
| 01:25.33 | hans | thanks for the insults, but it was just dinner time |
| 01:25.45 | sjansen | Red Hat, to name just one example, hasn't been ashamed to learn from Debian. |
| 01:26.10 | sjansen | Debian seems to be more interested in inventing every solution itself. |
| 01:28.37 | hans | I spent 2 years of my linux life on redhat, as a newbie and as a professional, I think I have had enough experience to say that you are also a little bit biased. |
| 01:29.25 | xbmodder_lappy | Gentoo is.... |
| 01:30.49 | sjansen | hans: See, the problem is that you make statements but don't back them up. |
| 01:30.50 | hans | my opinion of rpm and readhat comes not from a belief that debian is paradise in bits, but from my own experience prior to even trying debian |
| 01:31.13 | sjansen | If anything, I'm becoming less biased with time. |
| 01:31.30 | hans | that's good. I hope I do too. less biased is generally a good thing |
| 01:31.47 | sjansen | I've cited things that I like about Ubuntu (some of which come from Debian). I've cited things I don't like. |
| 01:32.11 | sjansen | All you've said is RPM suxors without going into any detail. |
| 01:32.37 | xbmodder_lappy | rpm is a pretty nice utility. |
| 01:32.45 | hans | that's a very superlative statement. hope you can back it up |
| 01:33.14 | sjansen | I'm willing to accept if I'm wrong about dpkg and family (although you'll have to give me that it's harder to find stuff out about them), but you've got to do more than expect me to accept on faith that it can do what I haven't been able to make it do yet. |
| 01:34.42 | sjansen | Okay, you've said that it's much easier to build debian packages from source. I doubt that, but I've put all of about five minutes into trying to build a dpkg from source (which, incidentally, wasn't as easy as a nice .src.rpm although that might have been the fault of the package provider). |
| 01:35.04 | sjansen | Tell me about this package you had trouble building. |
| 01:36.22 | sjansen | You've also accused rpm of corrupting you system more often, but haven't provided any detail. I've told you about a scenarior I've seen repeatedly: dpkg -i, dependecy fails, dpkg doesn't roll back, aptitude wants to uninstall paritally installed package and its dependencies. |
| 01:36.50 | xbmodder_lappy | packaging things are much easier using portage |
| 01:37.57 | xbmodder_lappy | hmm... |
| 01:37.58 | sjansen | xbmodder_lappy: Assuming you never want to do something so uncommon as uninstall software. Or has portage finally implemented that? |
| 01:38.11 | xbmodder_lappy | emerge -C package |
| 01:38.37 | xbmodder_lappy | sjansen, A bit too well, a few people have unmerged python and required things. |
| 01:38.53 | maquis | *cough* |
| 01:39.25 | sjansen | A package management system is uselss if its dependency checking only happens during install. |
| 01:39.33 | maquis | strcpy includes the \0, right? |
| 01:39.42 | sjansen | man strcpy |
| 01:39.51 | maquis | sjansen: i know... |
| 01:40.58 | maquis | sjansen: what i want is a package management system that, when you remove something, checks all the dependencies to see whether anything else depends on them, and if not, checks to see whether they were explicitly installed by the user, or solely because of the dependency, and then removes them if they're removable and not explicitly installed |
| 01:41.32 | maquis | if you see that package management system running around anywhere, let me know |
| 01:42.09 | maquis | hmmm |
| 01:42.49 | sjansen | aptitude can do that |
| 01:42.53 | maquis | so, this strcpy is writing over the first byte of the returnval with \0, but the function is still returning fine, and going fine... |
| 01:43.03 | maquis | sjansen: i didn't manage to ever get it to do it correctly |
| 01:43.20 | sjansen | you have to use aptitude to do the installation |
| 01:43.42 | maquis | sjansen: i was... maybe i wasn't using the right parameters, though |
| 01:43.48 | sjansen | if you use synaptic/apt-get/dpkg to install, you have to go back to mark the dependencies as such |
| 01:44.01 | maquis | oh.. .wait... aptitude... |
| 01:44.05 | maquis | no... i'm thinking apt-get... |
| 01:45.28 | hans | aptitude has a commandline interface too, in fact you can alias apt-get=aptitude (so I hear) |
| 01:45.47 | maquis | hans: interesting... |
| 01:46.09 | sjansen | but you can't alias apt-cache=aptitude because the two behave differently |
| 01:46.49 | sjansen | With aptitude, there's basically no reason to use apt-get, but you still should keep the other apt tools. |
| 01:46.49 | maquis | i find that i keep getting into the situation where my computer is full of dependencies and such that i don't use because i install something, and then later remove it |
| 01:47.36 | goozbach | suggestions for a free-as-in-beer antivirus software for windows? |
| 01:47.44 | hans | otoh sometimes aptitude will want to remove something I _do_ want, but never had to install manually because something else that is gone depended on it. so verification is important too. |
| 01:47.51 | maquis | goozbach: i've heard clamav is pretty good on windoze.... |
| 01:48.01 | hans | clamav, if you don't need realtime scan |
| 01:48.18 | goozbach | (it's the anual fix-mom's-pc time) |
| 01:48.24 | hans | :) |
| 01:50.10 | goozbach | and if I need real-time? |
| 01:50.17 | hans | shrug |
| 01:50.56 | JoshH | goozbach: get her a mac mini |
| 01:51.02 | emcnabb | http://www.grisoft.com/ |
| 01:51.23 | emcnabb | http://www.grisoft.com/doc/289/lng/us/tpl/tpl01 |
| 01:51.32 | emcnabb | that's what I installed on my Mom's machine a while back |
| 01:51.33 | sjansen | dpkg-deb --control <-- can be used to examine the scripts |
| 01:52.49 | sjansen | unfortunately, it insists on extracting junk instead of letting me just examine them on stdout |
| 01:56.32 | hans | so is yum the clear leader in humanizing rpm? |
| 01:56.46 | goozbach | yup |
| 01:57.38 | sjansen | Well, on Fedora it is. There are some apt die hards, but they're dying off. |
| 01:58.05 | hans | where is apt4rpm used primarily? |
| 01:58.10 | *** join/#utah Uncle_Jesse (n=jstay@c-67-169-253-101.hsd1.ut.comcast.net) |
| 01:58.23 | sjansen | On SUSE, the picture is less clear. Yast is the entrenched leader, but hardly loved. Yum has some mind share, but Red (Open) Carpet also has its foot in the door. |
| 02:00.04 | sjansen | And, of course, Mandrive has urpmi. |
| 02:00.30 | emcnabb | e.g. http://rpm.livna.org/ - They claim that 98% of the users of their archive use yum, so apt support is going to be discontinued |
| 02:01.12 | *** join/#utah synic (n=synic@c-67-177-16-249.hsd1.ut.comcast.net) |
| 02:01.22 | sjansen | I'm not aware of any major distros that use apt4rpm primarily. It had its day in the sun on RHL/Fedora. It had a (very) brief fling with SUSE. Mandriva users seem pretty devoted to urpmi. |
| 02:02.30 | xbmodder_lappy | errgh. my headache is getting worse. |
| 02:02.48 | goozbach | drink a coke |
| 02:03.24 | xbmodder_lappy | more like ibuprofen. |
| 02:04.58 | maquis | xbmodder_lappy: go to sleep |
| 02:05.39 | maquis | bah |
| 02:06.30 | maquis | ok... so, some of the references i've read so far say that the callee-save registers are added to the stack before local variables and some say after |
| 02:07.06 | xbmodder_lappy | maquis, ok. |
| 02:07.12 | sjansen | depends on the conventions being used, are you specifically reading the Linux C conventions? |
| 02:07.42 | maquis | sjansen: i'm just looking for anything that might explain it... i'm guessing i probably want whatever gcc does |
| 02:07.49 | maquis | since that's what i'm working with |
| 02:07.55 | sjansen | I don't remember the details, but I remember that Windows and Linux are basically polar opposites. |
| 02:08.19 | maquis | sjansen: that explains why the resources i've been looking at say opposite things |
| 02:08.20 | sjansen | It's also going to depends on chipset. |
| 02:09.00 | sjansen | HPPA actually has it spelled out specifically to encourage operability between compilers on the chipset. |
| 02:09.18 | maquis | ~hppa |
| 02:09.19 | ibot | i heard hppa is http://www.parisc-linux.org |
| 02:09.19 | sjansen | x86 is more of a mess |
| 02:14.37 | maquis | sjansen: :( |
| 02:15.57 | hans | *sigh* why has darwin not implemented sem_init |
| 02:16.41 | *** join/#utah synic (n=synic@pdpc/supporter/student/synic) |
| 02:16.41 | maquis | hans: what's sem_init? |
| 02:17.18 | hans | initializes a semaphore. the alternative is sem_open, which opens a named semaphore. sem_open is more complicated. |
| 02:17.57 | maquis | hans: ah... so, if you want a semaphore, you have to use sem_open instead of sem_init... |
| 02:18.19 | hans | looks that way |
| 02:18.22 | hans | or run it on linux |
| 02:18.37 | maquis | :) |
| 02:18.37 | hans | $ ./client |
| 02:18.37 | hans | Couldn't initialize semaphore: Function not implemented |
| 02:18.37 | hans | dsm_init: Function not implemented |
| 02:18.49 | maquis | weird |
| 02:21.17 | *** join/#utah synic (n=synic@c-67-177-16-249.hsd1.ut.comcast.net) |
| 02:23.58 | *** join/#utah tensai_ (n=tensai@kite.zmonkey.org) |
| 02:25.00 | *** part/#utah tensai_ (n=tensai@kite.zmonkey.org) |
| 02:30.08 | hans | anyone know off the top of the head what lib provides strlcpy in linux? |
| 02:30.21 | maquis | -lart stack-issues |
| 02:32.01 | sjansen | hans: strlcpy isn't standard on linux |
| 02:32.12 | synic | anyone good with the synaptics touchpad driver? Is there any way to disable all but regular mouse and button events (IE, scroll events, etc) |
| 02:32.25 | hans | I see that. It seems to be in the h files though |
| 02:32.26 | sjansen | Most software that chooses to use it, includes its own copy of strlcpy. |
| 02:32.31 | hans | it doesn't complain until link time |
| 02:32.44 | sjansen | Which .h file? |
| 02:33.24 | sjansen | strlcpy (IIRC) can pretty much be implemented as a macro on top of strncpy. |
| 02:33.27 | hans | string.h |
| 02:33.57 | hans | no, sorry, linux/string.h. my vgrepper is broken |
| 02:34.22 | hans | hmm, none of these are likely included by my program, (output of grep strlcpy /usr/include) and yet it doesn't complain until linkage |
| 02:34.27 | sjansen | Isn't that the kernel headers? |
| 02:34.59 | hans | yeah |
| 02:35.05 | hans | that's not likely included by my code |
| 02:35.14 | sjansen | And rightly so. |
| 02:35.56 | sjansen | strlcpy is an OpenBSD invention, Solaris has copied, wouldn't surprise me to find out that most of the *BSD have copied it, but for some reason it hasn't been adopted by Linux |
| 02:35.57 | hans | cc -c -o dsm_client.o dsm_client.c |
| 02:36.08 | hans | no complaints whatsoever |
| 02:36.18 | sjansen | Odd. |
| 02:36.21 | maquis | sjansen: when i write to a char[] in C, it's writing down, right? |
| 02:36.32 | maquis | (ie, it's writing to progressively lower addresses) |
| 02:36.44 | maquis | wait... |
| 02:36.54 | sjansen | I'm 99.99% sure it's writing to higher. |
| 02:37.03 | maquis | aha! |
| 02:37.11 | maquis | that makes a lot more sense |
| 02:37.23 | maquis | because if it's writing downward, you can' overwrite the return address, etc |
| 02:37.44 | hans | wow, even wierder is it doesn't complain if I use it wrong (too many arguments) |
| 02:37.45 | maquis | so, when adding things to the stack, you write down, but when sticking a string into the variable, you write up |
| 02:37.46 | sjansen | hans: Oh, wait, you're creating a .o, of course it isn't complaining. Just expects it to be linked in later. |
| 02:38.21 | hans | hm, I didn't realize that |
| 02:38.27 | sjansen | It's just assuming a default signature for strlcpy since it doesn't know what to expect. |
| 02:38.38 | hans | wow, you learn something new every day |
| 02:39.22 | sjansen | You can pass flags to gcc to make it pickier, but frankly with all the strictness they've been adding to gcc I'm surprised it didn't do that already. Thought it was just old versions of gcc that assumed signatures. |
| 02:40.23 | sjansen | maquis: on x86, yes |
| 02:40.35 | maquis | sjansen: thanks! |
| 02:41.08 | sjansen | maquis: things get even more fun when you start playing with specific bytes of int's, etc. |
| 02:41.20 | maquis | sjansen: ? |
| 02:43.35 | sjansen | maquis: double *foo = 0xDEADBEEF; <-- what is the address of the 2nd most significant byte of the double? frankly, I can't tell you 'cause it requires too much thinking, but the answer isn't immediately obvious |
| 02:44.09 | maquis | sjansen: you mean because of endianness? |
| 02:44.13 | sjansen | yup |
| 02:44.16 | maquis | mmk |
| 02:45.13 | sjansen | I vaguely remember that the endianness of words and bytes isn't the same in multi-byte numerical data. Or something like that. |
| 02:45.19 | sjansen | ~lart x86 |
| 02:48.32 | maquis | ??? |
| 02:50.02 | sjansen | ~lart gstreamer |
| 02:50.18 | sjansen | ~lart sound on Linux in general |
| 02:50.30 | hans | is gstreamer abusing you? |
| 02:50.58 | sjansen | gsteamer on amd64 skips constanly with certain streams |
| 02:52.19 | sjansen | Someday gsteamer will rock, but sure would have been nice if they'd started with something simple that worked and grew it instead of designing the ultimate-super-uber-ultra-cool media-frameworks-to-end-all-media-frameworks. |
| 02:55.19 | sjansen | ~lart launchpad |
| 02:55.53 | sjansen | The Universe hates me, doesn't it? |
| 02:56.03 | hans | h_errno? what is up with that? |
| 02:56.47 | sjansen | I've been trying all afternoon to report a simple ruby packaging bug on Ubuntu, and I still haven't suceeded. |
| 02:56.47 | hans | what is wrong with errno that they had to go make h_errno? |
| 02:57.20 | sjansen | errno isn't re-entrant, perhaps that is the source of this mysterious h_errno |
| 02:57.32 | hans | hmm, maybe |
| 02:57.41 | hans | it's still a global variable, though. |
| 02:57.46 | hans | don't see how that could be reentrant |
| 02:57.58 | hans | it's gethostbyname that's using it, btw. |
| 03:01.58 | sjansen | So what're you playing with? It's apparently a multi-threaded network client. |
| 03:02.49 | hans | it's a distributed shared memory client |
| 03:02.56 | hans | and server, but the server i get to write in ruby |
| 03:03.01 | sjansen | Argh! Now gsteamer has confused X! |
| 03:03.49 | hans | and although the server is theoretically much more complicated than the client |
| 03:03.50 | hans | <PROTECTED> |
| 03:03.50 | hans | <PROTECTED> |
| 03:03.50 | hans | <PROTECTED> |
| 03:03.50 | hans | <PROTECTED> |
| 03:04.33 | sjansen | Ah, Ruby. As long as I don't think too much about it's multi-threading support that's a happy thought. |
| 03:04.35 | sjansen | ~hug Ruby |
| 03:04.37 | ibot | ACTION hugs Ruby |
| 03:04.46 | hans | what is all that c code? convoluted socket stuff and checking everything's return value |
| 03:05.17 | sjansen | And at least one security vulnerability. |
| 03:05.18 | hans | yeah, I stay away from threads in ruby |
| 03:05.27 | hans | :) |
| 03:07.23 | *** join/#utah sjansen (n=sjansen@h4607608d.area7.spcsdns.net) |
| 03:34.21 | *** join/#utah mrpull-x (i=xmjake@xmission.xmission.com) |
| 03:38.33 | *** join/#utah markl_ (i=mark@dsl093-225-127.slc1.dsl.speakeasy.net) |
| 04:45.07 | hans | this is just peachy keen. |
| 04:45.25 | hans | the ruby distributed with tiger has a broken pack/unpack |
| 04:46.07 | hans | [1].pack("N") #=> "\001\000\000\000" |
| 04:46.13 | hans | it should be the other way around |
| 04:46.19 | hans | (network byte order) |
| 04:46.25 | maquis | hans: so, fix it :) |
| 04:46.39 | hans | easy, I compile my own ruby |
| 04:46.57 | hans | the problem appears to be with the cross-compilation (apple apparently compiled it on x86) |
| 04:49.12 | maquis | why would they do that? |
| 04:49.29 | hans | probably because they were already using osx on x86 even then |
| 04:50.08 | maquis | yes... but i'm sure they had some non-x86 boxen lying around... |
| 04:50.27 | hans | yeah, it seems like a roundabaout way to do things to me too |
| 04:50.36 | hans | but they probably had their reasons. |
| 04:50.55 | maquis | you're much more diplomatic than i am |
| 04:51.16 | maquis | "they probably had their reasons" is not something i generally think |
| 04:51.48 | hans | well, there's stupidity and then there's "nobody would have done this without a reason" |
| 04:52.16 | maquis | if i can't think of a *really* good reason, i usually assume the former |
| 04:52.16 | hans | cross-compiling isn't exactly easy to do, (even if you don't get it right) so I figure they did |
| 04:52.47 | maquis | if you're going to cross-compile, shouldn't you at least test, though? |
| 04:53.35 | hans | yeah |
| 04:53.57 | hans | they really hosed it with this one. there's another problem too that messes up compiling C extensions for ruby |
| 04:54.05 | hans | but that was fixable with a patch |
| 05:04.45 | maquis | :) |
| 05:13.27 | maquis | hmmm |
| 05:14.22 | hans | you'll have an embedded screen |
| 05:14.27 | maquis | hans: yes... |
| 05:14.32 | hans | you have to escape the c-a to get to the inner one |
| 05:14.41 | hans | c-a a |
| 05:14.42 | maquis | ah.. how would i do that? |
| 05:14.50 | maquis | mmk |
| 05:15.20 | maquis | cool! |
| 05:18.06 | jsmith | ~lart postgresql |
| 05:18.24 | jsmith | (And I'm a postgresql-lover) |
| 05:18.37 | maquis | jsmith: what'd it do? |
| 05:18.46 | jsmith | maquis: It's more like what it didn't do :-) |
| 05:19.05 | maquis | jsmith: what'd it not do? |
| 05:19.10 | jsmith | So I figured it would be drop-dead simple to output the result of a query to a CSV file. |
| 05:19.19 | maquis | uh huh... |
| 05:19.23 | jsmith | Heck, I thought, even MySQL can do that... |
| 05:19.25 | maquis | did it forget the commas? |
| 05:19.46 | jsmith | No, but it forgot to quote the strings... so if the strings contained commas... well, uh... |
| 05:19.56 | jsmith | Let's just say it turns into a big mess. |
| 05:19.56 | maquis | hmmm |
| 05:20.02 | maquis | not as cool as my idea |
| 05:20.28 | maquis | i mean... sure, it's annoying that it forgot to quote the strings |
| 05:20.38 | jsmith | CSV, that is. |
| 05:20.39 | maquis | but just imagine how much fun it'd be if it forgot the commas |
| 05:20.48 | jsmith | Uh, yeah... that'd be ugly |
| 05:21.00 | maquis | i suppose it might be easier to fix, though |
| 05:21.10 | jsmith | At least the guys in #postgresql are friendly... |
| 05:21.26 | jsmith | as opposed to a lot of the channels I frequent |
| 05:21.28 | maquis | i mean... if it did that, i'd immediately guess that therewas someplace that i failed to tell it what to use as a delimeter |
| 05:21.59 | maquis | or that i had found it at some point, and misunderstood what it was, and set it to '' |
| 05:22.07 | maquis | (the latter is more likely) :) |
| 05:25.57 | jsmith | Yeah, the delimeter is easy to set... |
| 05:26.35 | jsmith | They even went so far as to suggest this: SELECT '"' || text_field || '"' AS text_field |
| 05:26.59 | jsmith | which puts quotes around the field, but still doesn't manage to quote any quotes inside the text field. |
| 05:27.26 | maquis | yeah |
| 05:28.01 | maquis | i'd think that there ought to be some nice way to tell it "i want this to all be quoted" or something |
| 05:28.04 | maquis | but... |
| 05:28.07 | maquis | yeah |
| 05:28.30 | jsmith | You'd think... |
| 05:28.37 | jsmith | Oh well |
| 05:28.51 | jsmith | My tiny app is done... and it takes care of it all... |
| 05:31.03 | *** join/#utah Uncle_Jesse (n=jstay@c-67-169-253-101.hsd1.ut.comcast.net) |
| 05:43.09 | jsmith | Time to get some shut-eye... |
| 05:58.31 | *** join/#utah Uncle_Jesse (n=jstay@c-67-169-253-101.hsd1.ut.comcast.net) [NETSPLIT VICTIM] |
| 05:58.31 | *** join/#utah colera (n=colera@monsters.cs.byu.edu) [NETSPLIT VICTIM] |
| 05:58.31 | *** join/#utah dataw0lf (n=stderr@66.219.227.114) |
| 05:58.31 | *** join/#utah mrpull- (n=mrpull|@205.158.184.112) [NETSPLIT VICTIM] |
| 05:58.31 | *** join/#utah Mecworks (n=marc@208-186-182-173.customer.csolutions.net) [NETSPLIT VICTIM] |
| 05:58.31 | *** join/#utah Bradipo (i=bradipo@xmission.xmission.com) [NETSPLIT VICTIM] |
| 05:58.31 | *** join/#utah jebar (n=jebarlow@2.wencor.com) [NETSPLIT VICTIM] |
| 05:58.32 | *** join/#utah ScytheBlade1 (n=Death@c-67-171-124-6.hsd1.ut.comcast.net) [NETSPLIT VICTIM] |
| 05:58.32 | *** join/#utah tewk (n=tewk@192.41.88.101) [NETSPLIT VICTIM] |
| 05:58.32 | maquis | yay for finishing cs465 lab |
| 05:58.32 | maquis | and it's not even monday yet! |