Alpha port?
[ Please CC me your reply! ] Hello, I just got a DEC Alpha 21164 box. I'm running Debian on it. I went to the ports page but the port from "Uncle George" is not accessible (permission denied error). Can anybody point me to where I might find the Alpha version, appropriate diffs to compile it, etc, etc. I would really like to get it working on Alpha but can't seem to find the Alpha version anywhere! Thanks, John -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Uncle George's Alpha Port
Hi, The archives don't show e-mail addresses or else I'd write to Uncle George directly. Anyway, I understand there is some problem with your Web provider. I'd encourage you to upload your port of JDK to Alpha to sunsite or someplace like that. I believe there is significant interest in it, and it's a shame to have a situation where nobody can use the port to such an excellent machine because your web provider is being nasty. Sunsite has many, many mirrors and once it's on there, this ought to eliminate all future problems. Is there any other way to get it from you? Thanks, John Goerzen
Re: Announce: JDK117 for alpha
(BTW, I tried replying personally to you, but it bounced.) George, I just want to say a BIG thanks for your work on this. This has eliminated one of the things that I was lacking on Alpha, and was sorely missed. No longer! Just a quick question: Does it use green threads or native threads? If not native threads, can we expect such support in the future? Thanks, John On Wed, Nov 11, 1998 at 10:21:05AM -0500, Uncle George wrote: > Yes folks ( I think ) it ready for prime time. There was a binary > version v1, but there was an awt problem that showed up in the ide > "supermojo" ( i have no connection, AND have only a demo model ), and > has been superceeded by the binary files version v2. The classes file is > still version v1. -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Re: FUCKING MAIL LIST
Is there any particular reason that you ignore the instructions sent when you subscribed, fail to make use of the information available to you at the website for these lists, and further proceed to make a royal fool of yourself while endeavoring to inappropriately insult the list and others on it? On Sat, Nov 28, 1998 at 05:28:28PM -0600, apersil wrote: > TELL ME HOW TO REMOVE MYSELF FROM THIS FUCKING MAIL LIST! -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Re: An IDE for C and JAVA
On Mon, Dec 21, 1998 at 10:06:10PM -0500, Kirk Hutchinson wrote: > First of all, XEmacs is not an IDE. It's a code editor - that's it. You obviously know little about it then. It has built-in and (virtually) seamless interfaces to compilers, debuggers, and interpreters. > It's really too bad that more IDEs are not available for Linux. What do these give you that XEmacs doesn't? -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
Re: An IDE for C and JAVA
On Tue, Dec 22, 1998 at 11:11:08AM +0100, Artur Biesiadowski wrote: > John Goerzen wrote: > > I personally do not use highly integrated IDEs and it seems that you do > not also, but do not think that Xemacs is an IDE - it is just very smart > editor. What it lacks ? > > Graphical composition of GUI components, including positioaning them, I'm sorry, but you can certainly have IDEs without this. I remember using Borland C++ 2.0 under DOS, which had what everyone would call an IDE. Before that, I used Turbo Pascal 5.5 under DOS, which also had an IDE -- and everyone called it that. XEmacs has far more features than either of those, both IDE-wise and otherwise, so I cannot understand how you can claim that something that does more than other IDEs is not an IDE. > disvovering their properties by beans mechanism, creating handlers for > them by simple clicking, editing their properties with instant effect on > the screen. So what you're wanting is a Java visual development environment. Incidentally, I have yet to see one of those that I like, for Java or otherwise. They often work by laying out components at certain pixel locations, which is even worse in Java than elsewhere, because fonts and sizes of widgets can vary tremendously between systems. Also, none of them that I've seen will do Swing, which I use, so that rules them all out. Back to XEmacs. > is really pitty one. I'm talking about something with ability to check > variables by moving mouse over them , graphically displaying and > followingg instance variables (as ddd does) etc. I've never used jdb, but I must say that for a debugger, I prefer gdb. Nothing else, except perhaps the XEmacs interface to it, is really acceptable. I find that limitations of a GUI get to be cumbersome in many cases.
FAQs and mailing list
GRR... I'm getting a bit ticked with the endless "unsubscribe" posts to the list, and the JDK 1.2 questions. First, why are we not using cookies to confirm subscribe and unsubscribe requests? Seems like a prudent thing to do. Secondly, Majordomo has features to identify admin requests posted to the list (these posts with just the word unsubscribe in them) and bounce them to the list owner instead. These ought to be enabled. This way, we don't get clueless people that throw away the instructions they got when they subscribed filling mailboxes of lots of other people. Third, instructions for unsubscribing ought to be in a footer tacked on to messags. Finally, a FAQ aboug JDK 1.2 ought to be posted periodically. These all sound like reasonable and common-sense things to do, John
Re: Java-Linux enthusiasts
A valid categorization, I believe. I clearly belong best to #4, but a difference is that I believe that Linux will be overtaken by something else. Hurd, for instance, when it gets more stable (but we're looking at years here). Java has serious problems with speed, bloat, licensing and open-ness. Its cross-platform nature prevents it from being useful for certain types of programming that are best done in C; for instance, high-usage web servers or NFS. I also believe that applets are a fairly odd idea, and are not done in a good manner. Most that I've seen have very little use. On the other hand, I believe Java is almost ideal for GUI design, especially for the client in client-server programming. A GUI interface is sitting idle over 99% of the time, so speed is not so vital here. Cross-platform capabilities are a big win; a universal network client can be a big time saver for people that need clients on lots of platforms. I, for one, much prefer the Unix development environment, and this allows programs to run in Win32 platforms while we wait for Windows to finish dying :-) > 4. Linux evangelists : Linux is the future. Java is a fad that will >probably be overtaken by something else eventually. Think that Java >does not have the best licensing model (it's not GPL). Java is slow >because Perl kicks ass in CGI (have never heard of servlets). Can't >understand why we don't just have a Java to native compiler, > especially >one to Linux. I would certainly not use Java for CGI. libapache-mod-perl, FastCGI, etc. if necessary.
Re: JavaLinux for servlets
On Tue, Feb 16, 1999 at 04:34:03PM -0800, Kevin Hester wrote: > > > I would certainly not use Java for CGI. libapache-mod-perl, FastCGI, etc. > if necessary. > > I'd definitely encourage anyone to use servlets with wild abandon. So easy > and clean - I haven't had to write CGI cruft in over a year. In exchange > for servlets I have a logical/maintainable tree of server side classes. But what techincal advantage do they really give? Java is slower, uses more system resources, etc. John
Re: JavaLinux for servlets
On Tue, Feb 16, 1999 at 07:49:18PM -0500, David Harvill wrote: > Overall, the servlets do not use more system resources. CGI has to spawn > an entire new process (with full memory overhead) for each incoming > request. Java starts up the process (and memory overhead) only once, and > simply gives out a new Thread to handle the requesting. CGI does not have this drawback when you use FastCGI or mod_perl, so that case isn't really valid. Further, the speed comparison between Java and Perl or C can be significant if your CGI is doing any sort of computation. Most do :-) John
Re: JavaLinux for servlets [off-topic]
On Tue, Feb 16, 1999 at 08:03:26PM -0500, Daniel W. Dulitz x108 wrote: > John, you wonder about the technical advantages of Java. Java is all > about balancing easy to write and easy to read code against runtime > performance. Think C versus assembly language. And the real question > is, "Is the runtime performance of Java adequate?" For all but the > tiniest web servers, the answer is yes. Is servlet development time This is not really the point. The point is that for a heavily-loaded server, even a small difference in performance can make a tremendous difference in the system -- possibly the difference between running well and not running at all. > less than Perl development time? For substantial apps, we have always > found that to be the case. Are Java servlets more maintainable over I do not disagree that Java's strong typing is useful for large apps. > time than Perl? I don't think that's even a serious question. I do disagree that Java is more maintainable than Perl in general. If you know Perl, it is quite easy to read and maintain. The regexp support makes it far easier to code and maintain anything that parses things that are even vaguely complex. > Are you doing database work? PHP3 is a great tool for integrating > databases with the web, but try doing a sophisticated interactive user > interface with PHP3 -- it bogs down your server and produces really > abysmal client-side performance when compared to applet+servlet. And > the code is a nightmare to maintain. I do not, and have never, reccommended PHP3 for anything "serious", for just these issues, and others. But mod_perl and FastCGI are quite good for CGI. > For me, the clue is that you've only seen cute applets, not useful > ones. That's a big indication that you're not using real > client-server over the web. What do I mean by "real" client-server? > I mean the case where you have a "real" software system -- not the toy > programs we tend to think of when we think of the (consumer) web -- > with a user interface, some non-database-related processing, and one > or more databases that the server talks with while doing that > processing. No, I've seen Java programs, and even a "serious" applet or two. The point is that this is not an acceptable or useful paradigm in my opinion. The fact that the language used is Java is really irrelevant. If one really wants this sort of thing, embedded X may be a better solution, but it has lots of problems, too. I don't think it's a good solution either (except perhaps for corporate LANs.) > If that's what your problem looks like (and that's what a lot of > enterprise software looks like), CGI is a joke. Sure, you can spend a > while getting your database interface to talk with your C++ server, > and you can spend ages getting your C++ server integrated with CGI -- > and after all that, you end up writing a Java applet because it's the > only portable way to present an interactive GUI via a browser. So you You're clouding the issue. The point is that HTML itself is not adequate in the case you're describing. In fact, the whole Web idea is not adequate here, and it was never designed to be. I have never disagreed that a Java-based GUI application (note, not applet) as a client would be good, and in fact, in the message to which you are replying, you snipped the part where I said so. > spend time interfacing your applet with CGI, debugging the whole mess, > and then it still runs slowly. > With servlets and applets, you write your applet, it communicates > directly with the servlet via RMI, the servlet communicates directly > with the database via JDBC, and you don't have any integration and > debug problems. And because the servler is threaded, initial > connection speeds blow away CGI. I wish people would stop comparing a current Java idea with an outdated CGI one. If you want to compare it to CGI, please do us the favor and compare it to current CGI ideas. But you are comparing HTML to something that is not appropriate for HTML. You're describing a whole application.
Re: JavaLinux for servlets
On Tue, Feb 16, 1999 at 06:10:02PM -0700, Robert Ritchy wrote: > In addition to the above - portability. I just finished a complete a servlet > solution for a BIG company on my dinky pentium 75 linux laptop (apache/jrun). The > installation on their site (Solaris/NES/JRun Pro) was MINIMAL with no > environment/configuration changes except for the addition of the path to the new > servlet. I just uploaded the classes and html templates and updated the jrun > configuration file. For servers, I'm unsusre that portability is a big win, or even much better, with Java than Perl. Perl programs run all over, and well-written C programs do as well, although probably there would need to be a lot of changes. > > > > > On Tue, 16 Feb 1999, John Goerzen wrote: > > > > > On Tue, Feb 16, 1999 at 04:34:03PM -0800, Kevin Hester wrote: > > > > > > But what techincal advantage do they really give? Java is slower, uses more > > > system resources, etc. > > > > > > John > > > > > > Content-Description: Card for Robert Ritchy
Re: JavaLinux for servlets
On Wed, Feb 17, 1999 at 01:17:43AM -0800, Steve Byrne wrote: > > But what techincal advantage do they really give? Java is slower, uses more > > system resources, etc. > > John, if you don't like Java, can you please tell us why you feel it's > necessary to clog this mailing list with your anti-Java sentiments? I don't > think it's being constructive. I am really getting annoyed with people picking out bits and pieces of what I wrote. You, and others, are taking it out of context. I have explained the areas in which I feel Java has an advantage over other languages -- for example, development of large-scale client GUIs. I have also explained the areas in which I feel Java has some catching up to do, for example, tasks involving parsing. If you feel that any particular language, including Java, is the best choice for every possible task, then you need to take a larger view of reality. The fact is that Java is not the best in all areas. Likewise, Perl is not the best in all areas. Neither is C. For that matter, neither is Linux or Windows. You use the tool that's right for the job. I use Java for some things, Perl for some things, C for some, C++, shell scripting, etc. All of them have their unique advantages and disadvantages. You would probably think me crazy to use shell scripting for a GUI. While technically possible, it would be horrendous code. Likewise, I would probably think that using Java for an application that does a lot of complicated parsing of input, computation, and then generation of output would not be wise; Perl is better suited to that task. Similarly, if I were writing a webserver or other server that could see high levels of load, C is really the only good choice. Perl and Java may require less code, but the performance would not be the same simply because of the abstraction in order to make it system-independant -- although Perl is closer to Unix than Java. The interpretation cost and memory overhead hurts, too. Constructive criticism is a well-known useful device. If I point out to the Perl people that the lack of strong typing can make large projects difficult, and thus make Java a better tool for the job, perhaps the Perl people will consider adding typing to the language (and indeed, they are doing so). Likewise, if I point out to Java people that Java's parsing capabilities are weak compared to Perl, perhaps they will add something to help with that. In the end, everone wins, because all the languages improve. I fail to see what's wrong with talking about Java's unique benefits and problems in a Java list. John
Re: JavaLinux for servlets [off-topic]
On Wed, Feb 17, 1999 at 09:51:51AM +0100, Chris Huebsch wrote:
> The first is a "non-java-at-all" Server. It has to create a new process
> when a request arives. Where? The system is almost at the limit? It is
NO.
I keep saying this and apparently nobody is listening.
Let me give you URLs then:
http://www.apache.org/related_projects.html#modperl
"With mod_perl it is possible to write Apache modules entirely in Perl.
In addition, the PERSISTENT interpreter embedded in the server avoids
the overhead of starting an external interpreter and the penalty of
Perl start-up time." (emphasis mine)
http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm
"FastCGI processes are persistent: after finishing a request, they wait
for a new request instead of exiting."
"FastCGI . . . multiplexes the environment information . . . [allowing]
FastCGI programs to run on remote machines"
> > I do not, and have never, reccommended PHP3 for anything "serious", for just
> > these issues, and others. But mod_perl and FastCGI are quite good for CGI.
>
> Database-Access with php or perl may be simple with simple problems. But
> when the problem gets more complex the problems increase exponentially.
> For instance you change your database from oracle to informix. With php
> you may change all your pages and replace oracle_db_XXX() to
> informix_db_YYY(). In java you write a factory which creates the
> SQL-Statements and only change the factory. The remaining parts of your
> application/applet/servlet remain untouched
Perl has DBI, which is largely JDBC-like. DBI is not quite as good as JDBC
for some things, but it is better for others. DBI creates an abstraction
between the program and the database driver just as JDBC does.
> Java is not just a language! It is an very large API and a Virtual
> Machine too.
> And one usefull use of Applets: I wouldn't do my online-banking with
> ActiveAEKS or just SSL. A-X wouldn't run on a Sparc ;)
Hehe :-)
> There are some problems which require not much data-transfer but a lot
> of graphical work. I cannot imagine transferring every single screen via
> X-protocol. (Embedded X is a X-Server inside the browser - isn't it?)
Essentially yes. Which is the reason for my comment that, even with X
protocol compression, it's probably not good for much other than a LAN, and
even there it suffers from the same problems that Java does.
My point is that applets and embedded X are answers to a question that
nobody asked :-)
I know that Java is a VM, bytecode, etc. What I'm trying to say is that
this is irrelevant -- HTML and the Web are simply the wrong paradigm for
trying to deploy full-fledged applications.
> > I have never disagreed that a Java-based GUI application (note, not applet)
> > as a client would be good, and in fact, in the message to which you are
> > replying, you snipped the part where I said so.
>
> As already written - why to risk serious trouble by mixing lots of
> different technologies when you can use one? (If you really need peak
> performance you could use JNI with ANSI-C on the serverside)
Clouding the issue again :-)
The comments regarding applets have nothing to do with C or JNI. Again I'm
trying to say that applets do not make sense in the context of HTML. It's
not Java's fault, it's just how things are.
> > I wish people would stop comparing a current Java idea with an outdated CGI
> > one. If you want to compare it to CGI, please do us the favor and compare
> > it to current CGI ideas.
>
> And I wish people would stop comparing a current CGI idea with an
> outdated Java one ;)
> Java was designed with JITs in mind. Why would the bytecode assume a
> stack-architecture (which is simmilar to intermediate-code of "normal"
> compilers) if not to compile the last stage?
I've never denied JAva's thread abilities or JIT capabilities, nor bytecode,
and the like. I frankly don't see its relevance for applications vs.
applets, as I've already granted you that performance is not so critical
there.
> public class chu extends ChrisHübsch implements TUChemnitz {
OK, you have beeen programming Java WAY too much :-)
> String email= "mailto:[EMAIL PROTECTED]";
> String SMSMail = "mailto:[EMAIL PROTECTED]?Subject=SMS: info";
> URL homepage = new URL("http://www.tu-chemnitz.de/~chu/");
> Talktalkto = new Talk("[EMAIL PROTECTED]");
> Integer ePlus= new Integer(4628555);
> }
Re: JavaLinux for servlets [off-topic]
You are correct, Alex. Both Solaris and Linux support "real" threads, as do several other Unix OSs. We can go into detail if need be, but I hope we can spare the list that :-) On Wed, Feb 17, 1999 at 01:32:38PM +0300, Alex Romadinoff wrote: > >AFAIK unix doesn't support real threads. For new requests a new instance > > ? > >of the CGI is created with fork() or something like that? Now imagine a > >server with a load around 99%. > > > Are you sure ? > What about 'clone' on Linux ? > > With best wishes, > Alex Romadinoff
Re: JavaLinux for servlets
OK, this is about the 6th or 7th time I've said this and STILL people are ignoring it. Your whole argument is based on a flawed premise: that with CGI, a new process must be started for each request. This is plain and simply NOT correct. I have pointed this out time and time again. Any benchmarks comparing Java to this sort of thing are misleading at best, and more likely downright incorrect. If people want to discuss the performance of mod_perl or FastCGI vs. servelts, please do so. But please cease this misleading practice of comparing current Java to outdated Perl. In <[EMAIL PROTECTED]>, I wrote: I keep saying this and apparently nobody is listening. Let me give you URLs then: http://www.apache.org/related_projects.html#modperl "With mod_perl it is possible to write Apache modules entirely in Perl. In addition, the PERSISTENT interpreter embedded in the server avoids the overhead of starting an external interpreter and the penalty of Perl start-up time." (emphasis mine) http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm "FastCGI processes are persistent: after finishing a request, they wait for a new request instead of exiting." "FastCGI . . . multiplexes the environment information . . . [allowing] FastCGI programs to run on remote machines" On Wed, Feb 17, 1999 at 11:10:12AM -0700, Jeff Galyan wrote: > When a webserver (let's say Apache) gets a request from a client to run > a traditional CGI, the server spawns a new process *independent* of > itself. If the process is a Perl process, then it has the overhead of > initialization, reading in the file, parsing, etc. *before* it can do > anything useful to the end user. Not if using mod_perl or FastCGI, as I have kept saying. As the rest of your post relies on this flawed assumption, there isn't much else to say.
Re: JavaLinux for servlets
On Wed, Feb 17, 1999 at 12:39:57PM -0700, Jeff Galyan wrote: > Pardon me, but you appear to be the ONLY person actually using mod_perl > or FastCGI in a production environment. I know of multiple organizations using mod_perl in a production environment. If memory serves, hotmail is one, but that could be incorrect. > As for my assumptions being "flawed", that would mean that the > developers at Java Software (formerly JavaSoft) don't know what they're > talking about either, nor do the course developers at Sun Educational > Services, nor do anyone else I work with at Sun. I fail to see how your failure to realize that CGI is not a stone ages technology has any bearing on Sun. What marketing types and the real programmers say and do can be very different things. It is unfortunately not all that uncommon to compare a current version of one's own product to an outdated one from someone else for marketing purposes. > Perhaps the reason people are ignoring your argument against using Java > is because your argument is, plain and simple, wrong. How so? > Now I hope this puts an end to this stupid thread.
Re: NO MORE--JavaLinux for servlets
Shall we all send unsubscribe requests and 1.2 questions instead? :-) (Gotta keep the traffic up somehow, you know) Anyway, *cough* caps lock... On Wed, Feb 17, 1999 at 01:25:43PM -0600, Jason Hoffman wrote: > PLEASE, PLEASE, PLEASE! Take this offline... This list has a SPECIFIC > purpose, and this discussion is NOT it. Please reply directly to the sender, > AND NOT THE LIST. > > PLEASE, JOHN! > PLEASE, EVERYONE ELSE! > > Thank You!
Re: JavaLinux for servlets
On Wed, Feb 17, 1999 at 07:23:04PM -0800, Steve Byrne wrote: > I'm sorry, but all I saw from your sudden burst of postings was anti-Java. Perhaps you would realize that I did not start this thread? I was replying to a message that stated: > 4. Linux evangelists : Linux is the future. Java is a fad that will >probably be overtaken by something else eventually. Think that Java >does not have the best licensing model (it's not GPL). Java is slow >because Perl kicks ass in CGI (have never heard of servlets). Can't >understand why we don't just have a Java to native compiler, I do not understand why you are criticizing me for replying to that. If that post was on-topic, which it seems to be, how can a topical reply not be? Note that in my reply, I mentioned: A valid categorization, I believe. I clearly belong best to #4, but a difference is that I believe that Linux will be overtaken by something else. Hurd, for instance, when it gets more stable (but we're looking at years here). Clearly Linux-related. Again, people ignore that part of my message. I then go on to talk about Java, how it relates to Unix (and Linux), and then CGI. This was in <[EMAIL PROTECTED]>. > > I fail to see what's wrong with talking about Java's unique benefits and > > problems in a Java list. > > Ok. Let me be REAL clear to you. Your thinking here is confused. You > believe java-linux to be "*a* Java list"; i.e. you see is as equivalent to > comp.lang.java. It is not. It is for discussing issues related to Java on I never said that. > Linux. If you want to engage in debates about larger issues which are really > Linux independent, then this is NOT THE PLACE FOR YOU. I don't think that I've > seen anything that you have written criticizing Java is specifically Linux Java > related, and thus it constitutes a poor and inappropriate use of bandwidth to > announce your generic opinions on java-linux. I was not announcing my generic opinions about Java. I was replying to others. And if you think that Apache, CGI, web servers, and the like are not Linux-related, well, please take a look at your neighborhood Linux distribution and realize that they are. Note that we would not be talking about Apache or Perl for CGI if this was a Windows platform, or even many Unices. > The comp.lang.java* news groups are a much better place to talk about the > generic benefits and problems with the Java platform than java-linux. Please > use them for expressing your generic Java views, ok? Thanks. I'm quite willing, and would be glad, to see this thread die. But the rather brutal attack that I have suffered for merely pointing out that Java is not always the best is not really justified. I did not start the thread. I was agreeing with one particular option set forth by another person. It started out Linux-related. My reply was Linux-related. When people started replying to me, they chopped out parts of my messages. They did not reply to the whole message. Several people in here even were thinking that I was completely against Java, even after I recommended it for some types of projects! (People never quoted that.) I use Java. I also use other languages. What am I supposed to do here, refuse to answer because of underhanded quoting techniques? This whole thread has illustrated something: there is a lot of delusion of grandeur here. People must realize that no language is the best for everything. As a Linux developer, I have a very high opinion of Linux, but I do recognize that it has its weaknesses that could make it unsuitable for some people. As someone that programs in Perl, I have a similar opinion. Likewise for Java, (despite its poor licensing; the core is good.) John
Mailing list trouble
You may want to be on the alert for a message like this. Apparently either the administrator of java.blackdown.org or a very poorly-written bounce catcher is seriously misconfigured. If you note, it claims to have removed me due to bounces my mail account caused, but in reality, it was [EMAIL PROTECTED] My mail server was up the entire time, and my mail logs confirm that. I've received no response from any blackdown admin regarding this or the other issues I raised the other day. - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Date: Thu, 18 Feb 1999 01:54:21 -0500 To: [EMAIL PROTECTED] Subject: You have been removed from the list Your mail address [EMAIL PROTECTED] has been removed from the [EMAIL PROTECTED] mailinglist. It generated an excessive amount of bounced mails. Before sending in a subscription request to [EMAIL PROTECTED] again, please ensure that this problem has been resolved. When in doubt, ask your system administrator or send mail to "postmaster". The last one of those bounced mails has been quoted below: >From MAILER-DAEMON Thu Feb 18 01:54:01 1999 >Received: from mail.cabi.net (ikea.cabi.net [208.24.141.88]) by shell.ncm.com >(8.8.5/8.7.5) with ESMTP id BAA26115 for <[EMAIL PROTECTED]>; Thu, 18 >Feb 1999 01:54:00 -0500 >Received: from mail.megsinet.net (mail.megsinet.net [208.133.72.253]) > by mail.cabi.net (8.8.5/8.8.4) with ESMTP > id BAA16323 for <[EMAIL PROTECTED]>; Thu, 18 Feb 1999 >01:40:16 -0500 >Received: from mail.megsinet.net by mail.megsinet.net > (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) > id <[EMAIL PROTECTED]> for > [EMAIL PROTECTED]; Thu, 18 Feb 1999 00:43:03 -0600 (CST) >Received: from mail.megsinet.net > (Sun Internet Mail Server sims.3.5.1998.11.13.11.10) > id <[EMAIL PROTECTED]>; Thu, 18 Feb 1999 00:39:03 -0600 (CST) >Date: Thu, 18 Feb 1999 00:39:03 -0600 (CST) >From: Internet Mail Delivery <[EMAIL PROTECTED]> >Subject: Delivery Notification: Delivery has been delayed >To: [EMAIL PROTECTED] >Message-id: <[EMAIL PROTECTED]> >MIME-version: 1.0 >Content-type: MULTIPART/REPORT; > BOUNDARY="Boundary_(ID_4uwT2qbNDRl0ro2j+O1haQ)"; REPORT-TYPE=DELIVERY-STATUS > > >--Boundary_(ID_4uwT2qbNDRl0ro2j+O1haQ) >Content-type: text/plain; charset=ISO-8859-1 > >This report relates to a message you sent with the following header fields: > > Message-id: <[EMAIL PROTECTED]> > Date: Tue, 16 Feb 1999 18:34:17 -0600 > From: John Goerzen <[EMAIL PROTECTED]> > To: Kevin Hester <[EMAIL PROTECTED]> > Subject: Re: JavaLinux for servlets > >Your message has been enqueued and undeliverable for 1 day(s) >to the following recipients: > > Recipient address: [EMAIL PROTECTED] > Reason: unable to deliver this message after 1 day > >Delivery attempt history for your mail: > >Thu, 18 Feb 1999 00:03:12 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Wed, 17 Feb 1999 20:15:12 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Wed, 17 Feb 1999 16:03:58 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Wed, 17 Feb 1999 12:06:43 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Wed, 17 Feb 1999 08:08:05 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Wed, 17 Feb 1999 04:10:47 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Wed, 17 Feb 1999 00:06:17 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Tue, 16 Feb 1999 20:30:12 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >Tue, 16 Feb 1999 18:41:09 -0600 (CST) >Temporary error returned by SMTP partner. >smtp; 452 4.5.3 No more transactions allowed. > > >The mail system will continue to try to deliver your message >for an additional 6 day(s). > > >--Boundary_(ID_4uwT2qbNDRl0ro2j+O1haQ) >Content-type: message/DELIVERY-STATUS > >Reporting-MTA: dns; mail.megsinet.net > >Action: delayed >Status: 4.0.0 (unable to deliver this message after 1 day) >Original-recipient: rfc822;[EMAIL PROTECTED] >Final-recipient: rfc822;[EMAIL PROTECTED] > >--Boundary_(ID_4uwT2qbNDRl0ro2j+O1haQ) >Content-type: text/plain > >Return-path: [EMAIL PROTECTED] >Received: from mail.megsinet.net by mail.megsinet.net > (Sun Internet Mail Server sims.3.5.1998.11.13.11.10
Re: Mailing list trouble
On Thu, Feb 18, 1999 at 12:20:38PM -0500, Brett W. McCoy wrote: > On Thu, 18 Feb 1999, John Goerzen wrote: > > Every message I've posted to the list this week has resulted in a > bounced message from a system where the username is no longer valid. Same here, and I've already complained to their postmaster several times. That's not something that the blackdown people can do much about, though -- there are other broken mailers out there.
Re: TFS Delivery Failure: Re: Mailing list trouble (fwd)
I'm about to ban the IP of that server from my sendmail. It's obviously not compliant with RFCs, and their admins never answer mail. Maybe if they get a 550 when trying to deliver a bounce, it will create a mail loop on their end, hehe :-) On Thu, Feb 18, 1999 at 01:17:55PM -0500, David Harvill wrote: > Get it every single time > > -dave >
Re: Hatred of 1.2 messages
Gerald Gutierrez <[EMAIL PROTECTED]> writes: > I'm starting to get the feeling that many in this group are approaching > "when will 1.2 be out" messages with a very disheartening attitude that > will surely turn potential users off. Well let's see. Presumably to find out about the mailing list, they will have visited www.blackdown.org. At that website, there is a *prominent* link to the JDK 1.2 status. I don't see why there is a big right for them to bother the list with information that they could have easily looked up themselves (which is also contained in the list archives). Common netiquette has it that you RTFM first, then check the archives (or dejanews or whatever), and then finally ask on the list if you have a question. It saves everybody's time, including the person looking for an answer. If people are not willing to go to the effort of clicking a few links, I don't think that anybody here has any obligation to go to the effort of answering. Having said that, I do agree that some rather vitriolic messages may cross a line, but look at it this way: if they can't figure out where to find the news page, are they really going to be able to download and install the thing when it's out? A better solution would be to have public betas. Then people could give it a try, see for themselves what the problems may be, and make their own evaluation about whether or not the stability is good enough for them. This approach has been extremely successful in the Linux community. > about the Linux version. Perhaps it's because they think it's the > right-thing-to-do or perhaps it's their only option because they're already > using Linux. There are potential users anxious for it and they'll praise > those who make it happen. And I'm glad about the interest in Linux! But really, this has nothing to do with Linux. People that don't RTFM or RTFWP (the fine web page) before posting FAQs will get this sort of response most anywhere. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: go back to gzip!
"David Wall" <[EMAIL PROTECTED]> writes: > It was a bit rude as written, and that's part of the problem with email in > general. Sometimes terse statements sound worse than the intended message > was to be delivered. You said "nobody uses bzip2", which is CLEARLY incorrect. > While I am really happy with the work that this free software team has been > doing, and I appreciate and make good use of their labor, the original post > did have a good point: why introduce a new zip scheme that would not be > available to most people? gzip is open source and widely deployed. Was > there a particularly strong reason for using bzip2 over gzip? First, this is not "new". bzip2 has been around for some time. Secondly, the source is available and it runs on a wide variety of platforms. How is there a problem here? This is exactly how gzip is distributed. While it's true that bzip2 is not GPL, it does meet the DFSG. Your question about why to use it demonstrates that you do not know how it works, or what it does. Yet you criticise the use of it. Perhaps why you realize how much better compression it gets than gzip, and check out its homepage at http://www.muraroa.demon.co.uk/, you'll see that any computer that's going to be running the JDK will probably be of sufficient speed to benefit from bzip2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alphas?
Andrew Rawnsley <[EMAIL PROTECTED]> writes: > One platform that is conspicuously missing from the Blackdown > port list is an alpha port. Are there any plans? Is it a hardware > availability issue? It's already done; if this list is archived, check the archives. I've got it sitting around here waiting to install someitme. Yes, that's right, the Alpha one beat i386. Woohoo :-) If you can't find the link, let me know and I can do some digging. -- John Goerzen Linux, Unix consulting & programming [EMAIL PROTECTED] | Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | + The 1,029,878th digit of pi is 8. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
