Re: Posting rejected - please read and agree to mailing list rules. (fwd)
The Debian FAQ, answer to question 2.1: Debian GNU/Linux is the result of a volunteer effort to create a free, high-quality Unix-compatible operating system, complete with a suite of applications. The free here has to do with freedom, not price. While I know that, and you know that, it might need to be clarified in the FAQ. As it stands, that paragraph has no indication that a) Debian GNU/Linux might cost money (and thus not be free by monetary standards), but b) can be modified and redistributed at will (and thus free by -part- of the LPF/FSF standards). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Please do not use Qt (fwd)
On Sat, 23 Nov 1996, Buddha Buck wrote: Of course the apps CAN be gpled! Even if they have to be linked against some commercial libs. Not by my reading of the GPL. There are hundreds of gpled Motif based pieces of software out there. Name 5.By your assertion, I could modify GNU Emacs to use Motif widgets, and distribute the modified version freely, under the GPL. I am certain that if I were to do that, one of the first people I would hear complaints from would be RMS himself. There is actually a Motif Version of Emacs called Motif Xemacs (used to be called Lucid Emacs) I just ckecked the copyright statement on the moste recent version (19.14) It definetlely is GPL! Interesting. I wasn't aware that a Motif version of Xemacs existed. I use Xemacs on both my Linux system at home and at school (on Solaris), and neither version uses Motif. Checking the Xemacs docs (I don't have the full source) seems to imply that it can be build using Motif, but definately doesn't require it. It also implies that in some respects (like scroll bar performance), Motif-less Xemacs is better anyway (the scroll bars are the only place I was able to find mention of Motif in the equivilant of /usr/lib/xemacs/etc on my system at school, I'm not able to check what I'm using at home. In any event, Motif is -not- required for Xemacs in the same way that Qt would be required for LyX. So even for the GNU purists it must be evident, that Qt is LESS restricting than the Xforms license. But it is still MORE restricting in key ways than the Xforms licence. You did not tell in which respect the Xforms license is less restricting than the Qt license! Please do so. Sure... I mistyped. I meant to type ...GPL. instead of ...Xforms license. The rest of the discussion I had described what you could do naturally under GPL but not with Qt with its licensing the way it is now, thus demonstrating that the Qt license was more restrictive than GPL. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: How to choose safe configuration at boot time?
I am unable to use my Debian Linux system after the major update I did
on Tuesday.
WHAT HAPPENED: I used dselect in an xterm window under XFree to update the
system after an idle period of 1 week. I update from stable, unstable,
contrib, and nonfree. I allowed one of the installers to shut down xdm,
which led to a reboot. I finished the installation by starting dselect again
from an Xless console. The next reboot led to a login prompt on a non-X
console screen, flashing and ignoring all input, except for CTL-ALT-DEL
which led to another reboot ending in the same state.
WHAT I THINK IS WRONG: I think that my configuration of xdm is broken. The
last two outputs from the boot process, before the login prompt and the
flashing, are an indication that xdm is starting, and an indication that the
nas, which started earlier, has failed. The nas problem has been with me for
weeks, presumably has to do with a misconfigured SoundBlaster, and has never
before affected my ability to run X silently. Besides the install script
that shut down xdm for some change, I accidentally allowed another install
script to change the default X server (I had intended to experiment with
several X servers before deciding whether to change the default). One way or
another, I suspect that xdm is looping infinitely on a failed attempt to
start up X. I experienced similar behavior in an earlier incarnation, when X
failed due to lack of the right mouse driver, but in that case I saw some
failed attempts at driving the video in color, and now I see only on/off
flashing.
WHAT I THINK I NEED: I think that I need to boot the system in single-user
mode, or otherwise avoid starting up xdm, so that I can seek out the bad
configuration files and fix them. I have *only* Debian Linux on the system,
and I start it with LILO. I have been able to run several versions of the
kernel from LILO, including a very primitive one which I keep on a diskette
for emergencies. They all lead to the same behavior. Probably, there is an
appropriate option to give LILO, and it's probably mentioned in the online
documentation which I am now unable to read :^{ (I hope that this emoticon
portrays embarassment). In the past, I have used CTL-ALT-F1 to bring up a
single-user state, but I have been getting no useful response to this
signal, although it resets the phase of the flashing, so something is
evidently reading and ignoring it.
I'll be grateful for all suggestions. Useful ones will help me, and useless
ones will at least distract me from despair for a while :^)
Mike O'Donnell
[EMAIL PROTECTED]
http://www.cs.uiowa.edu/~odonnell
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: How to choose safe configuration at boot time?
I am unable to use my Debian Linux system after the major update I did
on Tuesday.
WHAT HAPPENED: I used dselect in an xterm window under XFree to update the
system after an idle period of 1 week. I update from stable, unstable,
contrib, and nonfree. I allowed one of the installers to shut down xdm,
which led to a reboot. I finished the installation by starting dselect again
from an Xless console. The next reboot led to a login prompt on a non-X
console screen, flashing and ignoring all input, except for CTL-ALT-DEL
which led to another reboot ending in the same state.
Something similar happened to me. I figured out what was wrong in my
case, which was similar.
In my case, because I knew that xbase required restarting X, I
intentionally stopped X before doing the install.
I also ran the new XF86Setup program, and configured it for my card, a
Cirrus 5426-based VLB video card. XF86Setup decided that probing my
dot clocks and adding a clocks line to the XF86Config file would be
a good thing. My video card doesn't need a clocks line, and in fact,
the X server won't run with it.
So at reboot, xdm starts up. It runs the X server, which finds the
problem with the configuration, and exits. So xdm starts it again.
It exits, and repeat.
I basically dealt with it by careful typing... (flash) r (blank)
(flash) o (blank) (flash) o (blank) (flash) t (blank) (flash) enter
(blank) (flash) and so on. It took me several attempts before I was
able to time -all- the needed keypresses in my password correctly
(that'll teach me to use a 11-character root password). But then I
was able to kill xdm, start X manually (and thus discover the
problem), and fix.
What happens is that while the VC is on the login prompt, it is
listening to the keyboard, but when X takes over, it switches the VC.
WHen I was able to finally kill it, the other VC contained all of my
mistimed keystrokes.
WHAT I THINK IS WRONG: I think that my configuration of xdm is broken. The
last two outputs from the boot process, before the login prompt and the
flashing, are an indication that xdm is starting, and an indication that the
nas, which started earlier, has failed.
It is probably true that it is a misconfigured X server. That is
exactly what I saw causing my similar problems.
WHAT I THINK I NEED: I think that I need to boot the system in single-user
mode, or otherwise avoid starting up xdm, so that I can seek out the bad
configuration files and fix them.
This will work, but I was also very surprised that when upgrading X on
my system, the install scripts decided that starting XDM for me was
good. Even though I was in single-user mode.
I have *only* Debian Linux on the system,
and I start it with LILO. I have been able to run several versions of the
kernel from LILO, including a very primitive one which I keep on a diskette
for emergencies. They all lead to the same behavior. Probably, there is an
appropriate option to give LILO, and it's probably mentioned in the online
documentation which I am now unable to read :^{ (I hope that this emoticon
portrays embarassment). In the past, I have used CTL-ALT-F1 to bring up a
single-user state, but I have been getting no useful response to this
signal, although it resets the phase of the flashing, so something is
evidently reading and ignoring it.
When starting with LILO, hit the shift key to get a boot: prompt, then
type linux emergency, which will start it in single user mode.
Or try timing your keystrokes, like I did. (My system has a long
uptime I didn't want to ruin even when upgrading).
I'll be grateful for all suggestions. Useful ones will help me, and useless
ones will at least distract me from despair for a while :^)
Mike O'Donnell
[EMAIL PROTECTED]
http://www.cs.uiowa.edu/~odonnell
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: X11 bashing
Qt forbids anybody from modifying their source code. So what if they changed their license when they've gained enough momentum? As far as I understand it, you can release code with a new licence, but you cannot change the licence on released code. Thus, if they changed their licence we would be stuck with the older code. I don't believe that that is correct. As copyright owner, they can license it anyway they want. What they can't do, however, is change an existing license without the consent of the licnsee (you). If you have a license saying you can use it for noncommercial use without modification, they can't say that you can't use it for noncommercial use. However, they can issue a -new- license to modify it, if they wish. In other words, they can GPL the old code if they want. I believe something similar happens like that with gs from Alladin. Brian ( [EMAIL PROTECTED] ) --- Generated by Signify v1.01. For this and more, visit http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: static vs. dynamic - gimp
Hello all. I would like to install gimp. gimp-dmotif (dynamic) vs. gimp-smotif (static) I am using a standard debian install with X, tcp/ip ... I would like to know : q1 - how do I know if I can use the static version? You can use the static version. Whether or not you want to is another story. The difference is in how the two packages are linked. Gimp requires the use of the Motif libraries. However, the Motif libraries have restrictive distribution requirements. You must pay money for the shared version of the Motif libraries, but it is perfectly acceptable to distribute programs linked statically with the Motif libraries. The tradeoff is memory -- each copy of the static libraries gets loaded into memory for each statically linked program running, whereas for the shared libraries, only one copy of the library is loaded into memory regardless of the number of programs using it. In addition, each executable statically linked has a copy of the library on disk, as opposed to only one copy in the /usr/X11/lib directory. So the static version can be used by anyone -- it doesn't require the use of the costly shared Motif libraries. The dynamic version is only useful if you have the shared Motif libraries. q2 - given a choice between both, what version would be better or faster Are there any pros and/or cons to choosing one or the other when both are valid options for a given machine (i.e.. speed vs. size ... )? If you -can- use the dynamic version, you probably should. Since you will probably be using other Motif applications (else why would you have bought the libraries?), using shared libraries instead of static libraries will give you more free memory, less swapping, etc. However, if you -can't- use the dynamic version, then you need the static version. If you only have Debian stuff installed, then you don't have Motif installed. So in that case, you will need the static version. Thanx in advance ... Keep up the good work - it is greatly appreciated.
Re: Debian Logo?
Hi! Is there an official Debian Logo? I haven't found one. If not, we could start a Logo contest, just as the Linux Logo Contest. I'm just an administrator and not an artist, but perhaps we have some on this list! An logo would be nice for disk labels, CD covers, www.debian.org, etc. When I read the subject, and the first line, I completely misunderstood. Is there a Debian Logo package? By this, I mean the programming language Logo. (And before people complain that Logo is too frivolous a language to have in the distribution, remember we have an Intercal package already.) Later, BP
Re: Netiquette of requesting package updates
I was being purposely vague because I didn't want to single anyone out, but no, they're both popular text-only programs. One of them is behind by a minor version, the other by a major + 2 minors. No more clues. :) Of course, being purposefully vague only serves to annoy us... Which would you rather see as a maintainer, a note saying that some package that you may or may not maintain is behind, but they won't specify which package, or a note that tells you that your package is behind the upstream release? You should probably send a message to [EMAIL PROTECTED] (I -think- that's the address), with the line Package: packagename as the first line in the message. That will send a message only to the maintainer of the package in question, without the rest of us seeing it. Of course, if the newer upstream version of the package fixes important bugs, you might want to file a bug report on those bugs, mentioning tha the newer version fixes them. Or you could look through the bug report archives listed by package, and submit a comment on an existing bug if the upstream version fixes it. If there is a reason why the maintainer hasn't updated it (such as the newer upstream version is still in beta and isn't an official, public release, as is the case with libc5, which has a 5.3.x beta series in development), then he/she will likely tell you. Just some ideas, and no need to be purposefully vague.
