Re: [Desktop_architects] [cairo] Automated testing of Cairo
On Aug 16, 2006, at 4:57 PM, Bryce Harrington wrote: All inter-machine communication in Crucible is done through a networked file system. I use NFS for this, which isn't very well suited for handling remote test machines. Thus, it'd be easiest if a machine could just be plunked down in the OSDL network. Mmm, yeah, I imagine so. It's easier for me to get machines and admins elsewhere, but I bet we can figure something out. However, since the machines are just communicating via a file system, in theory anything allowing network file sharing should do. RDP and VNC are probably overkill for this; WebDAV ought to be sufficient. The main consideration is security. While we keep the test systems outside our company firewall, I'd prefer to ensure access is limited to machines I specifically know about. Understood; we could provide a fixed IP address and use an SSL client cert to lock down the connection. I've got a machine that we could use to test this on, and I suspect I can get someone to help with the setup. It's already configured to build Mozilla, so it shouldn't be _too_ hard to get it running and building the cairo stuff distinctly. I'll get that going, and connect them with you off-line (and you, if you'd like, Carl!) to see if we can work it out. I'm quite keen to see the tests running well on Win32, so I'd love to help out here. Mike ___ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
Re: [Desktop_architects] [dtl_s_t_m] Adding some background information...
On Jun 14, 2006, at 1:55 PM, Calum Benson wrote: Indeed... I've often thought that larger OSS projects might benefit from a feedback squad in much the same way that they have bug squads... a team of people whose job is to patrol mailing lists, web forums, IRC and bug reports, and collate user feedback into a single place (possibly the bug database, possibly not) in a format that the project's usability team could best make use of. It's worked pretty well for us, yeah. Mike (though usability team is a bit of a soft term in our world) ___ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
[Desktop_architects] Linux Desktop vs Open Source Desktop
On 26-Jan-06, at 12:42 PM, Bastian, Waldo wrote: Not exactly open source, but Making Linux successful on the desktop is a hard problem. Making open source successful on the desktop, atop any operating system, is a hard problem. This group is obviously invested in the former, due to nature and composition, and we could have all manner of conversation about different paths to that success. (Maybe some people here are also interested in the latter problem. Another set of interesting conversations, to be sure.) But I think that welding those two problems together is borrowing trouble, and making the perfect the enemy of the good. (To be perfectly clear: I am not saying that people are representing that position here, so this is possibly a complete straw man, but I think it's an important issue of scoping and plausibility, so I thought I'd go ahead anyway.) Mike ___ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
Re: [Desktop_architects] Most wanted Application: Email
On 21-Dec-05, at 5:55 PM, Miller, Marc wrote: The trick then becomes to create demand for that server-end app by creating a client that supports compelling additional features without crippling the user for not having the server end of the solution. Do we need to do that for the Linux desktop to succeed? Mike ___ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
[Desktop_architects] Re: Runtime dependency limitations
On 18-Dec-05, at 9:43 PM, Dan Kegel wrote: Mike Hearn (who wrote relaytool) said that Debian objected to it (see http://plan99.net/autopackage/Linux_Problems#weak ) because it would defeat Debian's automatic dependency scanning. Presumably implementing DT_USEFUL directly would make them happy. Yeah, I agree with Mike that making automated dependency scanners a barrier for such things is sort of like cutting off your nose to make your glasses fit better, only you don't gain the benefit of additional nasal portability. If the automated dep scanner isn't good enough, you fix it or you go back to doing it manually. It's hard enough to get stuff working without people taking useful tools like relaytool out of our hands. Does anyone have a better link for the definition of DT_USEFUL, by the way, or is this something Mike Hearn came up with himself? Mike might well have come up with the DT_USEFUL term, but at least IRIX has had this support for ages. The key google inputs are #pragma optional and _MIPS_SYMBOL_PRESENT. If you have access to an IRIX system, /usr/include/optional_sym.h is another good source of information. The basic model is that an optional symbol is resolved against a magic, well-known symbol if it can't be found in a real library. I think IRIX used _missing_function, but it might be nice for it to work for non-function symbols as well and reflect it in the naming. A macro compares a given symbol's address to _missing_function, and, if they don't match, can go ahead and use the symbol normally. I must preface any such remark with admission of my complete and joyous ignorance of bfd and Linux linker internals, but: it doesn't sound like the science of rockets to add such support to our toolchain and ld.so. Mike ___ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
