Re: Die GNU autotools
I'll emphasize, I did not say autosuite is always bad. Autotools has it uses (maybe a more modern implementation would be nicer, but nevertheless it does the job). But what I'm saying is, 1) Nowadays supporting some legacy systems is simply not cost efficient. And supporting legacy systems will cost you much more than the cost of using autotools, so think twice before deciding on supporting legacy systems (the main use of the autosuite, it wouldn't really help you with inotify or PulseAudio). 2) Do not use the autosuite, unless you are writing a portability layer. Otherwise you'll mix the portability layer logic into your main application logic, and this is bad. For example, in fakeroot-ng, how will you test and make sure your map is efficient enough in your platform? This logic will have to be in your main project in the current design. 3) Using autotools have it costs (mental tax, lengthy configuration, different code on different systems), so if you can avoid it - please do. Even if that means you'll copy another implementation to your codebase or supporting less platforms. As a result I conclude, that if your project goal is not to provide a portability layer, it should not use the autosuite. For instance, in the std::map example, having the efficient map abstraction coupled to your main project, and underdocumented (which platforms do the effecient map support? Which compilers does it support. Does all compilers implement unordered_map to as effecient as I require? What are actually my effeciency requirement (if I don't know then I can probably just use std::map)). All this portability-related information is hidden in the m4 files, and coupled to my project. If I keep the rule that my main logic will never use autotools, then I'll have a different small portability layer which is less coupled to my project, and whose main goal is to be portable. So I'll write proper test to the new map (which I'll tend not to do if it's just an m4 file in another big project), will state exactly the requirements. I'll have a real class with a solid interface (the .h file is the same on all platforms), and only the implementation will contain the ifdef's, so that I'll never use a method which is not availible on all platforms by mistake, etc. etc. So yes, I'd rather have 7 different portability layers, which are good, then 7 different portability layers which are coupled to my project, are ad-hoc, under-tested and under-documented. As a side note it sounds weird that your app need 7 portability layer, since if something is really usefull, there probably is a portability layer someone else has written. On Wed, Jan 12, 2011 at 11:38 PM, Nadav Har'El n...@math.technion.ac.ilwrote: On Wed, Jan 12, 2011, Elazar Leibovich wrote about Re: Die GNU autotools: 3) Have a project in a separate directory which implements an efficient map in a siusing existing map implementation. For this project, it makes sense to use autotools. But this project will provide a solid testable interface (ie .hpp file) for this map. So basically, you're proposing that one big project with a complex autoconf setup is split into many different subprojects (libraries), each with its own autoconf setup? This suggestion may be valid in certain cases, but you're still ending up using autoconf - perhaps even more of it... At the end, some piece of code needs to check, at build time, whether the system's compiler and libraries already include a map implementation, or they don't. Autoconf (and its heirs to the throne, mentioned by others on this thread) does this pretty well. This way, my main project have a straightforward build system, and the portability layer is isolated from the project, testable and more portable (what if we'll have a platform with buggy std::map implementation we can't use? In case of (3) we can easily borrow one, and change the portability layer only. What would the ng-fakeroot project do for such a system?). What do you do if you have a realtively small project (not something like OpenOffice) and you find yourself with 7 different portability layers for all sorts of small features like this - do you really prefer having 7 different libraries, 7 build systems, 7 different separate projects, and so on, compared to what Shachar described - simple #ifdefs that solve the problem? What about the case of inotify/Linux fragmented audio system, etc, etc.? Again, the autosuite won't save the day here. If I want to write a portable program which uses inotify (which is kind of oxymoron, as inotify is a Linux specific API), what I really want is to program to a layer of abstraction above inotify, which is portable to as many system as possible. If I don't You're basically saying the same thing I am, but reaching a different conclusion. Indeed, a portable program can't rely on inotify because that is only available on Linux, and only certain versions thereof. When inotify is not
new SI1452 keyboard layout
Hi Long ago there was a thread on the ivrix-discuss mailing list with the title SI1452 insanity[1]. I've been a long time proponent of the lyx variant of the Israely X11 keyboard layout rather than the standard one (Standard of Israel no. 1452). Luckily in thr last year there has been some work to revise this standard. There is an initial draft: http://www.lingnu.com/he/howto/78-si1452.html And indeed there are comments: http://blog.shemesh.biz/2010/12/%D7%98%D7%99%D7%95%D7%98%D7%90-%D7%A8%D7%90%D7%A9%D7%95%D7%A0%D7%94-%D7%9C%D7%AA%D7%A7%D7%9F-%D7%9E%D7%A7%D7%9C%D7%93%D7%AA-%D7%A2%D7%91%D7%A8%D7%99%D7%AA-%D7%9E%D7%97%D7%95%D7%93%D7%A9/ I tried this. I must say it is sane and usable. I'm quite happy with it. But something is missing. the Hebrew hiphen: '־' (as opposed to '-'). There were quite a few comments in the links above about stuff that is missing, but I suppose there's no use talking about it. You have to try it. So I set up a small git repo with the xkb mapping and put my changes in a branch: http://gitorious.org/si1452-xkb/si1452-xkb/commits/tzafrir There's also a small script there to extract the interesting mappings in a more readable way: si1452-xkb(tzafrir)$ ./keys 9: LEFT-TO-RIGHT MARK 0: RIGHT-TO-LEFT MARK minus: HEBREW HIPHEN slash: HEBREW POINT SIN DOT apostrophe: HEBREW POINT SHIN DOT hebrew_qoph: HEBREW POINT QAMATS, HEBREW POINT QAMATS QATAN hebrew_resh: HEBREW POINT HATAF QAMATS hebrew_waw: HEBREW POINT HOLAM hebrew_pe: HEBREW POINT PATAH bracketright: HEBREW POINT HATAF PATAH hebrew_shin: HEBREW POINT SHEVA hebrew_dalet: HEBREW POINT DAGESH OR MAPIQ (or shuruq) hebrew_het: HEBREW POINT HIRIQ hebrew_samech: HEBREW POINT SEGOL hebrew_bet: HEBREW POINT HATAF SEGOL hebrew_nun: HEBREW POINT NUN HAFUKHA hebrew_zade: HEBREW POINT TSERE hebrew_finalzade: HEBREW POINT QUBUTS Can you improve that output? [1] Any idea where I can find the archives of this list on-line? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
JOBSEEK- Adopt a Programmer
Do you have room in your software company to adopt a good programmer? We found this hacker wandering around without tags in large enterprise company. He had been abused for some time but is still able to produce code, and quite lovable. He was apparently raised in startups, Where he had 15 years experience and programed in 20+ languages, with current expertise in Unix, C, MySQL, MongoDB, PHP, Perl and Javascript. He also has recent expertise in .Net, but is quite shy about it. He's a coder who can bring lots of joy to a good startup. He is about medium size, a dark brown coat, and has glowing references from his current (enterprise) employer as well as the Weissman Institute. So if you have a startup, and have room for a really adorable hacker please consider adopting him. Reply to this email address. PS. The programmer is not normally in the habit of referring to himself in the third person. He just thinks this is funny. His sense of humor is probably his biggest problem. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Die GNU autotools
On Thu, Jan 13, 2011 at 1:05 AM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: But it's a system (or user-installed) library. Why would I need to bundle it with my code? You just hit the nail on its head! Few years ago, you were correct, harddisks were thin, memory was spare, and if you could use a preinstalled library it'll be a great benefit. Nowadays, developer time is expensive, QA time is expensive, support time is expensive. Memory is cheap, CPU is cheap, disk space is cheap. So I'd rather include another Megabyte of library the user already have, than make building and supporting my software more complicated=more expensive. As mentioned, Mathworks would rather include a compatible JVM with matlab, then use the one availible on the computer. The cost of that is miniscule (another 20Mb on the disk, maybe a bit more memory, assuming the user is using another JVM software simultaneously), and even if the only thing it'll save you is the support call it says JRE 1.2 is not supported, please upgrade. How do I do that?, it probably well worth it, not to mention the reduced cost of testing, the freedom of using more advanced API, etc etc. This is not always true, but I think that nowadays adding a library of 100Kb to almost any software, *always* costs less than maintaining it with ifdefs. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Die GNU autotools
On Thu, Jan 13, 2011, Elazar Leibovich wrote about Re: Die GNU autotools: Few years ago, you were correct, harddisks were thin, memory was spare, and if you could use a preinstalled library it'll be a great benefit. Nowadays, developer time is expensive, QA time is expensive, support time is expensive. Memory is cheap, CPU is cheap, disk space is cheap. So I'd rather include another Megabyte of library the user already have, than make building and supporting my software more complicated=more expensive. I think we were talking about free software. With free software, developer time is cheap (in the sense that if you don't do something, someone else with more free time or more dedication, can), while user resources are expensive (in the sense that if program Y uses half the memory of X and does the same thing, I'll just switch to Y without looking back). As mentioned, Mathworks would rather include a compatible JVM with matlab, then use the one availible on the computer. The cost of that is miniscule (another 20Mb on the disk, maybe a bit more memory, assuming the user is This kind of corporate thinking doesn't fly with free software. Can you imagine a Linux distribution like Fedora or Ubuntu coming with a dozen copies of the JVM, just because the devlopers wouldn't bother themselves to use the system's on copy of JVM? And you know what, I once used a commercial instant-messaging client which, like you described, came with its own copy of a JVM. When I realized it was taking 100 MB of memory, and (at the time) I had only 512 MB, I simply dumped it and replaced it with pidgin, which took 1/10th the amount of memory. This is not always true, but I think that nowadays adding a library of 100Kb to almost any software, *always* costs less than maintaining it with ifdefs. Not to the users. -- Nadav Har'El| Thursday, Jan 13 2011, 8 Shevat 5771 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Tact: The ability to describe others as http://nadav.harel.org.il |they see themselves. - Abraham Lincoln ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
OT: Re: JOBSEEK- Adopt a Programmer
On Jan 13, 2011, at 1:16 PM, Justin wrote: Do you have room in your software company to adopt a good programmer? We found this hacker wandering around without tags in large enterprise company. He had been abused for some time but is still able to produce code, and quite lovable. .. I'm posting this to the list so that anyone else who reads it in the future will see it. IMHO you made a big mistake in posting under the same name you use for your comments on mailing lists. Some of them go back to 2002 (has gmail been around that long?) and they do not paint a picture of someone who would do well in small Israeli startup. They may have been relevant at the time or pithy, or just plain cute. Now taken together, which is probably way out of context, they don't do you justice. If you want to find a job, make sure a resume that says what you want it to say is linked to in the email, and comes up near the top when someone googles you. Plumbing problems, or a new business idea that flopped, and so on, are not going to make you attractive to a prospective employer. One email friend of mine, who spent the last 15-20 years making wise- ass comments on mailing lists and newsgroups found that they prevented him from getting a single call back when looking for a job. So he opened a new blog, dropped the old email address, blogs everyday and tweets several times a day, on various topics. If you google him now, you find that he is a good worker, smart, friendly, a nice family man and a team player. It gets him interviews and jobs. Geoff. -- Geoffrey S. Mendelson, N3OWJ/4X1GM Those who cannot remember the past are condemned to misquote it. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Die GNU autotools
I think you described correctly the root of the disagreement. I believe that any software (including free software) is written not as to implement an Aristotle's Ideal, but to be used by as many people as possible, and to be useful for them. So when I'm writing a free software, I'm trying to make it as useful as possible to most people. If most people are having 2Gb of memory on their machine they probably won't care for an extra 20Mb, so they'll be happy to have a better tested software and pay for that in 20Mb of memory of the JVM (they would only pay of course if they're running two JVM based software simultaneously, which is not so common). Of course, I won't force my user to use extra 200Mb, that could matter, but nowadays 20Mb in those settings are not such a big deal. Wasting 20 minutes of my user's time on updating his JVM is. I also want to support my users, even though I'm writing a free software. I really want it to be useful. You see free software writing as an art. The software you write must implement the ideal best software, even if it's not the most practical solution. So, for instance, you'll use an extremely complicated algorithm, which is hard to debug and maintain, even though it gives no user visible performance gain, only because it is the right thing to do. It is a plausible stance I can understand, and I understand why this stance cause you to prefer the autosuite for every project, despite its costs. And by the way, if a software is working correctly and using 10Mb, and another software does the same thing with 5Mb of memory usage, I won't switch. It really wouldn't matter for me, the difference between both is immeasurable for my computer usage patterns. But what I'm really bothered is by your claim developer time is cheap, it's FSF, somebody[*] will do that. I really don't think the situation nowadays is that we have too much working hands for free software. Especially in open source software for which you need special expertise http://zrusin.blogspot.com/2010/07/graphics-drivers.html [*] http://iml.jou.ufl.edu/projects/spring02/white/poems.htmlWhen our mother went Down to the town for the day, She said, somebody has to Clean all this away. Somebody, SOMEBODY Has to, you see. Then she picked out two Somebodies. Sally and me. http://iml.jou.ufl.edu/projects/spring02/white/poems.html On Thu, Jan 13, 2011 at 1:52 PM, Nadav Har'El n...@math.technion.ac.ilwrote: On Thu, Jan 13, 2011, Elazar Leibovich wrote about Re: Die GNU autotools: Few years ago, you were correct, harddisks were thin, memory was spare, and if you could use a preinstalled library it'll be a great benefit. Nowadays, developer time is expensive, QA time is expensive, support time is expensive. Memory is cheap, CPU is cheap, disk space is cheap. So I'd rather include another Megabyte of library the user already have, than make building and supporting my software more complicated=more expensive. I think we were talking about free software. With free software, developer time is cheap (in the sense that if you don't do something, someone else with more free time or more dedication, can), while user resources are expensive (in the sense that if program Y uses half the memory of X and does the same thing, I'll just switch to Y without looking back). As mentioned, Mathworks would rather include a compatible JVM with matlab, then use the one availible on the computer. The cost of that is miniscule (another 20Mb on the disk, maybe a bit more memory, assuming the user is This kind of corporate thinking doesn't fly with free software. Can you imagine a Linux distribution like Fedora or Ubuntu coming with a dozen copies of the JVM, just because the devlopers wouldn't bother themselves to use the system's on copy of JVM? And you know what, I once used a commercial instant-messaging client which, like you described, came with its own copy of a JVM. When I realized it was taking 100 MB of memory, and (at the time) I had only 512 MB, I simply dumped it and replaced it with pidgin, which took 1/10th the amount of memory. This is not always true, but I think that nowadays adding a library of 100Kb to almost any software, *always* costs less than maintaining it with ifdefs. Not to the users. -- Nadav Har'El| Thursday, Jan 13 2011, 8 Shevat 5771 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Tact: The ability to describe others as http://nadav.harel.org.il |they see themselves. - Abraham Lincoln ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Die GNU autotools
On Thu, Jan 13, 2011 at 10:45:45PM +0200, Elazar Leibovich wrote: I think you described correctly the root of the disagreement. I believe that any software (including free software) is written not as to implement an Aristotle's Ideal, but to be used by as many people as possible, and to be useful for them. Right. Though most of them won't build it directly. Most of those who will build it will build it through some sort of packaging system. Be it RPM, DEB, the Ports of the BSDs, or OpenEmbedded and similar embedded system builders. All of those have the concept of packages. If you bundle libfoo in package bar, and libfoo is also needed for building baz, it would be a waste of time and disk space to build it twice. Also note that if you bundle a library in your code, you tend to no longer treat the interface to it as public. It's part of your code base. You want to change the interface a bit: you go ahead and change it. You can also change the behaviour of the code to match your requirements. This is fine and dandy. But what happens when a new upstream version comes? Do you apply it? Or do you avoid changing something that works (and is already tested)? And if that upstream version fixes a hole or two? So when I'm writing a free software, I'm trying to make it as useful as possible to most people. If most people are having 2Gb of memory on their machine they probably won't care for an extra 20Mb, You're not the only one who adds just extra 20Mb. This is why they have a policy in place not to allow those. And in the process they manage to shave off some extra 100MB. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries so they'll be happy to have a better tested software and pay for that in 20Mb of memory of the JVM (they would only pay of course if they're running two JVM based software simultaneously, which is not so common). Of course, I won't force my user to use extra 200Mb, that could matter, but nowadays 20Mb in those settings are not such a big deal. Wasting 20 minutes of my user's time on updating his JVM is. I also want to support my users, even though I'm writing a free software. I really want it to be useful. But I as a packager want to work a bit harder so that my users would have an optimal build process. After I did that extra work, I send my patches to you (please add an option to use the system copy of libfoo). You don't have to accept it. But if you don't, my fellow packager will copy that patch from me directly rather than from you. And then you end up with a large portion of your userbase build off a different code base than your upstream code. Which is not what you wanted. You see free software writing as an art. The software you write must implement the ideal best software, even if it's not the most practical solution. So, for instance, you'll use an extremely complicated algorithm, which is hard to debug and maintain, even though it gives no user visible performance gain, only because it is the right thing to do. It is a plausible stance I can understand, and I understand why this stance cause you to prefer the autosuite for every project, despite its costs. But much of this can be distributed. If you want to take all of it to yourself: go ahead. But I suggest you don't make the work of potential packagers, who may take some load off your shoulders, more difficult. And by the way, if a software is working correctly and using 10Mb, and another software does the same thing with 5Mb of memory usage, I won't switch. It really wouldn't matter for me, the difference between both is immeasurable for my computer usage patterns. Many people now complain that the live version of Debian does no longer fit into a single CD. It seems that an extra MB here and there does matter. There are many fields where memory usage matters: 1. embedded devices 2. virtualization: the less memory (and other resources) you use, the more guests you can put on the server. But hey, who cares about those fields? -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
