-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 George Makrydakis wrote: > First of all, Joe Sixpack is David's term.
Yeah, I know that... > Second, I did not use Windows before Linux :) I'm not talking about you. I'm talking about the people that you seem to want to use your program - -- the ones that are running Windows; the Joe Sixpacks that David was also referring to after you said it could run there. I don't think it'd be a good idea to focus on that skill level. > In anycase, I only made a comment about cross-platform. And (specifically) that it could run on Windows. But what does running it on a Windows box actually gain us, that presenting it online wouldn't? > Qt is cross - platform and does not have cygwin patches. And Qt is not in the (LFS) book, either. Try compiling coreutils or glibc on Windows sometime. It's not going to happen without a lot of effort (some of which may have already been done, but I doubt it); the user would be better off simply installing Linux instead of trying to run some kind of program that will build a Linux system from sources on Windows. (And that's even after the comments above about it not being a good idea to target the skill level of Windows users.) > but there are many other libraries that do not require "cygwin" to > work. Actually, that's not what I meant. I meant that when Cygwin compiles the same packages that we compile, they have to apply lots of patches to get them to build in a sort-of-Linux-like system. I don't want to take on that extra maintenance overhead. > I am only interested in providing automation for the "author" of the > book to use. To accomplish what, exactly? What are you automating? (But that's not what I understood you to say earlier, either. Maybe that's because I came in late.) > If the scripts are not generated from the "book", whatever its form > may be, then you do not need automation, or anything else for that > matter and you do things manually, writing for example your own spec > files for rpm, making the debs and so on. (Again with the scripts.) But the rest is true. OTOH, we're not talking package management at the moment (at least, I didn't think so). I thought we were talking about modularizing the book. >> But since we'd (well: I'd) rather not artificially limit who can >> read the book and possibly learn something, as long as we don't >> have to also specifically cater to them, it makes the most sense to >> let them read it from any OS, browser, etc. > > XHTML is a form of XML. Transformations in various formats are > everyday business, everywhere. Um, irrelevant, I think? I should have combined those two paragraphs, I bet -- the one you quoted was supposed to lead into the next thing I said (in the parenthetical below). >> (This is where presenting it over the web is such a HUGE win over >> running a full program on the client.) > > And who excluded web? It was effectively excluded when you started talking about C++. The fact that you can use some form of C++ code as an Apache module is fine, but it's WAAAY simpler to just write a PHP script. (Or a Python script. Or whatever language that lets me code at ten times the speed.) Then you don't have to worry about crashing the server, either. (Running a C++ program as a CGI script is asking for it as well, what with C++'s memory management, etc. One bug and the web server process is owned.) >> Why the apparent fixation on C++ for this? Please be specific if >> and when you explain: be sure to include exactly why you weren't >> able to get PHP (or "any script-type language", as you said) to >> work. > > I did not say that I did not "get" PHP to work. I said that it would > have been a bad option. OK -- so please explain WHY. Maybe you did, below; I'll respond to that stuff there. > You cannot possibly compare PHP to languages like C++ though. For > obvious reasons :) It has been my experience that almost everyone that claims "obvious reasons" really hasn't used one of the alternatives. It sounds like you have used them -- but in case I haven't made myself ABSOLUTELY clear so far, it's not obvious to me why I can't make that comparison. (I do, every time I write a program. And I don't believe I've chosen C or C++ in the last five years, except in cases where it's required by the environment.) What is obvious to me is a way of modularizing the book that would work fine in Python at least, and probably also in PHP: add a tag to each "part" (that is: each package, each set of instructions, etc.) that documents which module(s) it's a part of. Then when a set of modules is requested, go through that set, using xpath (or whatever) to grab the set of "parts" required for each module. That chunk of code would probably only be a few hundred lines of Python (at most), using xml.etree.ElementTree and its functions. Then shell out to something else to generate [X]HTML; possibly the tools we use today, possibly not. Bingo: modular book. Now, it's true that this doesn't handle package management (which would be another whole can of worms anyway), or alternative formats (but [X]HTML isn't that bad). But it's a very solid basis. > Do not forget that they anyway depend on "bindings" written in > something else to work anyway. But when I (as a programmer) can write code 10 times faster in Python than I can in C (or C++), why should I use C just because Python uses C bindings to interface with other stuff? (And no, C++ isn't that much faster to write code in than C. Both are dwarfed by Python.) I could see, possibly, arguing that we should use C because more people know it. But I bet that the knowledge of other languages is fairly close around here, and the huge development-time advantage is likely worth it. > Do not imply that somebody does not get "scripting" to work if he > sees no use for it. I was under the impression that you were speaking from experience when you said scripting languages weren't going to work. Apparently you were saying something even less strong (in a logical sense) than that: that you had dismissed Python/PHP/whatever (all of them) out of hand. (Is this an example of Paul Graham's Blub paradox? [1] I can't tell for sure, but that's what it feels like.) [1] http://www.paulgraham.com/avg.html -- search it for "blub". >> But I do remember you said something vague about PHP not being able >> to handle XML databases, or something like that. > > I only said that PHP would not be a highly scalable solution (and not > even an option for what users like me require), and at some point, > for something like this, you would have to do a rewrite, exactly > because you used PHP. I don't remember reading that, exactly. But it doesn't matter -- you still haven't been specific. You've asserted (again) that "it won't be scalable", but not actually said *WHY*. What's so much better about C++, when you're writing what I outlined above? OTOH, if what I outlined above won't work, why not -- what limit will we run into? > XML databases are this: http://en.wikipedia.org/wiki/XML_database. The link is helpful in defining what they are; thank you. But I'm still not convinced that anything like that will be required here, except to the extent that the current DocBook is already an "XML database". > They are well known in the Industry. I cannot explain further until > you have your own idea on exactly what this is. Ah, throwing in an Appeal to Popularity logical fallacy, I see. Just because XML databases are "well known" doesn't mean they're good for this particular use (or, in fact, any other), or that they're required for anything. I think I've shown above that they aren't required to do this task quickly. > As I have said, I have my own project to implement around this, so I > am not trying to neither "convince" or make anyone use my proposal. > You can use whatever you want because there are always alternatives. Obviously you've decided to use C++ -- I'm trying to figure out exactly why. I don't think any of the reasons you've written so far actually hold a whole lot of water. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHy2qbS5vET1Wea5wRA7WGAJ4iTOodydwTxcPCQeiOFdeqnHry5wCgp3Sn m1v5nQImjyVZQFTTj92e1eU= =/G0n -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
