Re: question
On Tue, Nov 14, 2006 at 01:22:12PM -0800, walt wrote: > I had to make some emergency patches to get Thunar to build: > thunar-vfs-os-bsd.c:110: error: structure has no member named > `d_reclen' It should not use it at all. It is not portable or not needed. Joerg
question
I'm having fun playing with pkgsrc/wip/xfce4, which is the latest incarnation of xfce, version 4.3.99. I especially like Thunar, the low-calorie-back-to-basics gui file manager, which is very much in the original spirit of the xfce project. I had to make some emergency patches to get Thunar to build: thunar-vfs-os-bsd.c:110: error: structure has no member named `d_reclen' The offending code in several places uses dp->d_reclen, where dp is "struct dirent *dp;" After studying I substituted _DIRENT_DIRSIZ(dp) wherever dp->d_reclen appears. Much to my amazement, it all seems to work :o) My question, I guess, is whether my patching is the best way to fix the problem. I had to edit one file in four spots to make it compile, which seems a bit inconvenient for porting other applications to DF. (I dunno how many apps might use dirent.h).
Re: filesystem hierarchy
On Tue, Nov 14, 2006 at 09:56:59PM +0100, Eli Green wrote: > On 2006-11-14, Joerg Sonnenberger wrote: > >On Tue, Nov 14, 2006 at 08:57:02PM +0100, Eli Green wrote: > >>It seems to me that DragonFly is not very far from the stated goal of > >>having multiple libraries as it is, using varsyms or maybe a slightly > >>specialized version of nullfs: > > > >[snip] > > > >(a) As Jeremy said, this is something pkgviews tries/tried to do. > >(b) This is a *huge* maintainance hassle. > > > >It works for Debian using the 1000 monkeys approach, but it doesn't work > >for a reasonable large (as in: small) team. E.g. keep in mind that it > >means splitting a single package into small pieces for the static > >libraries, header files, associated programs etc., as everything but the > >shared lib will conflict in the filesystem. This is a wonderful > >nightmare. > > > > I don't understand why it would require packages to be broken up like > that. If anything, you wouldn't want that... the include directories > would be part of the same structure. Otherwise you start either symlink hell or can't support it with many packages as they simply expect a different structure. Joerg
Re: filesystem hierarchy
On 2006-11-14, Joerg Sonnenberger wrote: On Tue, Nov 14, 2006 at 08:57:02PM +0100, Eli Green wrote: It seems to me that DragonFly is not very far from the stated goal of having multiple libraries as it is, using varsyms or maybe a slightly specialized version of nullfs: [snip] (a) As Jeremy said, this is something pkgviews tries/tried to do. (b) This is a *huge* maintainance hassle. It works for Debian using the 1000 monkeys approach, but it doesn't work for a reasonable large (as in: small) team. E.g. keep in mind that it means splitting a single package into small pieces for the static libraries, header files, associated programs etc., as everything but the shared lib will conflict in the filesystem. This is a wonderful nightmare. I don't understand why it would require packages to be broken up like that. If anything, you wouldn't want that... the include directories would be part of the same structure. Two of the things I mentioned in my EuroBSDCon talk will make the issue much less pressing -- stay tuned for that :-) Well, it's not a pressing issue for me at all, I don't have any BSD-based servers because I work for a company with its head up its ass, technology-wise.
Re: filesystem hierarchy
On Tue, Nov 14, 2006 at 08:57:02PM +0100, Eli Green wrote: > It seems to me that DragonFly is not very far from the stated goal of > having multiple libraries as it is, using varsyms or maybe a slightly > specialized version of nullfs: [snip] (a) As Jeremy said, this is something pkgviews tries/tried to do. (b) This is a *huge* maintainance hassle. It works for Debian using the 1000 monkeys approach, but it doesn't work for a reasonable large (as in: small) team. E.g. keep in mind that it means splitting a single package into small pieces for the static libraries, header files, associated programs etc., as everything but the shared lib will conflict in the filesystem. This is a wonderful nightmare. Two of the things I mentioned in my EuroBSDCon talk will make the issue much less pressing -- stay tuned for that :-) Joerg
Re: filesystem hierarchy
:... :instead of /usr/pkg. This doesn't sound hard. Getting pkgsrc to convince :configure scripts to search the right directories for header files might :be trickier. Or, I guess it should just search /usr/pkg with the right :environment variables set. : :Is this sort of what you meant? Is there some glaring fatal flaw in this :scheme? I think it is all very doable, but the fatal flaw is one of maintainance. To work well the scheme (or any scheme) would have to be built into pkgsrc. We don't want to get into the business of having to maintain a major infrastructure piece of pkgsrc. Going with pkgsrc is really starting to reap rewards for us now. Yes, there are some glaring issues, like the lack of multiple version support, but all and all pkgsrc has been a huge benefit to the project. More and more major packages are working with DragonFly and when a package gets fixed now, it tends to stay fixed. We have to be careful to stay within the pkgsrc infrastructure and not try solo-hack it up to suit our needs. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: filesystem hierarchy
On 2006-11-14, Matthew Dillon wrote: : :Matthew Dillon wrote: :> At the moment we have no plans to integrate package management :> directly into the filesystem layer. We do have tools already :> available (varsyms) to make this possible, and pkgsrc makes things :> easier by installing into /usr/pkg, leaving /usr/local available to :> the user. :> :> But, primarily, we are dependant on pkgsrc's installation management. : :Um, wasn't this planned for 1.8? I don't think so. pkgsrc is pkgsrc. We have no plans to hack it. I do recall Joerg mentioning multi-version libraries but I don't know if that's in his current plans or not. It is possible to create independant pkgsrc environments using NULLFS and/or varsyms. In particular, one could make /usr/pkg a varsym pointing to the correct directory (instead of just being a directory), and then use varsyms to create entirely independant pkgsrc environments for each major service running on the machine. I would personally like pkgsrc to have the ability to install multiple versions of a package, but that is support that the pkgsrc people would have to add, not us. Couldn't it be more granular than that? It seems to me that DragonFly is not very far from the stated goal of having multiple libraries as it is, using varsyms or maybe a slightly specialized version of nullfs: foo-1.0 depends on libfoo-1.0 bar-1.0 depends on libfoo-1.1 /pkg/foo/1.1 /pkg/bar/1.0 /pkg/libfoo/1.0 /pkg/libfoo/1.1 then /usr/pkg is just a collection of symlinks, where: /usr/pkg/bin/foo -> /pkg/foo/$foo_version/bin/foo /usr/pkg/bin/bar -> /pkg/bar/$bar_version/bin/bar /usr/pkg/lib/libfoo.so -> /pkg/libfoo/$libfoo_version/lib/libfoo.so This is all stuff that's supported right now. The only magic is that instead of doing straight symlinks for the executables up there, they would be shell scripts that would go through all the dependencies of that executable and set the $foo_version, $bar_version and $libfoo_version accordingly. In fact, they could all link to a single executable that checked argv[0], figured out which package was being called (based on already-set environment variables or choosing the latest version if none are set) and then set the version numbers. The idea here (in my mind) would be to make this scheme co-exist with pkgsrc by just having pkgsrc install to /pkg/$pkgname/$pkgversion instead of /usr/pkg. This doesn't sound hard. Getting pkgsrc to convince configure scripts to search the right directories for header files might be trickier. Or, I guess it should just search /usr/pkg with the right environment variables set. Is this sort of what you meant? Is there some glaring fatal flaw in this scheme?
Re: filesystem hierarchy
> I would personally like pkgsrc to have the ability to install multiple > versions of a package, but that is support that the pkgsrc people would > have to add, not us. That feature existed a couple years ago. It is called "pkgviews". And I used it myself. It was experimental and not widely used. Over the past year, some changes broke it. (I don't know what.) Nobody noticed (at least nobody publicly mentioned it) until I reported it a month or two ago. I think the support for installing multiple versions of a package will be coming back soon. As it is now, someone can easily have multiple PKG_DBDIR (default /var/db/pkg) and LOCALBASE (default /usr/pkg) to have multiple installations of same package. Some pkgsrc users already use that. And just adjust symlinks to /usr/pkg and/or adjust users' PATH (and MANPATH) as needed. The minor problem is you may have multiple copies of identical dependencies.
Re: filesystem hierarchy
: :Matthew Dillon wrote: :> At the moment we have no plans to integrate package management :> directly into the filesystem layer. We do have tools already :> available (varsyms) to make this possible, and pkgsrc makes things :> easier by installing into /usr/pkg, leaving /usr/local available to :> the user. :> :> But, primarily, we are dependant on pkgsrc's installation management. : :Um, wasn't this planned for 1.8? I don't think so. pkgsrc is pkgsrc. We have no plans to hack it. I do recall Joerg mentioning multi-version libraries but I don't know if that's in his current plans or not. It is possible to create independant pkgsrc environments using NULLFS and/or varsyms. In particular, one could make /usr/pkg a varsym pointing to the correct directory (instead of just being a directory), and then use varsyms to create entirely independant pkgsrc environments for each major service running on the machine. I would personally like pkgsrc to have the ability to install multiple versions of a package, but that is support that the pkgsrc people would have to add, not us. -Matt Matthew Dillon <[EMAIL PROTECTED]>
ipw3945 WLAN driver
Hi, are there plans to port the ipw3945 driver from OpenBSD in the near future? Thomas
Re: DFly vs other BSD
Haidut pravi: I am currently trying to run some benchmarks for PostgreSQL and MySQL running on Dfly 1.6.2, PC-BSD (FreeBSD 6.1/6.2), NetBSD 3.1, OpenBSD 4.0, and Linux 2.6.x (Ubuntu). I've yet to find MySQL benchmarking tools that compile and run on all of the above OS but "pgbench" for PostgreSQL runs fine and so far it looks like it runs considerably faster on Dfly than FreeBSD. Please note that there is no kernel postgresql runs great on Dfly. DFly 1.2.x is still very nice and stable postgresql platform. Uptime almost a year on production SMP box.
Re: Java is open source finally
On Wed, Nov 15, 2006 at 12:48:21AM +1100, Petr Janda wrote: > https://openjdk.dev.java.net/ > > Now we can have a working JDK/JRE in DragonFly :-) It doesn't change anything. It was open source before, just not free software. Joerg
Java is open source finally
https://openjdk.dev.java.net/ Now we can have a working JDK/JRE in DragonFly :-) Petr
Re: Java is open source finally
AFAIU, it only changes the policy of distribution of binaries?
Re: [patch] Multiple ips for jails
Joerg Sonnenberger wrote: On Tue, Nov 14, 2006 at 10:00:54AM +0100, Simon 'corecode' Schubert wrote: Joerg Sonnenberger wrote: At least the IPv6 case is incomplete as it doesn't deal with mapped ipv4 addresses. I also don't think the behaviour for INADDR_ANY is correct. Could you elaborate on that? How should mapped ipv4 addresses be handled? I guess there would need to be a check for already used ipv4 addresses, and vice versa. If mapped IPv4 addresses are allowed, they should get exactly the same handling as normal IPv4 addresses. Esp. mapped 127.0.0.1 needs to be handled accordingly. yes, I agree. What behaviour for INADDR_ANY would be correct? (If you can use this term) When a socket is allowed to bind to INADDR_ANY two things have to be guarantied: (a) Connections to it are effectively only allowed, when one of the jail IPs can be used. E.g. if the jail is bound to 192.168.1.1 and 10.1.1.1, but the machine has also 176.1.1.1 as IP, a connection to that must not go to the jail. (b) Connections *from* the jail must use one of the jail addresses as source. E.g. when the jail is bound to 192.168.1.1 as before, a connection to 10.1.1.2 must not use 10.1.1.1 as soure address. as far as i can tell, the patch was designed to do exactly what you are describing. This gets further complicated by the question whether or not binding to broadcast and/or multicast addresses should be enabled by default. I don't know how this is handled at the moment, but I am confident that this could even be handled when the code is committed. As long as the old behaviour persists with just one IP, it is fine. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: DragonFly on a Intel G965 Mainboard
Am 14.11.2006 um 08:48 schrieb Joerg Sonnenberger: On Mon, Nov 13, 2006 at 06:30:45PM +0100, Markus Hitter wrote: Still I think an option to run DragonFly off BIOS drivers would be a good thing. Hardware changes every few months and if the bootloader works, why shouldn't the remaining OS? Performance is a secondary issue. The performance would be completely unusable. While the performance would suffer for sure, it would be the only option to run DragonFly on not-yet-supported hardware. Gentoo features such an option, lets you boot all up into Gnome and performance is reasonable for viewing documents, compiling drivers or even editing OpenOffice stuff. You get something like 1 MB/s disk throughput at full processor speed. For the records, Gergo asked me to switch off "Plug & Play support", but recent BIOSs for this Intel board (and likely all other current Intel boards) don't feature such an option. Luckily, I got DFly installed with Qemu 0.8.2 yesterday, running on top of Windows 2000. Next step would be to get an development environment up, but any suggestions are welcome. Even the loader already has to jump through a few loops to use the BIOS -- you certainly don't want to do that for the normal system. How about jumping three steps into the future and to use EFI drivers? From what I read on osx86.org, Intel offers an EFI emulator for BIOS systems and EFI is capable enough to allow OS-provided device drivers. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: [patch] Multiple ips for jails
On Tue, Nov 14, 2006 at 10:00:54AM +0100, Simon 'corecode' Schubert wrote: > Joerg Sonnenberger wrote: > >At least the IPv6 case is incomplete as it doesn't deal with mapped ipv4 > >addresses. I also don't think the behaviour for INADDR_ANY is correct. > > Could you elaborate on that? How should mapped ipv4 addresses be handled? > I guess there would need to be a check for already used ipv4 addresses, and > vice versa. If mapped IPv4 addresses are allowed, they should get exactly the same handling as normal IPv4 addresses. Esp. mapped 127.0.0.1 needs to be handled accordingly. > What behaviour for INADDR_ANY would be correct? (If you can use this term) When a socket is allowed to bind to INADDR_ANY two things have to be guarantied: (a) Connections to it are effectively only allowed, when one of the jail IPs can be used. E.g. if the jail is bound to 192.168.1.1 and 10.1.1.1, but the machine has also 176.1.1.1 as IP, a connection to that must not go to the jail. (b) Connections *from* the jail must use one of the jail addresses as source. E.g. when the jail is bound to 192.168.1.1 as before, a connection to 10.1.1.2 must not use 10.1.1.1 as soure address. This gets further complicated by the question whether or not binding to broadcast and/or multicast addresses should be enabled by default. Joerg
Re: [patch] Multiple ips for jails
On Tue, Nov 14, 2006 at 11:31:57AM +0100, Joerg Sonnenberger wrote: > On Tue, Nov 14, 2006 at 10:00:54AM +0100, Simon 'corecode' Schubert wrote: > > Joerg Sonnenberger wrote: > > >At least the IPv6 case is incomplete as it doesn't deal with mapped ipv4 > > >addresses. I also don't think the behaviour for INADDR_ANY is correct. > > > > Could you elaborate on that? How should mapped ipv4 addresses be handled? > > I guess there would need to be a check for already used ipv4 addresses, and > > vice versa. > > If mapped IPv4 addresses are allowed, they should get exactly the same > handling as normal IPv4 addresses. Esp. mapped 127.0.0.1 needs to be > handled accordingly. The mapped ipv4 addresses needs further investigation, i'll check it ASAP. > > > What behaviour for INADDR_ANY would be correct? (If you can use this term) > > When a socket is allowed to bind to INADDR_ANY two things have to be > guarantied: > (a) Connections to it are effectively only allowed, when one of the jail > IPs can be used. E.g. if the jail is bound to 192.168.1.1 and 10.1.1.1, > but the machine has also 176.1.1.1 as IP, a connection to that must not > go to the jail. This is already guaranteed. > (b) Connections *from* the jail must use one of the jail addresses as > source. E.g. when the jail is bound to 192.168.1.1 as before, a > connection to 10.1.1.2 must not use 10.1.1.1 as soure address. > > This gets further complicated by the question whether or not binding to > broadcast and/or multicast addresses should be enabled by default. Multicast is not supported in jails. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros.
Re: [patch] Multiple ips for jails
Joerg Sonnenberger wrote: At least the IPv6 case is incomplete as it doesn't deal with mapped ipv4 addresses. I also don't think the behaviour for INADDR_ANY is correct. Could you elaborate on that? How should mapped ipv4 addresses be handled? I guess there would need to be a check for already used ipv4 addresses, and vice versa. What behaviour for INADDR_ANY would be correct? (If you can use this term) cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
