Re: Debian architectures, according to popularity-contest
Hello Joey and all you other Debian heroes,Joey Hess wrote:"It's interesting to see arm increasing like this. I wonder which new arm systems are responsible?"It's likely that the TS-7300 is an ARM embedded computer quickly growing in popularity. I suggest this because the TS-7300 (and similar, past Technologic Systems products) seems to be the only Debian-compatible ARM computer that has ads for it in Linux Journal on a regular basis. After a couple months tinkering with one of these (with the goal of getting a working desktop), I've posted some juicy, straight-up technical info about the TS-7300 here: http://lists.debian.org/debian-arm/2006/07/msg00027.htmlhttp://ca.blog.360.yahoo.com/dustinharriman?p=7 http://ca.blog.360.yahoo.com/dustinharriman?p=11Also see desktop screenshot and other pix of my TS-7300 (dig the cheesy, tiny cardboard case I made with penguins on it) here: http://ca.photos.yahoo.com/ph/dustinharriman/slideshow?.dir=/af59scd&.src="">Cheers, Dustin HarrimanMy Blog: http://ca.blog.360.yahoo.com/dustinharrimanRSS Feed: http://ca.blog.360.yahoo.com/rss-RkGSoVA1brWtXrVH9Gr5CzgVujwwGg--?cq=1
Easy way to incorporate Ubuntu improvements back into Debian?
Hi, Ubuntu benefits alot from Debian. They have custom development tools for streamlining the process of taking Debian packages and making them into Ubuntu packages. I'm curious: does the reverse of this exist for the convenience of Debian Developers somehow? For example (just a thought): how about a Debian Developer receiving an email every time Ubuntu has added something (possibly juicy) to a Debian package (that the DD maintains) upon Ubuntu adding it? In this way, the juicy bits that Ubuntu adds could possibly get back to into Debian quicker. What processes, infrastructure and tools are in place to streamline Debian integrating improvements Ubuntu makes? The reason I ask is that there are several huge usability improvements that Ubuntu has over Debian that I would love to see in Debian. What are the chances of Debian catching up to the quantum leap in usability that Ubuntu has added in Etch? Has Ubuntu been consistent in sending all these goodies back upstream to Debian (or farther)? It seems to me that Ubuntu is getting alot more out of their friendship with Debian, than Debian gets out of Ubuntu. Anyone have comments on this? Please correct me if I'm wrong, and examples would be great. Does Debian get lots of benefits from Ubuntu (in the software) that I'm unaware of? Don't get me wrong, I deeply dig Ubuntu and Debian. I would just like to get a pulse for who is benefiting more (and by how much) out of the relationship, and hear some technical examples of processes and instances of these benefits (especially in the direction of Ubuntu to Debian). Cheers, -- Dustin Harriman http://annexia.ca My Blog's RSS feed: https://annexia.ca/news/RSS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A Big Thank You to all OSS Developers (especially Debian Developers)
Hi all, I realize that this is a technical forum, and I have something technically useful to contribute (in the sense of offering motivation to keep going full steam): my heartfelt thanks for all the efforts given by Debian Developers. I've carefully written a technically detailed "Thank You" letter explaining why I'm so grateful for the efforts going into Debian GNU/Linux in particular, and for all OSS in general: http://annexia.ca/Members/Dustin/Articles/Cultural/BigThankYou I also post this here to possibly brighten your day. If your day is bright enough, then by all means, move along. :) Here's a sample snippet from the end: "Most of all, I want to thank the Debian developers, whom I feel are the most altruistic and giving of all OSS developers (look at the extra mile they go to support all those architectures, languages, and releases). As a Debian developer/maintainer, you live up to standards of technical quality far beyond what even the largest corporations adhere to. How amazing it is that without being directly paid, you often do a far better job than paid professionals who are (ie. witness what a pain it can be to install most commercial software in Linux, which is rarely packaged in a given distro's native format). You uphold a constitution that embodies high ideals of human compassion, even if it's in a deeply geeky way that most cannot appreciate. As various commercial Linux distributions come and go, blowing in the wind from varying economic forces, it's safe to say that Debian (which is non-commercial) will stand the test of time. To all Debian developers, I want to say thanks for working towards such a rock solid, comprehensive, sustainable distribution that I'll probably still be using when I'm old and grey." Enjoy, and Cheers, Dustin Harriman http://annexia.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Benjamin Mesing wrote: However I have to say that I disagree with you in some points. You are correct, that the package description should be as non technical as possbile, without underminining the usefullness of it. Yes, I agree. Instead of the "absolutes" I proposed, perhaps it still makes alot of sense to have generally have rules of thumb that: 1) Package descriptions should tend towards readers like grandma by default (ie. are as general as possible by default), and 2) Debtags tend toward geekly, highly-accurate searchability by default (ie. are specific by default) This would still help reduce redundancy and economize the efforts of volunteers who edit the Package Descriptions and add Debtags. I think the following formula should hold true: What you don't understand that should be of no use to you. E.g. I don't have any use for programs evaluating DICOM images (I only know what it is from a recent discussion in debtags-devel). I strongly agree here. Additionally I do strongly disagree with debtags describing only the internals! Debtags is designed to allow an effective search without the fuzziness you get, when doing a full-text search. And it fullfills this task very good (have a look at the use:: and works-with:: facet). Or should your grandma read the >15.000 package descriptions to find a program to archive her receipies? My point is that Grandma should be able to merely use the simple search dialog in Synaptic without having to mess around with selecting/surfing through debtags. Moreover, her search terms are going to be very general, eg. "money" (instead of accounting) or "recipes" (instead of cooking). Therefore, let her general query turn up the best results, and hopefully having a general description (ideally with example use mentioned) in Package Descriptions helps in this regard. A Package Description provides the opportunity to squeeze in a few synonyms, or related words for even better searchability beyond the rather standard values in Debtags. If the debtags also get searched when she does a simple search, then great. This will depend on how seamlessly debtags get integrated into package managers (like Synaptic's) search facilities (for example, a simple search by default, then an "Advanced" button to expand the search dialog, and there are all the debtags to select or exclude, with logical operators). Finally I disagree with debtags being highly technical. It is only one step further from hierachies, and in my opinion even more intuitive. That's a good point. Since this is CC'ed to debtags-devel, perhaps there could be a quality measuring facet called "Maturity::", with Sourceforge-like values such as: "Conceptual" -> "Planning" -> "Pre-Alpha" -> "Alpha" -> "Beta" -> "Stable" -> "Mature" I have CCed debtags-devel and attached your original message for the benefit of those reading only debtags-devel. Best regards Ben Wouldn't it make sense that debtags and Package Descriptions not do redundant work of each other? And on a related tangent, wouldn't it also make sense that all the volunteers who are going to examine all the package descriptions one at a time also create the appropriate debtags while they are at it? This could further help eliminate redundancy in what debtags and package descriptions explain. At the very least, wouldn't it make sense for there to be more coordination between the debtags effort, and the Packages Descriptions review campaign? Maybe the gui tool "debtags-editor" should/could be extended to *also* allow editing of package descriptions? Cheers, -- Dustin Harriman http://annexia.ca -- Dustin Harriman http://annexia.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Usability: Technical details in package descriptions?
Hi all, Debtags shows great promise in covering the technical aspect of describing Debian packages. Debtags do a better job than Package Descriptions when it comes to precisely describing a package in a highly-technical, highly-searchable format (that is fully geek compliant). Wouldn't it make sense that debtags and Package Descriptions not do redundant work of each other? I propose that by a simple split in the use of the Package Description and debtags between the "internal world" (ie. relative to the computer) and "external world" (ie. relative to the end user's real life apart from their computer), respectively, I think we can make the best use of volunteer effort as they review the Package Descriptions and create debtags. I think that the Package Description should be (re)written using language intended at your grandma. This way she can intuitively find packages also without needing to learn about the debtags system. Learning how to use the search button in Synaptic is work enough for her, let alone learn and play with debtags to do wild and crazy searching (with logical operators no less). As debtags cater to the geek, I think the Package Description should cater to grandma. I think the package desription should state the purpose of the software as it relates to the real world, whenever possible: eg. "helps you easily keep lists of contact information on people along with details like their birthdays". A description like this is useful to grandma. Anything more technical and you lose her to the likes of Ubuntu or Linspire. Come on, throw grandma a (less than 80 character) bone! Grandma can give back some day by helping to file a bug report or something. I therefore propose that ***the package description should explain how a package could be used for real-world usefulness for the end user***, giving an example or two for those with dimmer imaginations than hard core geeks. In my example above, mentioning tracking birthdays helps users start imagining the potential usefulness of the software. Note how mozilla.org has a screenshot of the craiglist website on the front page to help users *imagine* visiting a website like craigslist using the browser (albeit visually, not textually). Same idea. Imagining how some piece of software could be useful is hard work for most people, and you can help them tremendously by providing a simple and obvious-to-you example in the package description. Debtags will much better handle all the fine-grained, geeky details, like the language it was written in, and to which suite it belongs. Therefore ***I think debtags should aim to exclusively describe a package's relationship to the internal system it lives in, ie. relative to Debian.*** And on a related tangent, wouldn't it also make sense that all the volunteers who are going to examine all the package descriptions one at a time also create the appropriate debtags while they are at it? This could further help eliminate redundancy in what debtags and package descriptions explain. At the very least, wouldn't it make sense for there to be more coordination between the debtags effort, and the Packages Descriptions review campaign? Maybe the gui tool "debtags-editor" should/could be extended to *also* allow editing of package descriptions? Cheers, -- Dustin Harriman http://annexia.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
