On Monday 03 March 2008 05:03:56 Bryan Kadzban wrote: > 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 do know that, but I also wanted to make it clear
> 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. Cross platform code runs everywhere. > > In anycase, I only made a comment about cross-platform. > > And (specifically) that it could run on Windows. Cross platform code runs everywhere. > > 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. You are missing the point, perhaps because it was not made clear enough; I only said that there are cross - platform applications that do not need cygwin. Please think about it. Hello world programs are not in the LFS book either. Not for once did I imply that i would like to add the framework into the LFS book. > (And that's even after the comments above about it not being a good idea > to target the skill level of Windows users.) Yes, people who know how to administer ADFS, system administrators etc are definitely off the list then. I am targeting people with IT experience. And those who want to have something that works for them. > > 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. There is no maintenance overhead when you stick to the standard implementation of a language. There is no need of cygwin. There is no need of anything but a standard compiler. I do not know what makes this so difficult to understand. There is NO MAINTENANCE OVERHEAD but the minimal abstraction wrapped around for example the missing POSIX - incompliance of the MS platform if we refer to specific system APIs and ABIs, where that is necessary (for the time being no reason to do that). Anyway, it was just a suggestion. You will just have to wait, again. > > 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.) Building your own distro, doing your own book, with ease in all the phases of its development cycle. To my knowledge, there is only a multidependency, full of hardcoding way of doing the build automation right _now_, that weakens the development cycle, not to mention its debug/maintenance cycle as well after deployment or shipping to testers. This is a far more devious overhead that can lead to long term unavoidable stagnation, critical also when one of the developers concetrated on one aspect of the system leaves. If he leaves then bye bye, you stick around and do the work while trying to find someone else if you do not have the necessary knowledge. In anycase, I think you understand a bit better now. > > 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.) Don't get it wrong, it is simply that this is obviously a place with enough static to make self - evident things impossible to understand. you will just have to wait then. All package managers actually wrap build scripts for their most basic part: the file format (example). > 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. Modularizing the book, without taking into account that a good design has to be extensible in situ, will lead to a rewrite. And the same discussion will > >> 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). That XHTML is XML is irrelevant? > >> (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. You write your own PHP script. I will just offer the binding, apache module, you name it <here> that will make the same PHP script be shorter, more maintainable and faster than the PHP solution. Not to mention all the rest. As I said, if you like PHP fine. But don't see everythign under that spectrum. > (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.) CGIs and apache modules are different things. You perhaps do not know the things that can be done in C++ memory management wise. It all depends on the programmer and how thorough his work is. I already talked about this in earlier posts in here as well. > >> 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. It is pointless to use PHP for this one. Not that you cannot do it. You can even use javascript to do what you want. You can even use bash _alone_ to do what you want. Then, at some point, you will hit the wall with them. Better have a core that can provide bindings to "simpler" things than have a core that can't. > > 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.) Write your own operating system in PHP then. PHP cannot be compared to C++. This is not a pun, it is a fact. It does not mean that you cannot do "some" of the things in PHP, it means that you just cannot take a small boat to cross the ocean during hurricane season. > 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. Python would be a far better choice than PHP. See where it got portage to though. Unmaintainability. That is not python's fault but anyway. Still, with python relying on a set of bindings or _a_ binding to a more adept core, there is still the performance and flexibility advantage, while people who like python can use python without having problems. Look how mercurial is coded. Python, with some critical parts in C. And What is Python written in? > Then shell out to something else to generate [X]HTML; possibly the tools > we use today, possibly not. Bingo: modular book. I always said that what the book should die as it is. I have also talked about book modularity using the term "multiple streams" of the book that get specialized for the end user. Conceptually it is the same if not better. The word module leads to the word: dependency management. The word stream leads to the word: lazy evaluation (the word lazy has a programming meaning here). Eventually I will explain why the two are different but it is not the case here. > 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. XML. XHTML is just a simply transformation from an original XML database output in order to make things readable on a browser, for example, as you want. Again, a big discussion. > > 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.) Having bindings for Python from another more cohere set makes your 10 lines faster. Because 10 lines is only what you need. C++ is faster to write code in if you have the right library. It is the ultimate do-it-yourself language and you have to have the library you need in order to work with it faster. That is why you spend time doing it. THat is what I am doing. > 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. People can use C for all they want. Writing a simple program in C uses 90% of the features of the language. Writing the same in C++ uses 10% of these features if not less and its power shines when you do not use it as a C superset. > > 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. Actually, i studied what I wanted to accomplish and the possibilities extending it. C++ was the logical choice, even after i started doing comparisons say with Haskell in this matter. I did not exclude them out of hand because i did not like them. I excluded python/php/whatever because this particular language type did not serve well to my design. > (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". http://www.research.att.com/~bs/bs_faq.html http://www.research.att.com/~bs/bs_faq2.html > >> 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? I am specific: PHP is not a well thought out choice. Would python be a better one since you so like it? yes. Long term? not if you need to scale. > > 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". It is, and a badly implemented one right now. This is why you end up ditching the design after all. > > 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. Nope, I am not making a pun, because i do not make part of the LFS humor base: you have to have your own ideas first on the matter since you said ("whatever that is supposed to be') for XML databases, implying that you did not, else it would be neither nice or fruitful for both of us to continue bashing over it. > 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. No. Only that XML is a human readable format easy to fix and work with in a variety of ways. All my design is not to be exhausted in this list though. It is an export/import safe mechanism for handling data. Even between non XML "Databases" in their strictest term possible. > > 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. You are comparing PHP to C++. Does that hold water? Ask yourself if it does. Depending on your problem, it "may". But then so can <language X> to language <Y>. Check Stroustrup's links on language comparison. I have nothing else to say on the matter. Anyway, I am about to drop this list, I am spending too much time trying to swim while I can take the speedboat, for many many reason. Please use what you wish for your own implementation of the same process. But just do not compare C++ to PHP :). They cannot be compared. For what it matters your concerns hold up as valid points for the fact that they offer a better chance to explain. So for this... Thank you for the interest. George -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
