Date: Tue, 28 Jun 2005 00:05:20 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 570 ************************************************** Monday 27 June 2005 Number 570 ************************************************** Subjects for today 1 Re: Warpstock 2005 : billn 2 Re: Warpstock 2005 : billn 3 Re: Warpstock 2005 : billn 4 Re: Warpstock 2005 : lgrosenthal at 2rosenthals.com 5 The OS/2 and eCS Ecosystem : billn 6 Re: Warpstock 2005 : Neil Waldhauer" 7 Re: Warpstock 2005 : Yuri Dario" 8 Re: Warpstock 2005 : John Poltorak 9 Re: The OS/2 and eCS Ecosystem : Stefan.Neis at t-online.de 10 Re: The OS/2 and eCS Ecosystem : Lewis G Rosenthal 11 Re: The OS/2 and eCS Ecosystem : billn 12 Re: The OS/2 and eCS Ecosystem : Andy Willis 13 Re: The OS/2 and eCS Ecosystem : Stefan.Neis at t-online.de 14 Re: The OS/2 and eCS Ecosystem : Dave Yeo" 15 Re: The OS/2 and eCS Ecosystem : mikus at bga.com (Mikus Grinbergs) 16 Re: Warpstock 2005 : Steven Levine" 17 Re: Warpstock 2005 : Steven Levine" 18 Re: Warpstock 2005 : Steven Levine" 19 Re: Warpstock 2005 : John Poltorak 20 Re: The OS/2 and eCS Ecosystem : Stefan.Neis at t-online.de **= Email 1 ==========================** Date: Sun, 26 Jun 2005 07:07:51 -0700 From: billn Subject: Re: Warpstock 2005 The issues Steve raises are somewhat complex. What he says is true, yet incomplete. I once held a toolmaker position like Steve's. By building tools for the rest of the company, I made the other 20 programmers more productive. All I had to do each year was make each of them 5% more productive and I could justify my cost. In fact I usually did much better. Steve's response reminds me of some programmers I worked with in the 60s and 70s. When the users complained the software was hard to use, they said, half joking, "If it was hard to write, it should be hard to use." I hear echos of that in Steve's responses. But it is not correct to say that Steve is wrong. Within his workspace, greater knowledge leads to better productivity and better results. Where he is incomplete is that he does not consider the end use of the tools he builds. In order to understand why I want a simple installation of a development environment, we need to look at what I do. Steve develops compilers (among other things) which I use as a tool. When I go to Home Depot to buy a power saw, I don't want a kit to put together. Yes, I would know more, but that is not my objective. I want to cut some wood. This is a user view of a tool, not a developer view. Similarly, I view a development environment as a tool for my job, which is developing applications. Yet, my development is someone else's tool, a person who uses the application to build a database (for instance). The user who builds the database is another level of tool builder for the manager who needs that data, and so on up the chain - one level's tool builder creates the next level's user function. Getting back to Steve's original premise, that learning to install a complex tool makes using it more effective, is only valid at that level of tool builder. For me, as a tool *user*, anything that takes away from my productivity in building applications is a cost, not a benefit. An operating system is a tool for compiler writers, who make tools for applications developers, and so on. How you view a tool depends on what your objective is. Each level looks at a lower level item as a user tool, and develops a user tool for the next level. I've worked at every level in the tool chain, including OS development. What Steve does is essential for those of us who work on applications. What is not essential is that I know all of the details that Steve does, because that time spent would reduce my productivity. All of this leads to my next message, which explains the reason I posted the first message. The next message I post will discuss the OS/2 and eCS ecosystem. BillN Steven Levine wrote: > > In <42BE094D.4070007 at 2rosenthals.com>, on 06/25/05 > at 09:47 PM, Lewis G Rosenthal said: > > >the server, I just need to enter the venue details in the captive portal > >page. Plug the AP into the broadband, it finds the jabber server on the > >far side (my server), logs in, and the hotspot is up and running. No > >muss, no fuss. > > I see and the jabber server just magically appeared and you picked the > Hautspot equipment first try with no R&D effort on your part. Let's see > and you've never had to stare at one of these setups wondering why it > chose not to work at some particular moment. > > >True, but again, that doesn't mean that it should be more complex. I > >agree with you: setting up a build system IS tedious. I just believe > >that we should strive toward making it less so. > > The only way that will happen is if those that find it complex make > concrete contributions to the process of making it easier for others like > them. > > >However, if I could spend less time getting > >the ! at #$ing build environment set up and working, I could spend more > >time actually BUILDing with it. > > It would be nice if this could just happen magically, but it won't. > > >*I* have the need. So, the need may not be there for you, my friend, but > >it is for me. :-) > > My work environment is what it is because I've made the effort to make it > so not because I complained about the facts of life. > > Regards, > > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- **= Email 2 ==========================** Date: Sun, 26 Jun 2005 07:07:51 -0700 From: billn Subject: Re: Warpstock 2005 The issues Steve raises are somewhat complex. What he says is true, yet incomplete. I once held a toolmaker position like Steve's. By building tools for the rest of the company, I made the other 20 programmers more productive. All I had to do each year was make each of them 5% more productive and I could justify my cost. In fact I usually did much better. Steve's response reminds me of some programmers I worked with in the 60s and 70s. When the users complained the software was hard to use, they said, half joking, "If it was hard to write, it should be hard to use." I hear echos of that in Steve's responses. But it is not correct to say that Steve is wrong. Within his workspace, greater knowledge leads to better productivity and better results. Where he is incomplete is that he does not consider the end use of the tools he builds. In order to understand why I want a simple installation of a development environment, we need to look at what I do. Steve develops compilers (among other things) which I use as a tool. When I go to Home Depot to buy a power saw, I don't want a kit to put together. Yes, I would know more, but that is not my objective. I want to cut some wood. This is a user view of a tool, not a developer view. Similarly, I view a development environment as a tool for my job, which is developing applications. Yet, my development is someone else's tool, a person who uses the application to build a database (for instance). The user who builds the database is another level of tool builder for the manager who needs that data, and so on up the chain - one level's tool builder creates the next level's user function. Getting back to Steve's original premise, that learning to install a complex tool makes using it more effective, is only valid at that level of tool builder. For me, as a tool *user*, anything that takes away from my productivity in building applications is a cost, not a benefit. An operating system is a tool for compiler writers, who make tools for applications developers, and so on. How you view a tool depends on what your objective is. Each level looks at a lower level item as a user tool, and develops a user tool for the next level. I've worked at every level in the tool chain, including OS development. What Steve does is essential for those of us who work on applications. What is not essential is that I know all of the details that Steve does, because that time spent would reduce my productivity. All of this leads to my next message, which explains the reason I posted the first message. The next message I post will discuss the OS/2 and eCS ecosystem. BillN Steven Levine wrote: > > In <42BE094D.4070007 at 2rosenthals.com>, on 06/25/05 > at 09:47 PM, Lewis G Rosenthal said: > > >the server, I just need to enter the venue details in the captive portal > >page. Plug the AP into the broadband, it finds the jabber server on the > >far side (my server), logs in, and the hotspot is up and running. No > >muss, no fuss. > > I see and the jabber server just magically appeared and you picked the > Hautspot equipment first try with no R&D effort on your part. Let's see > and you've never had to stare at one of these setups wondering why it > chose not to work at some particular moment. > > >True, but again, that doesn't mean that it should be more complex. I > >agree with you: setting up a build system IS tedious. I just believe > >that we should strive toward making it less so. > > The only way that will happen is if those that find it complex make > concrete contributions to the process of making it easier for others like > them. > > >However, if I could spend less time getting > >the ! at #$ing build environment set up and working, I could spend more > >time actually BUILDing with it. > > It would be nice if this could just happen magically, but it won't. > > >*I* have the need. So, the need may not be there for you, my friend, but > >it is for me. :-) > > My work environment is what it is because I've made the effort to make it > so not because I complained about the facts of life. > > Regards, > > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- **= Email 3 ==========================** Date: Sun, 26 Jun 2005 07:07:51 -0700 From: billn Subject: Re: Warpstock 2005 The issues Steve raises are somewhat complex. What he says is true, yet incomplete. I once held a toolmaker position like Steve's. By building tools for the rest of the company, I made the other 20 programmers more productive. All I had to do each year was make each of them 5% more productive and I could justify my cost. In fact I usually did much better. Steve's response reminds me of some programmers I worked with in the 60s and 70s. When the users complained the software was hard to use, they said, half joking, "If it was hard to write, it should be hard to use." I hear echos of that in Steve's responses. But it is not correct to say that Steve is wrong. Within his workspace, greater knowledge leads to better productivity and better results. Where he is incomplete is that he does not consider the end use of the tools he builds. In order to understand why I want a simple installation of a development environment, we need to look at what I do. Steve develops compilers (among other things) which I use as a tool. When I go to Home Depot to buy a power saw, I don't want a kit to put together. Yes, I would know more, but that is not my objective. I want to cut some wood. This is a user view of a tool, not a developer view. Similarly, I view a development environment as a tool for my job, which is developing applications. Yet, my development is someone else's tool, a person who uses the application to build a database (for instance). The user who builds the database is another level of tool builder for the manager who needs that data, and so on up the chain - one level's tool builder creates the next level's user function. Getting back to Steve's original premise, that learning to install a complex tool makes using it more effective, is only valid at that level of tool builder. For me, as a tool *user*, anything that takes away from my productivity in building applications is a cost, not a benefit. An operating system is a tool for compiler writers, who make tools for applications developers, and so on. How you view a tool depends on what your objective is. Each level looks at a lower level item as a user tool, and develops a user tool for the next level. I've worked at every level in the tool chain, including OS development. What Steve does is essential for those of us who work on applications. What is not essential is that I know all of the details that Steve does, because that time spent would reduce my productivity. All of this leads to my next message, which explains the reason I posted the first message. The next message I post will discuss the OS/2 and eCS ecosystem. BillN Steven Levine wrote: > > In <42BE094D.4070007 at 2rosenthals.com>, on 06/25/05 > at 09:47 PM, Lewis G Rosenthal said: > > >the server, I just need to enter the venue details in the captive portal > >page. Plug the AP into the broadband, it finds the jabber server on the > >far side (my server), logs in, and the hotspot is up and running. No > >muss, no fuss. > > I see and the jabber server just magically appeared and you picked the > Hautspot equipment first try with no R&D effort on your part. Let's see > and you've never had to stare at one of these setups wondering why it > chose not to work at some particular moment. > > >True, but again, that doesn't mean that it should be more complex. I > >agree with you: setting up a build system IS tedious. I just believe > >that we should strive toward making it less so. > > The only way that will happen is if those that find it complex make > concrete contributions to the process of making it easier for others like > them. > > >However, if I could spend less time getting > >the ! at #$ing build environment set up and working, I could spend more > >time actually BUILDing with it. > > It would be nice if this could just happen magically, but it won't. > > >*I* have the need. So, the need may not be there for you, my friend, but > >it is for me. :-) > > My work environment is what it is because I've made the effort to make it > so not because I complained about the facts of life. > > Regards, > > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- **= Email 4 ==========================** Date: Sun, 26 Jun 2005 10:41:16 -0500 From: lgrosenthal at 2rosenthals.com Subject: Re: Warpstock 2005 Steve, I hope that from your perspective, we're having a discussion and not an argument... ;-) On 06/25/2005 10:12 pm, Steven Levine thus wrote : > In <42BE094D.4070007 at 2rosenthals.com>, on 06/25/05 > at 09:47 PM, Lewis G Rosenthal said: > >> the server, I just need to enter the venue details in the captive portal >> page. Plug the AP into the broadband, it finds the jabber server on the >> far side (my server), logs in, and the hotspot is up and running. No >> muss, no fuss. > > I see and the jabber server just magically appeared I installed a White Box Enterprise Linux server from two CD's onto a spare Compaq Deskpro PIII/933 system, and racked it. I purchased a license from Sputnik, Inc (www.sputnik.com) for their captive portal software, and ran a Red Carpet install on that box, following simple directions (a dozen steps?). This properly installed and configured Apache, Jabber, and Postgres, and automagically updated a few other things on the WBEL box. Total install time (after the OS) was approximately a half hour of my time, and an hour of machine time (downloads, etc.). > and you picked the > Hautspot equipment first try with no R&D effort on your part. Hautspot is my company. Sputnik took a bit of R&D effort, but I actually met with the president, Dave LaDuke in Santa Clara in 2003, just after Warpstock SF. I signed on as a beta tester, assuring me a steep discount on my first round of licenses and on my subsequent purchases (IOW, I made an investment with this company, because they were using tried and true, standard technologies, and I wanted something which would set up "out of the box" and NOT run on a Windows platform, as I wanted stability). So, yes, I did do some homework ahead of time, however, with regard to this discussion, I would equate this with comparing any group of apps which might server the same function: the time was in the comparison, not in the setup. If we had several development environments from which to choose, I don't think any of us would complain about comparing the pros and cons of each against the other(s). > Let's see > and you've never had to stare at one of these setups wondering why it > chose not to work at some particular moment. > Troubleshooting is a different issue, however, since bringing the system online in late 2003, I've only had two such incidents, and the second triggered by my own carelessness in troubleshooting the first. Last fall, my WBEL box was compromised (boy, I wish this stuff ran on OS/2...and porting would not be too much of a hassle, I don't suppose) and someone got a rootkit on in (my guess is that there was a security hole in Jabber which allowed access). Anyway, the box has been limping along for some time, waiting for me to rebuild it. I set up a temporary box alongside it, but the APs don't want to talk to it (I believe this to be a certificate issue), however, I erroneously left the temporary box up and running - and patched into the LAN with an identical IP address (ouch!!) - which caused the Cisco router in front of it to have a heck of a time directing traffic through the NAT to the correct box. Another case of a little bit of knowledge being a dangerous thing... ;-) So, anyway, to more directly answer your question, I've spent a grand total of about a day and a half in a year and a half troubleshooting the system. Like NetWare, it just works, leaving me with the time necessary to do the business of selling hotspots instead of tightening bolts. That same philosophy I see applied to what we're discussing: if there were a closer to out-of-box build environment, people with a modicum of skills could invest their time porting instead of setting up the build environment. You and I both know that there's no substitute for getting one's hands dirty when it comes to learning how something works and why. Troubleshooting, without the basic knowledge of the underlying platform, is almost an exercise in futility, as it leads to stabbing in the dark to hit upon what "might" be the cause (and you have reminded me of that fact on more than one occasion, my friend!). >> True, but again, that doesn't mean that it should be more complex. I >> agree with you: setting up a build system IS tedious. I just believe >> that we should strive toward making it less so. > > The only way that will happen is if those that find it complex make > concrete contributions to the process of making it easier for others like > them. Absolutely. Which is where John's UX2BS project comes in (as just one solution). Granted, it's scope is still somewhat limited, but it is a step closer to a unified, portable (as in installable on multiple systems) build environment. > >> However, if I could spend less time getting >> the ! at #$ing build environment set up and working, I could spend more >> time actually BUILDing with it. > > It would be nice if this could just happen magically, but it won't. > Agreed 100%. >> *I* have the need. So, the need may not be there for you, my friend, but >> it is for me. :-) > > My work environment is what it is because I've made the effort to make it > so not because I complained about the facts of life. > I'm not complaining. If this were higher on my list of priorities, I'd probably get more involved with it. However, it still would be nice (other things that would be nice are a native port of OpenOffice, less M$ OSes in my clients' offices, cooler weather in the summer, less snow in the winter - well, for those of us here in the northeast, at least! - and so on). Anyway, you haven't answered the underlying question of this thread, and that is, will you be presenting at Warpstock this year? Inquiring minds want to know!! :-) A trap troubleshooting session (as opposed to a "cr-p shooting session," that is)? Perhaps a build environment session? Apache? Oh, and you conveniently side-stepped my last inquiry regarding that AirPrime driver. You have my curiousity piqued. ;-) -- Lewis ------------------------------------ Rosenthal & Rosenthal Accountants / Consultants ------------------------------------ WebMail/2 - Powered by OS/2 **= Email 5 ==========================** Date: Sun, 26 Jun 2005 07:55:09 -0700 From: billn Subject: The OS/2 and eCS Ecosystem The majority of computer owners are users, not developers. This holds true for business and personal use. The people on this list are a small minority of the full set of OS/2 users. Yet we are a critical subset. OS/2 holds a slowly diminishing population of users in the broader context of all computer users. This is not because the OS has become obsolete even though we hear that from many people. In the broadest sense, OS/2 ecosystem is shrinking because its utility to end users is shrinking. The utility, or usefulness to end users depends on applications, something Microsoft recognized a long time ago and used bundling of applications with the OS to develop a monopoly over time. That's somewhat oversimplified, but a core issue. In reaction to this confining monopoly, Linux has attracted many OS and application developers, and many of the applications have become very powerful, more than enough for many uses, both personal and business. OS/2 has not kept pace with Linux for a number of reasons, but the critical one is the lack of current level applications. Fix that, and OS/2 becomes much more competitive. In order to expand the application portfolio for OS/2, we must have easy to install and use development environments. OS/2 offers a market where users still expect to pay for good software, unlike much of Linux. And Linux has hampered itself from the business POV because of its rapid rate of change which makes it appear unstable. Now you can get well tested Linux distros from Red Hat and Suse, but you *will* pay for them. So the overall market choices are currently MS, Linux, or for a few, OS/2 in its current form as eCS. OS/2 remains the most stable OS for PC and server class systems. All of us routinely run our OS/2 systems for months at a time, servers for years at a time, and we do not consider this unusual. The unusual is when it *doesn't* run for long periods. I can't claim that making more and current applications available for OS/2 will guarantee growth, though I think it will. However, it does offer opportunity for developers to make money and eCS to grow by having a better set of applications to sell. The kicker in all of this is getting more developers on board. In particular, if we had an easy to install development environment that would install on OS/2 *or* Linux, we could invite Linux developers to build OS/2 versions of their current applications, and have the ability to build custom applications w/o having to spend large amounts of time in the install and tuning of a development tool. I see this current requirement for specialist knowledge in order to configure the development environment as a major roadblock to broadening the OS/2 application portfolio. IMNSHO, this is a critical obstacle to stability and expansion of the OS/2 ecosystem. Therefore, the survival and growth of OS/2, not to mention employment and income from writing applicatioons, is dependent on solving this problem. This is why I originally wrote about the need for a simplified install. I realize now that it makes more sense when you understand the reasons behind the original post. BillN **= Email 6 ==========================** Date: Sun, 26 Jun 2005 08:14:55 -0700 From: "Neil Waldhauer" Subject: Re: Warpstock 2005 I think a thoughtful discussion is welcome. I agree that the toolset for porting unix applications is too difficult for some users, including myself, to put together. I liked emx because it was a lot easier, and I did a nice port in 1997 with that. On Sun, 26 Jun 2005 07:07:51 -0700, billn wrote: > I once held a toolmaker position like Steve's. Steve is a consultant, not a toolmaker. > When I go to Home Depot to buy a power saw, I don't want a kit to put > together. OS/2 is not Home Depot. OS/2 is the independent lumberyard owned by the local mill. There are a few dozen OS/2 developers left. If Home Depot was looking at our market, they'd dissolve the company and move to the Cayman Islands. We could use someone like yourself to assemble a tool chain in a nice package with all the help files. The files are all there someplace, and many people on this list have made their own collection. The help files are all there someplace. WarpIN gives you a tool that can make a nice installer in a few hours. It's a bite-sized project. It would need occasional tending as tools get updated, and as people try to use it and run into problems. I know, you said you want to use the thing, not make it. But there are very few of us left, you know. I think quite a few people are stuck waiting for a nicely assembled toolkit. I'm kind-of working on something like that for raising abandoned OS/2 applications. Neil -- Neil Waldhauer, neil at blondeguy.com kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art **= Email 7 ==========================** Date: Sun, 26 Jun 2005 17:16:48 +0200 (CDT) From: "Yuri Dario" Subject: Re: Warpstock 2005 Hi, >I was not aware of edm2. It is a big site with a lot of info, so I'll be >doing some study. Thanks for the pointer. something more http://www.edm2.com/0101/emx.html it is old, but it seems still valid to me. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 8 ==========================** Date: Sun, 26 Jun 2005 16:20:32 +0100 From: John Poltorak Subject: Re: Warpstock 2005 On Sat, Jun 25, 2005 at 10:42:23AM -0700, billn wrote: > I'll just offer a comment. I've been wanting to contribute to the > porting effort, but I'm really confused about how to setup an OS/2 > development system. The UnixOS2 site has a 'Getting Started' with 'major > rework under way' which has been there for some time. > > I think this may be blocking more than just me. I also think that the > infrastructure for OS/2 development needs to be packaged, with perhaps > quarterly updates that take a known working development system and > yields a better working development system. > > I'm an example of a programmer who likes to work on applications, but > does not want to spend time working on infrastructure. In fact I'd be > willing to donate a reasonable sum to whatever group kept the > infrastructure up to date, paid on a release/update basis. I originally started up the UX2BS project to try and create a standardised infrastructure, and in many respects it worked very well. In fact it allowed a complete novice to create that infrastruce and even build Perl from source by running a simple script and without reading pages and pages of documentation. The problem is that I was getting very little feedback about how things were progressing and not being a C guru myself sometimes had major problems trying to get certain apps to build and to a large extent the project has fizzled out. However my approach was that all ports of Unix apps should be buildable following the Unix build instructions for an app which normally consist of simply running Configure and Make. I still think that UX2BS could form the basis of a standardised infrastructure, but it isn't something that can be easily parceled up and made available to others - it is essentially tailored to create that infrastructure on the system which it was built on. For UX2BS to provide anything worthwhile it does require a number of people to show some interest in getting it working properly. > I'd also like to see the infrastructure support the Ada language via the > C++ compiler support. I have no idea whether that is currently > supported, or out of date. But for what I want to do, it is a much > better tool. > > So there's my $.02 worth. > > BillN > > > Lewis G Rosenthal wrote: > > > > You know, we have almost nothing in the way of leads for speakers on > > porting or ported apps for Warpstock Hershey this year. Would someone > > here kindly step up to the plate? BTW, who is planning on attending > > Warpstock in Hershey this year? I'd love to have a roundtable discussion > > concerning ported apps (what is needed, who is doing what, etc.). > > Thoughts on this idea? > > > > TIA > > > > -- > > Lewis -- John **= Email 9 ==========================** Date: Sun, 26 Jun 2005 19:23:58 +0100 From: Stefan.Neis at t-online.de Subject: Re: The OS/2 and eCS Ecosystem Hi, > I see this current requirement for specialist knowledge in order to > configure the development environment as a major roadblock to broadening > the OS/2 application portfolio. IMNSHO, this is a critical obstacle to > stability and expansion of the OS/2 ecosystem. Sorry, but I just completely fail to see what you're talking about. If you need a development environment, you just download a suitable version of gcc (either plain EMX, or EMX+gcc-3.x, or Innotek, depending on your needs), Gnumake, an editor of your choice (e.g. emacs) a couple of tools (unzip, Gnu Shell/Text/File utilities), unzip them, add the new directories to your path and are essentially done; the rest can be done as needed and this whole exercise up to here did take maybe half an hour (if you have a reasonably fast internet connection). OK, if you're using all those tools for the first time, you might want to read and understand a couple of the readmes, so add some additional amount of time for that (say between one hour and one day, depending on what you do know in advance), but so what? Where the problem? Or the specialist knowledge required? Regards, Stefan **= Email 10 ==========================** Date: Sun, 26 Jun 2005 14:11:38 -0400 From: Lewis G Rosenthal Subject: Re: The OS/2 and eCS Ecosystem Different versions of gcc behave differently. Many tools (e.g., ncurses) are somewhat outdated, and often, errors generated by make can lead in strange directions (which, of course, has nothing to do with the build environment directly, unless the cause is an outdated library or such). Essentially, the point is that building is (still) not for the casual user or for those lacking a deeper understanding of C and the whole process. I understand Steve's points, and he makes them well. However, as Bill has said, some of us just want to focus on getting the job done and not on the mechanics of doing it. ___ Lewis ___ Lewis G Rosenthal, CNA, CLE Rosenthal & Rosenthal Sent via SnapperMail ....... Original Message ....... On Sun, 26 Jun 2005 19:23:58 +0100 Stefan.Neis at t-online.de wrote: > Hi, > >> I see this current requirement for specialist knowledge in order to >> configure the development environment as a major roadblock to broadening >> the OS/2 application portfolio. IMNSHO, this is a critical obstacle to >> stability and expansion of the OS/2 ecosystem. > >Sorry, but I just completely fail to see what you're talking about. >If you need a development environment, you just download a suitable >version of gcc (either plain EMX, or EMX+gcc-3.x, or Innotek, depending >on your needs), Gnumake, an editor of your choice (e.g. emacs) a couple >of tools (unzip, Gnu Shell/Text/File utilities), unzip them, add the new >directories to your path and are essentially done; the rest can be done >as needed and this whole exercise up to here did take maybe half an hour >(if you have a reasonably fast internet connection). OK, if you're using >all those tools for the first time, you might want to read and understand >a couple of the readmes, so add some additional amount of time for that >(say between one hour and one day, depending on what you do know in advance), >but so what? Where the problem? Or the specialist knowledge required? > > Regards, > Stefan > > > > > > **= Email 11 ==========================** Date: Sun, 26 Jun 2005 13:24:17 -0700 From: billn Subject: Re: The OS/2 and eCS Ecosystem Your ease of installation comes from long experience with the tools, and detailed knowledge of how they operate, where to install them and how to use them. For someone without that knowledge, which is the specific class of people I am writing about, that process is not trivial and making a working install could take days. Learning all the tool relations and limitations could take weeks. > Sorry, but I just completely fail to see what you're talking about. As an expert, it can be difficult to put aside what you know to understand what the customer is talking about. But it is a necesssary skill for a consultant. When you first used these tools, did it take you an hour? Or much longer? From your expert view, it's easy. From my (and others) POV, it is very complex, and not too well documented. Your outline does not include all the little details that are needed to make a working system. * Which version of the compiler and libraries for what use? * Installed on which drive or drives? * Which unzip? * Which utilities are necessary and which are useful? * "The rest can be done as needed." The rest of what? This *is* the specialist knowledge. I can learn it, so can others, but it should not be required to just use the development environment. For me and others, it is not a productive use of time. It would be the same for you if the OS you use came as a bunch of pieces you had to find, download, assemble, link, convert to loader form and install before you could use the system. And every time you got a fix or update for the OS, you would have to do the whole thing over. I speak from experience that this is a lot more complex than the brief description above. All the time you had to spend learning and maintaining the OS would take away from productive time for your consulting. And any problems or troubleshooting would be more lost time, possibly causing you to miss a deadline. This is the view that those of us who build, or want to build applications, see when the development environment is so fragmented. There is no technical reason why this could not be pulled together as an ISO image with a standard install script. After installation and a reboot, a developer could go to work knowing that it will work without surprises, and without wasted time. In other words, we don't want to build a car so we can drive. We want to get in the car and drive to the store. Both choices are equally valid, but have different objectives. One is not better than the other, just a different objective. BillN Stefan.Neis at t-online.de wrote: > > Hi, > > > I see this current requirement for specialist knowledge in order to > > configure the development environment as a major roadblock to broadening > > the OS/2 application portfolio. IMNSHO, this is a critical obstacle to > > stability and expansion of the OS/2 ecosystem. > > Sorry, but I just completely fail to see what you're talking about. > If you need a development environment, you just download a suitable > version of gcc (either plain EMX, or EMX+gcc-3.x, or Innotek, depending > on your needs), Gnumake, an editor of your choice (e.g. emacs) a couple > of tools (unzip, Gnu Shell/Text/File utilities), unzip them, add the new > directories to your path and are essentially done; the rest can be done > as needed and this whole exercise up to here did take maybe half an hour > (if you have a reasonably fast internet connection). OK, if you're using > all those tools for the first time, you might want to read and understand > a couple of the readmes, so add some additional amount of time for that > (say between one hour and one day, depending on what you do know in advance), > but so what? Where the problem? Or the specialist knowledge required? > > Regards, > Stefan > > **= Email 12 ==========================** Date: Sun, 26 Jun 2005 15:57:51 -0600 From: Andy Willis Subject: Re: The OS/2 and eCS Ecosystem billn wrote: > Your ease of installation comes from long experience with the tools, and > detailed knowledge of how they operate, where to install them and how to > use them. > > For someone without that knowledge, which is the specific class of > people I am writing about, that process is not trivial and making a > working install could take days. Learning all the tool relations and > limitations could take weeks. > > >> Sorry, but I just completely fail to see what you're talking about. >> > > As an expert, it can be difficult to put aside what you know to > understand what the customer is talking about. But it is a necesssary > skill for a consultant. > > When you first used these tools, did it take you an hour? Or much > longer? From your expert view, it's easy. From my (and others) POV, it > is very complex, and not too well documented. > > Your outline does not include all the little details that are needed to > make a working system. > * Which version of the compiler and libraries for what use? > * Installed on which drive or drives? > * Which unzip? > * Which utilities are necessary and which are useful? > * "The rest can be done as needed." The rest of what? > > This *is* the specialist knowledge. I can learn it, so can others, but > it should not be required to just use the development environment. For > me and others, it is not a productive use of time. > > It would be the same for you if the OS you use came as a bunch of pieces > you had to find, download, assemble, link, convert to loader form and > install before you could use the system. And every time you got a fix or > update for the OS, you would have to do the whole thing over. > > I speak from experience that this is a lot more complex than the brief > description above. All the time you had to spend learning and > maintaining the OS would take away from productive time for your > consulting. And any problems or troubleshooting would be more lost time, > possibly causing you to miss a deadline. > > This is the view that those of us who build, or want to build > applications, see when the development environment is so fragmented. > > There is no technical reason why this could not be pulled together as an > ISO image with a standard install script. After installation and a > reboot, a developer could go to work knowing that it will work without > surprises, and without wasted time. > > In other words, we don't want to build a car so we can drive. We want to > get in the car and drive to the store. Both choices are equally valid, > but have different objectives. One is not better than the other, just a > different objective. > > BillN > > > Stefan.Neis at t-online.de wrote: > >> Hi, >> >> >>> I see this current requirement for specialist knowledge in order to >>> configure the development environment as a major roadblock to broadening >>> the OS/2 application portfolio. IMNSHO, this is a critical obstacle to >>> stability and expansion of the OS/2 ecosystem. >>> >> Sorry, but I just completely fail to see what you're talking about. >> If you need a development environment, you just download a suitable >> version of gcc (either plain EMX, or EMX+gcc-3.x, or Innotek, depending >> on your needs), Gnumake, an editor of your choice (e.g. emacs) a couple >> of tools (unzip, Gnu Shell/Text/File utilities), unzip them, add the new >> directories to your path and are essentially done; the rest can be done >> as needed and this whole exercise up to here did take maybe half an hour >> (if you have a reasonably fast internet connection). OK, if you're using >> all those tools for the first time, you might want to read and understand >> a couple of the readmes, so add some additional amount of time for that >> (say between one hour and one day, depending on what you do know in advance), >> but so what? Where the problem? Or the specialist knowledge required? >> >> Regards, >> Stefan >> >> >> > > > I didn't find setting up the environment that difficult (though I have found that I in general have a talent for such things so can't always use that as a measure for someone else) but what is a pain is dependencies. This is where some project requires the bleeding edge of some other project that requires the bleeding edge of another project, etc. That is a matter of porting everything over, depending on factors such as time. This all being said, shortly after the creation of the c++ class on yahoo there were people that said they could not setup the gcc compiler (this was pre-innotek with its installer). I setup a rexx installer for it so that people could use it (not sure though that it really ever got used but it is on hobbes). More recently there has been those trying to setup a Mozilla build environment (which is how most of my environment got setup). To me it was a mostly trivial process of following the instructions. It took more than a week (2 or 3) for someone who has been programming for years to get it set up. He would likely have a better chance of successfully porting the apps than I do once he had the environment. I can therefore see where it would be useful to have the setup but the problem is I would have a hard time setting up what I have now in a generic form as it morphs with my needs. I haven't used the UX2BS as I had a working environment that I hadn't wanted to lose trying to setup a new one but seems that it would be a good starting point for those without an environment. Andy **= Email 13 ==========================** Date: Mon, 27 Jun 2005 01:30:16 +0100 From: Stefan.Neis at t-online.de Subject: Re: The OS/2 and eCS Ecosystem Hi, > When you first used these tools, did it take you an hour? Well, I was familiar with the compiler and make tools from using them under SunOS, so gcc and make weren't new to me. Personally, I found EMX installation instructions quite detailed and they sure compare very favorable to the instructions you get for the native Unix tools. > Or much longer? Well, getting my first install took _much_ longer because of a bug in EMX-0.8d (or whatever the precise version of that antique distribution was): It used the first "ld" it could find in the path (in my case a "list directory" utility from Norton utilities), instead of the one in the gcc directory, put that has been fixed for a descade and really was the only reason why it took longer than an hour. > From my (and others) POV, it is very complex, and not too well documented Did you ever read EMX install instructions? What is it missing? > > Your outline does not include all the little details that are needed to > make a working system. > * Which version of the compiler and libraries for what use? It doesn't really matter, they all work quite well. The only general advice to keep in mind is to choose a version which is compatible with the libraries you want to use. > * Installed on which drive or drives? It doesn't matter. The binaries need to be in "PATH", DLLs in LIBPATH, choose the location you like (and don't try to change the "internal" directory structure of the zip files, i.e. don't start moving things around after you unzipped them). > * Which unzip? They are all compatible, the only difference (AFAIK) is that some treat the time stamp as GMT while other versions treat it as local time. > * Which utilities are necessary and which are useful? Well, if make calls something and can't find it, you still can worry about where to get it. For a quick start, just start. > * "The rest can be done as needed." The rest of what? Finding esoteric packages needed be specific packages. E.g. if I try to compile some X11 application requiring a specific X11 library, I go "hunting" down that library (which admittedly can be time consuming). But it really is not worth the pain to get and install everything which you might need sometime if you compile all the software that's available. Just start developping/ compiling and you'll find out what you do need. It's normally a matter of a couple of minutes to find/install an additional requirement when it happens, while you can easily pass weeks just assembling a "complete" environment and still see something missing, occassionally. Complete the environment to suit your needs as you go. > This *is* the specialist knowledge. I can learn it, so can others, but > it should not be required to just use the development environment. Well, assuming I had more spare time, you could tell me what you want to develop, I could do it and assemble all the tools needed in the process and then give you the perfect environment to complete the task that's already completed. At that point it would be somewhat useless to do the work again, but that's the only way I see to get a development environment that fits _your_ needs. [I have one that fits my needs, I even described it in my mail (EMX+emacs+ GNU shell/text/file utilities + Gnu make) and if some package turns out to require some additional stuff (e.g. lesstif libraries or autoconf or perl or whatever) I download that and install it as well and that's it.] For experimenting, I'm also using Innotek libc and the corresponding newer gcc versions, but that's currently really something for an advanced developpment environment and not normally needed. Or, if I even had more time, I could download and install everything that might be remotely useful to somebody, wrap nice installation scripts around it and try to find somebody with a hard disk big enough to actually install that monster. > For me and others, it is not a productive use of time. Nor for anybody else. But I still don't see the problem. A minimal amount of time invested in reading the excellent readmes and installation instrcutions really is all that's required. It really is as minimal as it can possibly get. > It would be the same for you if the OS you use came as a bunch of pieces > you had to find, download, assemble, link, convert to loader form and > install before you could use the system. No, it's about the same as having to locate, download, install all the fixpacks after OS installation to get an up to date system. In fact, that's the part that I personally find much more time consuming. > And every time you got a fix or > update for the OS, you would have to do the whole thing over. Sorry? I'm essentially using the same developpment environment I installed almost 13 years ago on OS/2. Occasionally, I unzip a file with a newer version over the old one but that's it. _Much_ less work than keeping the OS itself up to date. I'd claim I'm spending about _1_day_ of my time on updating the OS (adding things since 1992) for every _hour_ I spend on updating the developpment environment. > I speak from experience that this is a lot more complex than the brief > description above. No, it isn't. You just have to be couragous and start. It really is all easy and obvious - unless something is going catastrophically wrong, but that can also happen with everything else. > ll the time you had to spend learning and > maintaining the OS would take away from productive time for your > consulting. Personally, I'm not doing consulting but rather developping software. And yes, the time maintaining the OS and the developpment system _is_ annoying, but I don't see how you could avoid it. Personally, I've spend _much_ more time installing Visual C++ on Windows and compiling gcc for Linux or Solaris than I have invested in my OS/2 developpment system, even though OS/2 is my main developpment platform and the others are just for compiling/testing that things also works on those platforms. > And any problems or troubleshooting would be more lost time, > possibly causing you to miss a deadline. Yes, I know the problem ("... but it doesn't work with XP SP2...", setting up yet another new system for testing/debugging myself ...)... > This is the view that those of us who build, or want to build > applications, see when the development environment is so fragmented. I'm making my living with building applications ... Really, the OS/2 development enviroment is no problem at all. You can almost take arbitrary components, throw them together and it will just work. Problems caused by incompatible versions of tools are _very_ rare. (Bad sed versions - causing trouble on _all_ platforms -, gnuregex.dll, and problems with incompatible versions of gettext are all I can remember since about 1995). The binaries you generate might not be identical byte by byte to those compiled by somebody using different versions of the developpment tools, but both will work. > There is no technical reason why this could not be pulled together as an > ISO image with a standard install script. Sure, but I fail to see the advantage. With the "all complete" ISO image, when installing from scratch, you're still downloading while I already successfully compile the first applications. Of course, after a month or two, when I've downloaded all the other stuff that I discover sooner or later to be needed I'll have wasted just as much time on downloading and installation as you initially did, but in the meantime I might have avoided to miss some deadlines. Of course, if you're interested, I could put most of my development environment (warning: mostly 5 to 7 years old) on an ISO image and somebody could wrap a nice install script updating config.sys around it, but what for? > In other words, we don't want to build a car so we can drive. We want to > get in the car and drive to the store. Yes, and you obviously expect said car to mysteriously materialize in front of your house if you need it. It doesn't work like that. Even if you don't want to assemble the car, you still have to get through all the process (and paperwork) of actually buying (or renting) it, otherwise there will be no car you can get in. Regards, Stefan **= Email 14 ==========================** Date: Sun, 26 Jun 2005 17:29:33 -0800 From: "Dave Yeo" Subject: Re: The OS/2 and eCS Ecosystem On Sun, 26 Jun 2005 13:24:17 -0700, billn wrote: > >When you first used these tools, did it take you an hour? Or much >longer? From your expert view, it's easy. From my (and others) POV, it >is very complex, and not too well documented. > >Your outline does not include all the little details that are needed to >make a working system. > * Which version of the compiler and libraries for what use? > * Installed on which drive or drives? > * Which unzip? > * Which utilities are necessary and which are useful? > * "The rest can be done as needed." The rest of what? > >This *is* the specialist knowledge. I can learn it, so can others, but >it should not be required to just use the development environment. For >me and others, it is not a productive use of time. > >It would be the same for you if the OS you use came as a bunch of pieces >you had to find, download, assemble, link, convert to loader form and >install before you could use the system. And every time you got a fix or >update for the OS, you would have to do the whole thing over. > >I speak from experience that this is a lot more complex than the brief >description above. All the time you had to spend learning and >maintaining the OS would take away from productive time for your >consulting. And any problems or troubleshooting would be more lost time, >possibly causing you to miss a deadline. > >This is the view that those of us who build, or want to build >applications, see when the development environment is so fragmented. > >There is no technical reason why this could not be pulled together as an >ISO image with a standard install script. After installation and a >reboot, a developer could go to work knowing that it will work without >surprises, and without wasted time. > >In other words, we don't want to build a car so we can drive. We want to >get in the car and drive to the store. Both choices are equally valid, >but have different objectives. One is not better than the other, just a >different objective. The problem is as Andy said there is a lot of weird interdependencies and different projects need differrent tools. As an example I have 6 versions of GCC here. 2.81, 2.95.3, 3.0.3, 3.2.1 all installed into the e:\EMX tree with simple batch files to make whichever dominant, 3.2.2. and 3.3.5 installed in I:\gcc322 and I:\usr for 3.3.5 using Knuts gccenv.cmd to setup whichever Innotek_libc version. Then I have Johns UX2BS setup on G: with another 2.81, F:\usr has most of my tools installed. I have XFree86 4.4 installed in f:\usr\X11R6 and XFree863.3.6 installed in f:\XFree86 and an experimental Innotek_libc partial build of XFree 4.4 in I:\usr\X11R6(.bak) and have to move this one around as my Mozilla build enviroment is also on I: and it finds /usr/X11R6 and pulls in a bunch of stuff. Lots of these are also symlinked to X: which is a TVFS drive and the symlinks can be changed depending on required enviroment. An example of a tool that we need a few different versions of is autoconf. Newer ports in general use the newest 2.5.x versions and work pretty well out of the box thanks to cygwin adding support for Windows but some projects eg Mozilla need 2.13 which doesn't work out of the box to well so we need an OS/2 port installed. Both autoconfs are named autoconf and use a similar setup so I have to juggle the %PATH% depending on which version of autoconf I need. It gets quite complicated juggling different %PATH%, LIBPATH, %C_INCLUDE_PATH% etc paths. It is very complicated and I still have a few conflicts, notably to do with iconv. The way I started was with a simple setup (the basic EMX setup) which has grown over the years as I needed to add things. Another consideration is that EMX and Innotek_libc are incompatible when it comes to libraries and DLLs so need a couple of trees, then all GCC libs are incompatible to one degree or another when dealing with C++. Most of these problems also exist on Linux and even with proper distrubations there are the same problems. On my Debian partition there are also a couple of autoconfs and GCCs. Same thing, one project will only build with the newest GCC and another, eg the Kernel needs an older GCC. The only advantages on Linux are better support for symlinks and longer library (DLL) names. Another problem I keep stumbling into on Linux is there seems to be a couple of sets of the networking includes which cause conflict. The wikki at http://www.edm2.com/index.php/Porting seems a good place to start and I'm hoping to find time to add to the wikki and hopefully others will too and eventually it will morph into a good set of instructions combining all our knowledge but it is still going to take effort as we all have different ways of doing things around here. Back to the car analogy, This is like the state cars were in 100 yrs ago, you couldn't just hop in your car and drive to the store. You had to be a mechanic, an oil refinery, and a road builder. Dave, who is willing to give any help I can to help you setup a build enviroment, but is always short on time **= Email 15 ==========================** Date: Sun, 26 Jun 2005 20:25:24 -0500 From: mikus at bga.com (Mikus Grinbergs) Subject: Re: The OS/2 and eCS Ecosystem On Sun, 26 Jun 2005 07:55:09 -0700 billn wrote: > > I see this current requirement for specialist knowledge in order to > configure the development environment as a major roadblock to broadening > the OS/2 application portfolio. IMNSHO, this is a critical obstacle to > stability and expansion of the OS/2 ecosystem. I agree with the above, and disagree with those who say gaining the knowledge would take only "hours". I spent part of my early career writing pieces of the "kernel" for MVS for the System/360. To me, the development environment AND the runtime environment of MVS were "straightforward". For examples, I _knew_ how the 'linkage editor' worked, and how 'shared library modules' worked. I used that knowledge in improving what I produced. With OS/2, three widely used compilers (gcc, Watcom, IBM) each has their own 'linkage editor' (with *incompatible* directives), and when switching development between compilers great care has to be taken to ensure the code header directories and the shared library definitions match the 'DLL modules' which will be actually provided at runtime. [I gave up compiling Odin some time ago, when they started using different compilers within a single output package.] I'm retired now, but still doing software "for the fun of it". My current biggest problem with OS/2 development is _understanding_ the mechanisms used by tools which have been ported from Unix. Fifteen years ago, I was a "wizard" with 'make' on AIX. But I have not kept up. Now there is the 'autoconf' process (supposedly easier to use). I would like to customize it, both to set up a "Mikus environment" as to where it looks for resources, and to tell it where to put the generated software package. But all I've found is the variable 'prefix', which seems sometimes to be used for the one, and sometimes for the other, and sometimes to be not honored at all. Until I have MONTHS to figure out what is going on, I have one set of 'autoconf' rules for Mozilla, and one set for some Unix tools, and one set for Timidity, and ... It has been my experience so far that _one_ OS/2 development environment configuration does NOT "fit all". And it takes specialist knowledge to know when_not/why_not. mikus **= Email 16 ==========================** Date: Mon, 27 Jun 2005 00:23:11 -0700 From: "Steven Levine" Subject: Re: Warpstock 2005 In <20050626104116-52905-7 at 2rosenthals.com>, on 06/26/05 at 10:41 AM, lgrosenthal at 2rosenthals.com said: >Steve, I hope that from your perspective, we're having a discussion and >not an argument... ;-) Absolutely. >I installed a White Box Enterprise Linux server from two CD's onto a >spare Compaq Deskpro PIII/933 system, and racked it. I purchased a >license from Sputnik, Inc (www.sputnik.com) for their captive portal >software, and ran a Red Carpet install on that box, following simple >directions (a dozen steps?). I expected you to say it was easy. These are folks selling commercial software. I has to install relatively easily or all things being equal they will be out of business sooner or later. >This properly installed and configured >Apache, Jabber, and Postgres, and automagically updated a few other >things on the WBEL box. Total install time (after the OS) was >approximately a half hour of my time, and an hour of machine time >(downloads, etc.). You did well. >Warpstock SF. I signed on as a beta tester, assuring me a steep discount >on my first round of licenses and on my subsequent purchases (IOW, I made >an investment with this company, because they were using tried and true, >standard technologies, and I wanted something which would set up "out of >the box" and NOT run on a Windows platform, as I wanted stability). Just wondering. Were they a venture funded outfit or just folks that managed to go from garage shop to successful business? >certificate issue), however, I erroneously left the temporary box up and >running - and patched into the LAN with an identical IP address (ouch!!) >- which caused the Cisco router in front of it to have a heck of a time >directing traffic through the NAT to the correct box. Another case of a >little bit of knowledge being a dangerous thing... ;-) I've heard of NIC vendors shipping out NICs with indentical MACs. Another interesting failure mode. >same philosophy I see applied to what we're discussing: if there were a >closer to out-of-box build environment, people with a modicum of skills >could invest their time porting instead of setting up the build >environment. That is another of those cases where I would rather be wrong that right, but I just don't see thse kinds of build environments happening to the level you would like to see in OS/2. That said, if one was willing to invest 4 hours or so installing an gcc 2.8.x environment using John's ux2bs, they would be able to build the older apps. Another half day or so following the cookbook at http://www.mozilla.org/ports/os2/gccsetup.html and they would have an almost current gcc build environment. Another hour or so installing Watcom and they would have that too. Another 30 minutes or so installing gcc 3.3.5 and they would have to too. By then they would be able to write several scripts to prepare an evironment for each of these. With this, they would be ready to build some of currently interesting apps. >Troubleshooting, without the basic knowledge of the underlying platform, >is almost an exercise in futility, as it leads to stabbing in the dark to >hit upon what "might" be the cause (and you have reminded me of that fact >on more than one occasion, my friend!). One does not need to be a domain expert, but one does need to have a certain level of common sense knowledge. Remind me the tell you about the programmer with an EE degree that seems to be having problems converting from an ISA serial card to a PCI serial card on a DOS-based control system. >Absolutely. Which is where John's UX2BS project comes in (as just one >solution). Granted, it's scope is still somewhat limited, but it is a >step closer to a unified, portable (as in installable on multiple >systems) build environment. > Keep in mind that John probably would not claim to be a programmer, although since he was willing to put in the effort, he is getting pretty good at the process. The way it works is he does the vast majority of the detail work on his own and when he gets to a sticking point, he asks for help. Often is is just some little thing he has never seen before and the problem is solved in a couple of messages. The result is UX2BS works pretty well. >(other things that would be nice are a native port of OpenOffice, less M$ >OSes in my clients' offices, cooler weather in the summer, less snow in >the winter - well, for those of us here in the northeast, at least! - and >so on). We have snow here on the left coast. I just need to drive to where it happens to be. It's not going to just come to me. ;-) >Anyway, you haven't answered the underlying question of this thread, and >that is, will you be presenting at Warpstock this year? Inquiring minds >want to know!! :-) A trap troubleshooting session (as opposed to a "cr-p >shooting session," that is)? I'm considering my options. >Perhaps a build environment session? Probably not. >Apache? Contrary to what some might think, I don't know very much about Apache. ;-) >Oh, and you conveniently side-stepped my last inquiry regarding that >AirPrime driver. You have my curiousity piqued. ;-) I may have missed it. This weekend turned into a medical event here and I've spent most of Saturday and Sunday caring for my better half in the ECU and the ICU. Hopefully, she will be OK to come home sometime Monday. She's a bit allergic to hospitals so she not all that happy about being there. I'll try to track down the message. If I don't find it, I ask you to repost. Like I mentioned, I just did the code. Mark did all the hard work, which is why I recommended you ask him for the details. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 17 ==========================** Date: Mon, 27 Jun 2005 01:10:16 -0700 From: "Steven Levine" Subject: Re: Warpstock 2005 In <200506261514.j5QFE2mD007379 at ns2.cruzio.com>, on 06/26/05 at 08:14 AM, "Neil Waldhauer" said: >myself, to put together. I liked emx because it was a lot easier, and I >did a nice port in 1997 with that. Yes, in '97 emx was pretty much compatible with the unixes of that time. Made porting much easier. For any number of reasons, emx stayed where it was and unix evolved. >Steve is a consultant, not a toolmaker. Actually I'm more of a jack of all trades. A lot of what I do is architecting solution that make the best sense given the available resources and desired results. Of course, I'm capable of writing code when needed. FWIW, Bill is not entirely incorrect. I have written compilers and all the other stuff that that it takes to get source code from source media into ROM and tested and debugged, but that was a long time ago. >OS/2 is not Home Depot. OS/2 is the independent lumberyard owned by the >local mill. There are a few dozen OS/2 developers left. I like to think that there are a few more than that. However, since they don't seem to come out much, it's hard to know if they really exist. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 18 ==========================** Date: Mon, 27 Jun 2005 01:29:41 -0700 From: "Steven Levine" Subject: Re: Warpstock 2005 In <42BEB6B7.19AE196D at ywave.com>, on 06/26/05 at 07:07 AM, billn said: >I once held a toolmaker position like Steve's. As other's have mentioned this is not a core element of what I currently do. >said, half joking, "If it was hard to write, it should be hard to use." I >hear echos of that in Steve's responses. That's a silly attitude. You can ask my clients if they find the tools I build for them hard to use. >In order to understand why I want a simple installation of a development >environment, we need to look at what I do. Steve develops compilers >(among other things) which I use as a tool. I'm not quite sure where you got this idea. Do you actually know what OS/2 apps that I maintain or have developed or where I have contributed to products such as eCS? IAC, my point is basically that asking others to build a flexible and easy to configure tool chain for you is not going to work out very well unless you happen find someone that is interested in doing this kind of development. You might get lucky and it might happen sooner or later. However, while you are waiting you will not be doing what you claim you want to do, which is porting apps. If you take on the mindset that building the tool chain is part of the porting process for the first couple of apps, your apps will see the light of day much sooner. Also, given your stated ability to build effective tools, you might actually end up with the tool chain you think everyone should have. Regards, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 19 ==========================** Date: Mon, 27 Jun 2005 10:31:11 +0100 From: John Poltorak Subject: Re: Warpstock 2005 On Mon, Jun 27, 2005 at 12:23:11AM -0700, Steven Levine wrote: > In <20050626104116-52905-7 at 2rosenthals.com>, on 06/26/05 > at 10:41 AM, lgrosenthal at 2rosenthals.com said: > > >same philosophy I see applied to what we're discussing: if there were a > >closer to out-of-box build environment, people with a modicum of skills > >could invest their time porting instead of setting up the build > >environment. > > That is another of those cases where I would rather be wrong that right, > but I just don't see thse kinds of build environments happening to the > level you would like to see in OS/2. That said, if one was willing to > invest 4 hours or so installing an gcc 2.8.x environment using John's > ux2bs, they would be able to build the older apps. I think I should make it clear that this 4 hours investment is not personal time, but computer time. The personal effort involved is just a few minutes ie downloading and running a simple script. The four hours or so which very much depends on the power of your of hardware is spent downloading and building various elements of the toolchain for the environment you want to work in. This includes the latest version of Perl. Bear in mind that v2.8.1 is still used for building many apps today including Python and probably Apache as well as Perl which has been mentioned. > http://www.mozilla.org/ports/os2/gccsetup.html > and they would have an almost current gcc build environment. > > Another hour or so installing Watcom and they would have that too. > > Another 30 minutes or so installing gcc 3.3.5 and they would have to too. > > By then they would be able to write several scripts to prepare an > evironment for each of these. > > With this, they would be ready to build some of currently interesting > apps. I did hope that at some point UX2BS could be used to build gcc 3.3.5 so that it could provide a single build environment for all OS/2 ports, but still have several problems getting some of the most basic apps in the toolchain to build properly. > >Troubleshooting, without the basic knowledge of the underlying platform, > >is almost an exercise in futility, as it leads to stabbing in the dark to > >hit upon what "might" be the cause (and you have reminded me of that fact > >on more than one occasion, my friend!). > > One does not need to be a domain expert, but one does need to have a > certain level of common sense knowledge. Remind me the tell you about the > programmer with an EE degree that seems to be having problems converting > from an ISA serial card to a PCI serial card on a DOS-based control > system. > > >Absolutely. Which is where John's UX2BS project comes in (as just one > >solution). Granted, it's scope is still somewhat limited, but it is a > >step closer to a unified, portable (as in installable on multiple > >systems) build environment. > > > Keep in mind that John probably would not claim to be a programmer, > although since he was willing to put in the effort, he is getting pretty > good at the process. The way it works is he does the vast majority of the > detail work on his own and when he gets to a sticking point, he asks for > help. Often is is just some little thing he has never seen before and the > problem is solved in a couple of messages. The result is UX2BS works > pretty well. It could actually be so much better. As you say I'm no programmer - at least not in C (I used to be quite good with IBM BAL), but the point about UX2BS is to fully automate the building of any apps which have already been ported by someone by formalising what they did and put it within an integrated build environment. The idea is to find out what the porter did and then try and script it so that everyone else can do it without reading reams of docs. > I'm considering my options. > > >Perhaps a build environment session? > > Probably not. Maybe someone could show what UX2BS can do... I'm still quite please that it can build something as complex as Perl so effortlessly, but it would be nice to be able to do the same with every other Unix app too. > Regards, > > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.67 #10183 Warp4.something/14.100c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- > -- John **= Email 20 ==========================** Date: Mon, 27 Jun 2005 13:57:54 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: The OS/2 and eCS Ecosystem Hi, > Now there is the 'autoconf' process > (supposedly easier to use). > But all I've found is the variable > 'prefix', which seems sometimes to be used > for the one, and sometimes for the other, > and sometimes to be not honored at all. Yes, those are bugs, possibly both in the tool versions used on OS/2 and in the software packages you're trying to install. However, this proves my point that the problem is _not_ how to install autoconf but the development work involved in possibly fixing it and in porting the interesting apps to OS/2. > It has been my experience so far that _one_ > OS/2 development environment configuration > does NOT "fit all". And it takes > specialist knowledge to know > when_not/why_not. I tend to agree. Things that work OOTB on somebody elses development environment can be huge problems for myself and vice versa. But the only way to find that out is trying. And if you're faced with problems, asking on mailing list about what others use to compile a specific package probably is the easiest way out. However, the generic "I need a development environment which can do everything" leads nowhere. Regards, Stefan