On Tue, Nov 22, 2005 at 09:48:53AM +0100, Goswin von Brederlow wrote:
Aparently yes. Menu seems to be smart enough for that, see other
mails. Bad example, sorry. But manpages certainly aren't.
Well, being able to read the documentation (including the man page) of a
binary without requiring the
On Tue, Nov 22, 2005 at 12:21:37PM +0100, Thomas Hood wrote:
But the problem is that foo may produce output and this will break up the nice
single-line format. I don't mind deverting stdout to /dev/null, but I am
reluctant to divert stderr to /dev/null and error messages will also break up
On Sat, Nov 26, 2005 at 11:44:48AM +1100, Brian May wrote:
The Heimdal configure script correctly detects that glob() is present
in libc6, but appears to build glob.c anyway, and it also installs
glob.h.
It tests for the GLOB_QUOTE flag but that is not present in glibc, so it
decides that
On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote:
Given the need, and now the reality, of /run, is there any need for a
separate /var/run? I vote we migrate to /var/run - /run, at least in
the default install.
If /run is tmpfs, it means everything stored there eats virtual
On Sun, Dec 18, 2005 at 05:24:40PM +0100, Marco d'Itri wrote:
Reality check: packages have been using it for a long time and the world
has not fallen yet.
Emphasis on yet. /dev/shm was created to be used uniquely by shm_open(),
and violating this _will_ cause some problems after a certain
On Sun, Dec 18, 2005 at 01:03:37PM -0500, Joe Smith wrote:
1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm,
or that if it does exist, that it can be be read as a block device, or that
if it can, it has a file system on it.
AFAIK /dev/shm is just an internal detail
On Sun, Dec 18, 2005 at 06:54:42PM +, Andrew M.A. Cater wrote:
Will it work fine over a serial console? Is it fine for ex-Solaris/HP-UX
/AIX admins who may have got used to nvi?
As an ex-Solaris/AIX admin I can say that I used vim there too (except
when the filesystem containing vim did
On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
tmpfs stores run ressources in vm more efficiently (since they are otherwise
in th buffercache and the filesystem).
Quite the contrary. tmpfs needs vm space even if nobody needs the data
(thus, it could be evicted from the page
On Mon, Dec 19, 2005 at 01:14:45PM +0100, Marco d'Itri wrote:
But what about the future, and what about it being specifically for
POSIX-SHM?
Tell us... Do you have reasons to believe that we will be forced to
remove /dev/shm/ in the future?
If in the future glibc decides to choose some
On Sat, Dec 17, 2005 at 11:49:55PM +0100, Thomas Hood wrote:
A new version of sysvinit (binary packages sysvinit, sysv-rc and initscripts)
has
just been uploaded to experimental.
Just tried it on amd64.
After rebooting you should have logs of the fsck runs in
/var/log/fsck/check{root,fs}.
On Mon, Dec 19, 2005 at 07:40:24PM +0100, Bernd Eckenfels wrote:
Yes, we are talking about a few pages in swap space at most.
It's 55 pages (220k) on this machine (368k on ext3). And it's a simple
desktop with not much running state.
And I am not sure if not used is valid here, since symlinks
On Mon, Dec 19, 2005 at 09:12:22PM +0100, Marco d'Itri wrote:
There is no reason why it should be moved.
But there is a reason why its current abusers should get fixed to use
something else. Just think what happens if an app does something like
shm_open(/network, ...), or even better,
On Mon, Dec 19, 2005 at 09:11:42PM +0100, Marco d'Itri wrote:
The real lesson in this is that object names should be choosed
carefully.
Exactly. Therefore any object not created by shm_open() should not use
the /dev/shm/ path prefix. Glad you finally agree :-)
Gabor
--
On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote:
Putting R in / spoils the otherwise read-only character of that
directory. *shrug*
No, it's not. Mounting something over a top-level subdirectory does not
require / to be writeable.
That is, pretty much everything that runs as a
On Mon, Dec 19, 2005 at 03:33:35PM -0800, John H. Robinson, IV wrote:
One of the first things I do on any debian install is to install vim,
and set that to be a far higher priority for editor than anything else
imaginable.
Same here. That's why I do not care what the default editor in base is
On Mon, Dec 19, 2005 at 11:41:26AM -0800, Russ Allbery wrote:
Perhaps this is a bad idea (or perhaps this is even how it's already
done), but given the very limited number of things that would have to use
/run, would it be possible to write them all to use /var/run if it's
available and only
On Tue, Dec 20, 2005 at 09:23:05AM -0200, Henrique de Moraes Holschuh wrote:
Then IMHO Debian is NOT the appropriate system to run on that box. Get a non
glibc-based one that also likes to pass -Os to gcc and compiles the kernel
with -Os.
AFAIK -Os is not the upstream default for kernel
On Tue, Dec 20, 2005 at 12:13:15PM +0100, Thomas Hood wrote:
The new mountvirtfs prints such warnings for all the virtual
filesystems.
Where? I do not see any such checks in /etc/init.d/mountvirtfs. Also, to
be effective, such checks should run at level S99 in rc[2345].d and I do
not see
On Tue, Dec 20, 2005 at 12:19:16AM -0500, Glenn Maynard wrote:
Well, I get to use other people's systems now and then, and I'm always having
to ask people to install vim. If vim is the default, and configured to act
like vi by default, then people who like old vi get it, and people who like
On Tue, Dec 20, 2005 at 09:09:27AM +, Roger Leigh wrote:
Wouldn't that break mtab, or will that be moved under /var at the end
of booting?
It can be moved. Using mount --bind even the mount binary does not need
to be modified for the new location.
Gabor
--
On Tue, Dec 20, 2005 at 03:42:56PM +1000, Anthony Towns wrote:
For (a) you just need to wait until S10checkroot.sh has finished.
For (b) you need to wait until S35mountall.sh has finished.
I really like storing the fsck logs and that requires a writable place
before S10checkroot.sh finishes.
On Tue, Dec 20, 2005 at 12:45:13AM +0100, Frans Pop wrote:
Did you move bootlogd init script before udev? That should at least get
you a log and allow you to check the rest.
That worked, thanks. However, I just compared the contents of
/dev/.static/dev and /dev and I cannot see any device
On Tue, Dec 20, 2005 at 10:09:43PM +1000, Anthony Towns wrote:
The other aspect is that /var's the place for stuff that varies during
normal use; introducing some other place for the same thing is redundant
and thus more complex.
The more I think about it, the usage of /run matches /tmp much
On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote:
[1] Dark blue on black. Need I say more?
That's not vim's fault:
$ echo $TERM
xterm
But this is gnome-terminal, and _not_ xterm. xterm used a white
default background since prehistoric times, so when vim detects
On Tue, Dec 20, 2005 at 10:46:33PM +1000, Anthony Towns wrote:
Likewise, how do you document the mounting of /run in mtab?
If you start with a read-only /, then no matter what you do, the first
mount command will not be recorded in mtab (unless you implement a mount
daemon that holds mtab in
On Thu, Dec 22, 2005 at 05:18:43PM +1100, Russell Coker wrote:
Putting system directories under /tmp is a really bad idea, it opens
possibilities of race condition attacks by unprivileged users against system
processes. Generally for almost everything we should be looking to reduce
usage
On Thu, Dec 22, 2005 at 05:09:02PM +1100, Russell Coker wrote:
368K is an issue on a machine with 8M of RAM, it's an annoyance if you have
16M, beyond about 32M it stops being a problem.
Yeah, and a new optimization step only takes a few thenth of a second and
only a few extra KB of memory,
On Wed, Dec 21, 2005 at 07:29:16PM +, Darren Salt wrote:
I'd call that broken, just as I consider udev (076) to be broken given that
it breaks expectations wrt device naming. (Here, it swapped the names of the
DVD drives (drivers are built-in) and sound devices (drivers are modular).)
But
On Mon, Jan 02, 2006 at 08:19:30PM +0100, Adrian von Bidder wrote:
'just plug' is the watchword. New device model just needs a reboot - in
some circumstances device numbering is random without hardware changes and
without software changes.
So it exposes a bug more frequently than before. So
On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote:
But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev
and it works.
AFAIK it should work with the default ruleset. It breaks only with
certain custom rules due to a bug in the libsysfs version used by udev.
So,
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw)
wrote:
Perhaps the idea of maintain a kernel with other distros is not bad,
if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire,
Xandros, DCC Alliance Fan Club and also other Debian
On Tue, Jan 03, 2006 at 10:43:55PM +0100, Julien BLACHE wrote:
I wonder how that's going to happen wrt udev and a couple of other
things that, as of today, depend on a precise version of the kernel.
The udev breakages were rather annoying but the situation is not as bad
as it looks. ALSA for
On Wed, Jan 04, 2006 at 11:52:58AM +0100, Josselin Mouette wrote:
Furthermore, udev doesn't bring new problems. You can't have a
persistent naming scheme with a static /dev either, unless you are
loading modules by hand. If you still want to load your modules by hand,
udev won't prevent you
On Wed, Jan 04, 2006 at 02:19:31PM +0100, Steinar H. Gunderson wrote:
udev has broken my system -- completely (as in: can't boot and/or log in) --
_seven_ distinct times since this summer. How on you can claim that ALSA is
worse, is beyond me :-)
That's why I said udev breakage is rather
On Wed, Jan 04, 2006 at 02:26:51PM +0100, Maximilian Attems wrote:
the -rc kernels are build in experimental, staging area for unstable
and without any potential d-i breakage.
Ah, nice, I did not notice it. Perhaps it should get some more publicity
to attract more testers :-)
Gabor
--
On Mon, Jan 09, 2006 at 03:03:07PM +0100, Moritz Muehlenhoff wrote:
I've heard that gpdf is to be replaced by evince in GNOME, which
already links dynamically, so it's probably best to remove it for Etch.
While evince is nice it is unfortunately unbearably slow compared to
gpdf/gv/acroread
Hi,
On Fri, Feb 10, 2006 at 12:09:40PM +0100, Hendrik Sattler wrote:
Is there any preference on which type should be included in the -dev package?
I would prefer PDF:
* one file only
* easy to print
* many viewers available
I would rather not build all three as this is a definite
On Tue, Feb 14, 2006 at 08:37:26AM +1000, Andrew Pollock wrote:
I realise that update-inetd needs to be more flexible than just servicing
xinetd and netkit-inetd style configurations though...
What do you mean by more flexible? IMHO update-inetd should implement
just the minimum needed for
On Thu, Feb 16, 2006 at 10:04:25AM +0100, Javier Fernández-Sanguino Peńa wrote:
Moreover, I know of *no* -doc packages that provide SGML format so there
is not that much experience (or tools) on how to automatically do what others
suggest (dwww integratin).
IMHO SGML is losing ground in favor
On Fri, Feb 17, 2006 at 12:57:54AM +0100, Javier Fernández-Sanguino Peńa wrote:
And if the administrators choice is to not want any automatically created
formats, he may use a docbook program that displays it from the SGML or XML
source. Why not, such a tool may exist at one time or maybe
On Fri, Feb 17, 2006 at 02:33:47PM +0100, Javier Fernández-Sanguino Peńa wrote:
Show me a *documentation* package (i.e. those that install documentation
under /usr/share/doc/ and use doc-base's install-docs to register
documentation files [1]) that uses that. You are pointing me to a help
On Sat, Feb 25, 2006 at 05:01:25PM +0100, Michelle Konzack wrote:
If I have a hardware which comes with a CD/DVD/Floppy with the firmware
and there is a free firmware loader but it must stay in contrib it will
not realy productiv. It is a big disavantage.
Why? I've been using Debian for
On Tue, Feb 28, 2006 at 08:59:46AM +, Brian M. Carlson wrote:
[0] In case you're unsure, you can check the X-Spam-Status header, which
will tell you that I am an LDOSUBSCRIBER, in which case you can assume
Just nitpicking: there is no X-Spam-Status: header in my copy; however,
there is a
On Tue, Feb 28, 2006 at 10:20:30AM +0100, Jesus Climent wrote:
For those of you who enjoy to live in the bleeding edge, have loads of free
time or just feel like helping a bit, there is a dspam package in experimental
waiting for your love.
Finally :-) Thank you for packaging it!
Please,
On Mon, Feb 27, 2006 at 10:04:59AM -0800, Adam McKenna wrote:
Taking it out of main moves us in the wrong direction if our goal is to
give our users a *usable* operating system, as opposed to some kind of
'proof of concept' OS that some people here seem to want to create, but
that the
On Tue, Feb 28, 2006 at 02:36:52PM +0100, Wouter Verhelst wrote:
The CIPE driver doesn't actually need hardware, since it is an
encryption layer. As such, I can use it as a test-case for ndiswrapper,
to find out how the latter works and to actually be able to test whether
I set it up
On Tue, Feb 28, 2006 at 05:46:07PM +0100, Wouter Verhelst wrote:
[...]
user applications can use the whole 4GB of virtual address space while the
kernel runs it's own AS.
[...]
Run make menuconfig; then, select Processor type and features, and
High Memory Support. Done.
The question was
On Wed, Mar 01, 2006 at 01:04:17AM +, Brian M. Carlson wrote:
I understand that different mail systems do different things (although I
hope you're not using qmail[0]).
Not on my desktop, but I have no control over the institute's central
services.
However, the code of conduct seems to
On Wed, Mar 22, 2006 at 11:29:01AM -0300, Gustavo Franco wrote:
FYI, GMemChunk (old and deprecated by the upstream) was reimplemented to
use GSlice, so no need to change or rebuild code to be affected due to buggy
code. I don't know exactly why asking GSlice to force allocate and free memory
On Tue, Mar 28, 2006 at 12:57:24PM +0200, Marco d'Itri wrote:
Does anybody have an opinion about this?
When udev is installed for the first time on a running system the
current /dev/log socket ends up in /dev/.static/ (which is not
world-readable) until the next reboot.
How about restarting
On Tue, Mar 28, 2006 at 06:15:27PM +0200, Marco d'Itri wrote:
Harder than it looks. There are multiple syslog daemons, how can the
package know which one is installed and needs to be restarted?
glibc already checks for more than 40 packages and restarts only those
that are installed. I doubt
On Mon, Apr 10, 2006 at 11:16:06AM +0200, Wouter Verhelst wrote:
* System users on a Debian system are created with the --system
argument. On reading the manpage, these users are called system
users, not Debian system users; so non-Debian software could very
well be using that by using
On Sun, Apr 16, 2006 at 07:19:40PM +0200, Pierre HABOUZIT wrote:
Give me a break. For one single package, it's already quite penible to
use experimental (to avoid to pull every single experimental package,
you have to edit your /etc/apt/preferences, and stuff like that), it's
not
On Thu, Apr 20, 2006 at 09:10:18AM +0200, Marco d'Itri wrote:
No, ifrename cannot be used with udev because it cannot know that the
name of an interface has changed and will not be able to correctly
deliver the hotplug events.
I do not understand how hotplug events enter the picture. I do not
On Thu, Apr 20, 2006 at 11:12:58AM +0200, Marco d'Itri wrote:
Result: programs run after ifrename (like ifupdown...) will get the old
name.
So what? The user deliberately asked for it. Also it seems easy to write
an udev rule to replace persistent-net-generator.rules using ifrename so
udev
On Thu, Apr 20, 2006 at 01:52:14PM +0200, Marco d'Itri wrote:
This does not make it less broken.
Why? Care to point out just one single feature that is broken, provided
that the interface is _not_ configured to be automatically brought up in
/etc/network/interfaces?
But it's not.
That's
On Thu, Apr 20, 2006 at 09:23:00PM +0200, Marco d'Itri wrote:
This looks like a bug in udev. It should not try to identify devices
based on names a user can and will change.
I think I missed which alternative design you are proposing.
AFAIK the only correct way to identify a network
On Fri, Apr 21, 2006 at 02:16:07PM +0200, Marco d'Itri wrote:
Too bad that it is not what the kernel reports in the hotplug events and
that there are no symlinks in sysfs to access a kobject by its ifindex.
Sending a patch RFC to LKML would be the first step to improve this.
What stops udev
On Thu, May 04, 2006 at 11:54:44PM -0400, Anthony DeRobertis wrote:
If gcc generally generates faster code with -Os than -O2, then isn't
that a gcc bug, in that the optimizations enabled by -O2 are incorrectly
picked?
The problem is, faster is not a well-defined term. Faster when? I can
well
On Mon, May 08, 2006 at 10:00:42AM +0100, Thiemo Seufer wrote:
You can surely explain why /bin/nologin is more secure than
/bin/false. I'm eager to learn.
I am curious why any of both would be more secure than /dev/null, a
place which makes it hard to smuggle an infected binary into.
If
On Mon, May 08, 2006 at 11:53:15AM +0100, Thiemo Seufer wrote:
Such a binary is completely broken, and it would fail in a similiar way
for any sort of file it has no execute permission for, not only for
$SHELL.
Sure, but that does not change the fact that it is a failure path that
is usually
On Mon, May 08, 2006 at 12:47:53PM +0100, Thiemo Seufer wrote:
So you expect systems to become exploitable by mounting /usr as noexec
when they provide some /usr/bin/foo shell?
Not actually expect, but I would not be _that_ suprised. Most programs
that care about the login shell tend to run as
On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote:
Does it also allow multiple versions of the same package to be
installed at the same time?
For example, multiple minor versions or multiple major versions?
I think that's not going to fly. Just think about the different
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
Why would that not fly?
Both versions of the arch-independent package could be installed at
the same time.
/usr/share/foo/bar can't point to two different files at the same time,
so you can't install multiple package versions
On Thu, May 11, 2006 at 06:12:42PM -0300, Daniel Ruoso wrote:
And what if dpkg knows about it and handle arch-independant packages in
a different way?
There is nothing dpkg can do. Package-1.0 has a hardcoded reference to
/usr/share/foo/bar (provided by some other package) and expects it to be
On Mon, May 15, 2006 at 01:18:47PM +0200, Goswin von Brederlow wrote:
e.g. /etc/x86_64-linux-gnu/pango/pango.modules
or /etc/pango/x86_64-linux-gnu.modules
I'd prefer the architecture be a suffix, e.g.
/etc/pango/pango.modules.x86_64.
I intend to file bugs about those in the future
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote:
That's great. Could you tell me how to use those so that script A uses
python 2.3 and script B uses python 2.4 without modifying the scripts?
That's trivial. Create a wrapper that somehow decides which python
version to run and
On Tue, May 16, 2006 at 06:02:58PM +0200, Romain Beauxis wrote:
Few things that I see:
-- FUSE goes throught userland - kernel - Userland so it:
** May be an overhead for all /usr/bin calls.
Sure. Every feature has a price. In reality I expect the dentry cache
and the page cache takes care
On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote:
Wait a second. How do you create the dir when the file already exists?
There was quite some talk on linux-kernel about
'every-file-is-a-directory' approaches when Reiserfs 4 was released.
Some said they'd like to see this
On Wed, May 17, 2006 at 10:44:21AM +0200, Goswin von Brederlow wrote:
Which is still stupid not to have in the kernel API as feedback from
the event manager and have insmod optionaly block.
For that to work you should make device discovery synchronous everywhere
in the kernel. That would be a
On Thu, May 18, 2006 at 03:23:44AM +0200, Goswin von Brederlow wrote:
But there will be times where the actual source version of debs for
each arch differs. Actualy at every upgarde that happens between arch1
getting unpacked and arch2 getting unpacked as well. Dpkg just has to
handle it in
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
What timeout? With feedback you would know exactly when it is done and
wouldn't have to poll.
Quoting Linus:
: It really is very hard to accept the blocking behaviour.
:
: Some things can take a _loong_ time to be ready,
On Thu, May 18, 2006 at 11:25:46AM +0200, Toni Mueller wrote:
yes: Please say *why* newer 2.6.x kernels actually do depend on udev
instead of hotplug.
1. They do not depend on it at all. 2.6.x kernels work just fine with a
static /dev as long as you don't need dynamic device creation. There
On Thu, May 18, 2006 at 04:50:44PM +0200, Wouter Verhelst wrote:
Install udev on my system - things break randomly and unreproducibly,
due to race conditions all over the place.
This is quite in line with what I said about userspace not being ready
for hotplug. The kernel can send the events
On Thu, May 18, 2006 at 05:01:53PM +0200, Goswin von Brederlow wrote:
Now the system randomly doesn't boot and instead of a 10 minute boot
time you have a 3 hour drive to reset the system and analyse that is
was just udev screwing you over.
Then introduce a timeout. Create
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
That is because udev is slower so the window of the race condition
gets increased many many times. Without udev you don't have to wait
for the mknod call to complete.
I think you got the speed comparison wrong: udev does
On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
The only other solution that keeps the asynchronisity is what Joey
suggested at the start: Instead of waiting/polling for udev events to
finish move the code into udev rules that get called asynchronously
when the devices
On Fri, May 19, 2006 at 03:17:20AM +0200, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh. Anything
else?
Alternatives break on a daily basis, I wouldn't trust them for something
as
On Fri, May 19, 2006 at 10:58:33AM +0200, Goswin von Brederlow wrote:
Local admins are already allowed to convert directories into links,
e.g. to move parts ot the directory tree to another disk.
According to Steve Langasek in
Message-ID: [EMAIL PROTECTED]
that's not allowed and you should use
On Mon, May 22, 2006 at 01:55:54PM +, Jörg Sommer wrote:
But what counts more in the comparison dash vs. bash is the shell
startup. And the shell is started for every script not name foo.sh.
Also, if init scripts will be really parallel (meaning lots of
concurrent scripts, not just 2-3),
On Tue, May 23, 2006 at 01:19:44PM +0200, Gabor Gombas wrote:
difference. Some very basic tests using callgrind show that bash uses
20-30 times more CPU cache than dash. And when things are running
Er, fat fingers. The difference is just 2-3 times.
Gabor
On Sat, May 20, 2006 at 01:58:14AM +0200, Adam Borowski wrote:
The interesting fact is that, contrary to what I expected, running
configure was improved by only about 1% on average.
That may come from the fact that configure uses only the most basic
shell constructs (it does not even use
On Wed, Jun 14, 2006 at 01:53:29AM +0300, Jari Aalto+mail.linux wrote:
Command line usage (or from Window manager menu):
call: x-spreadsheet
How would this be different from using the already-existing run-mailcap
command? And what happens if 95% of time I want to use one application
as
On Fri, Jun 30, 2006 at 03:42:12PM +0200, Martijn van Oosterhout wrote:
It is also used to compile contrib modules that are included in the
distribution. If you started using pkg-config you'd have introduced a
build dependancy on a GPL'd program in a BSD licenced package, not
exactly a good
On Fri, Aug 11, 2006 at 02:59:16PM +1000, Brian May wrote:
The second query is trying to find out all the groups root is in (is
it possible to skip this???).
Only if you either remove ldap from the groups: line in nsswitch.conf,
or you do not use any programs that call initgroups()/getgrent().
On Wed, Aug 24, 2005 at 05:36:43PM +0200, martin f krafft wrote:
I have two comments: udev is a device node manager, not a hook
system for generic actions to be taking when a device is plugged or
unplugged. RUN rules kinda make this possible, but udev is on the
right track of doing the wrong
On Wed, Aug 24, 2005 at 06:23:37PM +0200, Julien BLACHE wrote:
To be honest, I installed a laptop the other day, and udev works well
on it (sarge with a 2.6.12 kernel); but I probably won't be able to
upgrade the kernel without running into problems with udev, which is a
total pain.
I only
On Mon, Sep 19, 2005 at 08:12:49PM +0100, Alastair McKinstry wrote:
Interesting, but very specific to the caching example. There are other
useful parts of the proposal, too: e.g. if libraries are in ~/lib then
its easy to have $LD_LIBRARY_PATH=$HOME/lib work on multiple
applications
If
On Fri, Sep 23, 2005 at 02:47:58PM +0200, Christoph Haas wrote:
..warning: connect to mysql server foobar: Access denied for user
'whoever'@'localhost.localdomain' (using password: YES)
Well, I had seen several machines having 127.0.0.1
localhost.localdomain localhost in /etc/hosts and running
On Fri, Sep 23, 2005 at 08:01:05PM +0200, Christoph Haas wrote:
It appears like MySQL does that. It seems to check the IP address of the
connecting client to find the permissions in it's internal `users`
table. So it sees 127.0.0.1 and looks up localhost.localdomain which
it cannot find since
On Thu, Oct 06, 2005 at 07:31:37AM -0500, Steve Greenland wrote:
When proposing a variation from long-standing historical practice,
shouldn't the onus be on the on making the change? What problem does
'localhost.localdomain' solve? Why is is better than just 'localhost',
which has been common
On Thu, Oct 06, 2005 at 07:44:42PM +0200, Pierre Machard wrote:
I can not remember precisely. I think that at that time I was testing the
debian-installer and I saw it was taken a long while to boot. I saw
that my system had no FQDN (hostname -f). When you add .localdomain, the
FQDN is
On Fri, Oct 07, 2005 at 08:12:38AM +0200, Lionel Elie Mamane wrote:
Having the DNS and /etc/hosts give different results is asking for
trouble. RFC 1912 says that this discussion was had in the past and
the conclusion was localhost..
Note that that discussion was about appending the local
On Thu, Oct 06, 2005 at 12:44:34PM -0700, Russ Allbery wrote:
No, they won't, because INN ignores hostnames that do not contain a period
for the purposes of generating external identifiers, specifically to keep
from using things like localhost or other unqualified names that aren't
globally
On Fri, Oct 07, 2005 at 04:45:24AM +0200, Bernd Eckenfels wrote:
Those asumptions are not false, they are what they are: asumptions. If you
dont want to configure your system that way, just dont use it.
That is what I say: every Debian package that uses hostname -f is
bogus, because it relies
On Fri, Oct 07, 2005 at 07:10:07AM +0200, Stig Sandbeck Mathisen wrote:
Changing the canonical name of localhost is an arbitrary change that
breaks more than MySQL. It also violates the principle of least
astonishment.
Then fix those other broken things as well. If you want localhost-style
On Tue, Oct 11, 2005 at 03:51:15PM +0200, Josselin Mouette wrote:
2. The cure
A mmap()-able cache file format was proposed, and is generated by
gtk-update-icon-cache in /usr/share/icons/$theme/icon-theme.cache files.
It helps a lot to improve speed.
You mean
On Fri, Oct 07, 2005 at 11:18:57AM -0700, Russ Allbery wrote:
* Obtain the system host name with gethostname().
* Look up an IP address for that host with gethostbyname().
The bug is here. This is completely wrong but sadly very common
practice. It is common because it is portable and works
On Fri, Oct 07, 2005 at 04:15:18PM +0200, Christoph Haas wrote:
MySQL definitely chokes on localhost.localdomain. And although MySQL will
adopt to distributions using localhost.localdomain instead of localhost
doesn't mean it's correct. MySQL by default expects localhost as the
hostname
On Thu, Oct 13, 2005 at 12:35:11PM -0700, Jeff Stevens wrote:
1 -- When configuring DNS, 127.0.0.1 must resolve to localhost and vice
versa [1].
No, the RFC does not say must, it only says should (and it is not
even a SHOULD).
And regardless if localhost.localdomain is removed from /etc/hosts
1 - 100 of 303 matches
Mail list logo
