On Monday 03 March 2008 20:57:48 Bryan Kadzban wrote: > 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? >
AGAIN: i do not _care_ to actually make it _run_ on windows. It is just a side effect of the way it is programmed. Non - system call related code compiles with a standard compliant C++ compiler since it is standard C++; a standard - compliant C++ compiler compiles standard - compliant C++. I don't need system calls to have the build system running. Is it now clear? > > > > 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. AGAIN: i do not _care_ to actually make it _run_ on windows. It is just a side effect of the way it is programmed. Non - system call related code compiles with a standard compliant C++ compiler since it is standard C++; a standard - compliant C++ compiler compiles standard - compliant C++. I don't need system calls to have the build system running. Is it now clear? --------------------------------------------- I also did NOT say EVER that i was providing a tool for building LFS from windows. I only said that the tool could eventually run on windows. The two things are _not_ the same. ---------------------------------------------- > > > > 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. NOTE: I did not say that you should build glibc or any book program, linux program, solaris program whatever it is that you on WINDOWS, let's go over it again: The tool, could be made to run on any platform that has a standard - compliant C++ compiler. The fact that the tool could run on it without any cygwin etc, is simply a side effect of how it is programmed. It does not mean in anycase that it builds LFS on windows. Can you see the difference now? > 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.) I _HAVE_ my own parsers. > 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. Read up, i _don't_ want to do that. Let's go over it again: The tool, could be made to run on any platform that has a standard - compliant C++ compiler. The fact that the tool could run on it without any cygwin etc, is simply a side effect of how it is programmed. It does not mean in anycase that it builds LFS on windows. Can you see the difference now? > (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. What is .spec for RPM? that, is a format. > (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. I really do not know WHY you are not getting this. Use what language you want. Do what you want, you have not seen the system yet; eventually you will require a rewrite as you require now and dumping jhalfs work. Why? Because you focus on the wrong issues. It is your problem, not mine. > > > >> 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. No, you crash your own server by unplugging the cord. Are we again missing points? Yes we are. Everything can crash your server. Why do you use git, mercurial, svn etc? Are there no "C" parts in them or it is python only... Come on. You are not seeing the issue. > (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. Listen, you do not see this. You clearly fail to see this. Do you want to make up your mind and read things as you should? Thanks. > > > > 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. Listen, do your own thing; fail in your own way. You clearly fail to see the points, both performance and implementation wise. > Unless you EXPLAIN YOURSELF, that is. I did, you just don't want to see this and you are interpreting it the way you want it. You are comparing PHP to C++ and that is inappropriate for the task at hand. > > 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. You are still not seeing this. Enjoy. > > > > 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. You are not seeing this, go compare the performance of PHP and python to C++. > (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.) Yes, and you are providing evidence of being clueless right now. I would appreciate it if you just sit down and wait for it to come. In the meanwhile, there are many fine books that teach why these things are valid. BAD DESIGN = REWRITE BAD LANGUAGE = SHORT TERM SUCCESS, LONG TERM FAILURE > > > > 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). Come on, you are already using XML. What is the book written in? > > 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. Yes right. You are definitely not seeing this. Don't waste your time replying anymore, because you just don't get it. You are either put here to make me waste time replying to you deliberately, or you really need to read again everything and think about it. Pick your option. Enjoy. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
