On Sunday 02 March 2008 21:33:42 Bryan Kadzban wrote: > I think it's a really bad idea for us to specifically try to teach > anything to Joe Sixpack that's never even used Linux. Note I'm not > saying that everyone who uses LFS had used Linux before they started -- > but those that didn't are most definitely *NOT* Joe Sixpack. They had > an understanding of how computers worked, at least, and probably an > understanding of some of the tasks of an operating system. (Heck, they > at minimum knew what operating system they were running: it was not "MS > Office 98" (or whatever), as so many users used to say.)
First of all, Joe Sixpack is David's term. Second, I did not use Windows before Linux :) > Anyway, it's a bad idea because our talents (IMO anyway) could be of > much greater use somewhere else: teaching people that *do* already have > some experience. > > (I don't say we should explicitly exclude Windows users, by the way. > But I do say we shouldn't focus on them, either: I don't believe they > should be the target demographic.) The comment about windows "users" includes other things that do not have to do with "users" but much different user profiles. The people who would be interested in something like this, would hardly be "users" anyway. In anycase, I only made a comment about cross-platform. > > Since when it was impossible to compile cross - platform compatible > > code? > > How much of the code that we compile is actually cross-platform > compatible? How many patches does Cygwin have to apply when they're > building stuff for their environment, which actually appears to act like > *nix? How much worse would it be when the normal directory structure > doesn't even exist? Qt is cross - platform and does not have cygwin patches. First example that comes to mind but there are many other libraries that do not require "cygwin" to work. The fact that some system calls are different, can be overcome with the proper indirection, which if done right, bears no overhead to the end user of a library. > [snip] > > If you were able to create the scripts through a web interface you > > would be cross platform again, for example. > > Maybe I'm missing the boat here, but I don't think anyone was talking > about generating scripts. I think people were talking about showing a > reader whatever modules the reader requested, via the web. I am only interested in providing automation for the "author" of the book to use. Powerfull automation through a highly reusable code - basis. So I focus on that. > Note that I don't remember for sure if generating scripts was ever > requested, either. But even apart from that, the OS that the user uses > to generate the instructions (and educational text, etc., etc.) does not > have to match the OS that they build from. Since it's so much simpler > to just assume that gcc is present, and that the directory structure > makes sense, it's a ton less work to do that in the book's text. 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. Therefore you do not require even a change in the current book format. Therefore you do not even need to consider changing LFS altogether. > 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. > (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? > > Last time I checked, C++ compilers where available for Windows 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. Infact, there is not problem with using PHP, Ruby, Erlang, Eiffel, Java, Haskell, OCaml and the rest of the boys. You cannot possibly compare PHP to languages like C++ though. For obvious reasons :) I did say that "script languages" are a bit pointless but for rapid conceptual design in this matter (and at times not even that). It is my opinion. Do not forget that they anyway depend on "bindings" written in something else to work anyway. Do not imply that somebody does not get "scripting" to work if he sees no use for it. Please always stick to the authentic text. Despite that, I would like to point to the fact that doing bindings for "script languages" as you call them solves the problem for people who are less apt with more complex languages. > (I should note that I haven't read everything you've posted, mostly > because the majority of it looked like a huge mess of talking that I > didn't want to wade through at the time. 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. Please understand that it is one thing to like and get things "done" with PHP, and another appreciate it and choose it as a valid option for a more complex design. That does not mean though that you cannot do everything PHP oriented for your own needs. To me, it is just not the right option. > You also made some vague comments before that > about "required" changes (at least, the ones you thought were required > -- which should also be explained) being equivalent to turning the book > into an XML database (whatever that's supposed to be). XML databases are this: http://en.wikipedia.org/wiki/XML_database. They are well known in the Industry. I cannot explain further until you have your own idea on exactly what this is. > All of this > stuff was simply asserted, with no reasons or examples or anything given > behind it. Anyway, if you need to point me to somewhere that you've > already explained it, feel free.) For the time being you can peek around here, you know where my project is to be hosted in anycase, through this thread. > Generally, "trust me, X doesn't work for Y" isn't a good way to stop > someone from using X. Explaining exactly why X didn't work when you > tried to do Y (the specific limits you ran into, etc.), on the other > hand, is much better. At minimum, that way the other person will see > places that you had issues, and can perhaps figure out another way > around them. Proper programming does not have any limits in implementation. But you cannot use but the right tool for the right job. 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. Enjoy, thanks, George -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
