On Mon, Mar 03, 2008 at 04:07:38PM +0200, George Makrydakis wrote: > Cross platform code runs everywhere.
Um, yeah (at least in theory), but does that actually help? See the question below that you didn't answer: > > But what does running it on a Windows box actually gain us, that > > presenting it online wouldn't? Still would be nice to get an answer to that... > > 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. Yes, that is what you said, but you said it in the context of attempting to run some program to build an LFS system from Windows. (Or at least, that's what I understood.) My original response was not to what you said, but to both what you said and its context. > > > 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. 1) That misses the point. The point is, building glibc on Windows is impossible, as is building LFS from Windows. So unless you want us to do even more work, please stop with the cross platform stuff. 2) Even if that didn't miss the point, there is no XML parser in the C++ standard. Feel free to write your own while we use one of the three standard Python ones. (That's one of the reasons Python is so much better, but it's not the only one either.) 3) Even if you had an XML parser, you would not be able to build glibc on Windows unless WE (that is, the LFS people) started maintaining a HUGE number of patches to allow it. No glibc, no Linux system: no LFS. (Yes, maintenance is required: every time glibc releases a new version, we need to update the patches. Just like the patches we maintain today.) > > (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). No, "all" package managers do not. See the package user hint: scripts are not required, and there is no "file format" at all. (But again, you're conflating package management with modularization.) > Modularizing the book, without taking into account that a good design has to > be extensible in situ, will lead to a rewrite. I doubt it. Anytime someone says "X will require a rewrite", without providing details on WHY, I doubt it. > > >> 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? It's irrelevant to what I was saying, yes. I wasn't saying "we should let users read from any OS/browser/whatever" on its own. I was saying it, leading into the parenthetical below about *HTML being better. The fact that it's also XML is pretty much useless at that point. > > 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> OK, so now $random_extra_code can crash our web server? Whee. (Yes, I'm opposed to using Apache's built-in php_module as well, for the same reason. Running code inside the web server is problematic when that code crashes, or when that code doesn't handle input properly, or whatever.) > > (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. Hence the "as well" in that sentence. I already expressed my extreme dislike of linking code into the web server; this was added (as a parenthetical) to preempt any possible suggestion to "run it as a CGI then". C++ as a CGI is almost as bad as C++ inside the web server. > > > 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. > <blah blah> Since I've given you MULTIPLE chances to explain EXACTLY WHY you don't think it's a good idea, and you continue to fall back on assertions without explanation, I'm going to start ignoring your future posts, starting right now. Unless you EXPLAIN YOURSELF, that is. > 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 Yep, it's the Blub paradox. Linking to Bjarne Stroustrup's FAQ is just evidence of 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. More assertions, with no evidence or explanation. (HINT: If you say "it won't work", you're making an assertion. If you say "when you try to do X, you run into Y", you're providing evidence.) > > > 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 You're right -- you're not. What you are doing is making a logical fallacy. Your conclusion (that we should use an XML database) does not follow from your evidence (that "the Industry" uses them a lot). > But just do not compare C++ to PHP :). They cannot be compared. Every time I choose which language to write a program in, I am making lots and lots of comparisons. They therefore obviously CAN be compared.
pgpnXANfjmy0v.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
