Unpopulated subdirectories for amd64
Hi, I'm learning the DFBSD community website. I've found that .../stable/... subdirectories are unpopulated contrary to .../stable/All. See .../stable/graphics and others. http://avalon.dragonflybsd.org/packages/amd64/DragonFly-2.7/stable/All/ Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpl7aBPec0Ek.pgp Description: PGP signature
Re: Bug on www man pages
* Tomas Bodzar wrote: Hi all, it's not possible to display dhcpd(8) man page either from there http://leaf.dragonflybsd.org/cgi/web-man or from any other link like from this page http://leaf.dragonflybsd.org/cgi/web-man?command=dhcpsection=ANY Yes, this is correct. We do not ship dhcpd in base, so there is no man page in the base system and thus you cannot see it online. We put the pkgsrc dhcpd package on the live cd and thus on every new system. Cheers Matthias
example of dfbsd deployment or product that based on dfbsd
Hi, I just have interest in DFBSD and have some questions. Can someone give me examples of some big/great DFBSD deployment or some product that based of DFBSD ? Is DFBSD proven to be rock solid in real world ? Thanks
Misleading directory names
Hi, Listing from http://avalon.dragonflybsd.org/packages/ Name Last modified Size Description Parent Directory - README 18-May-2010 02:45 1.3K amd64/ 24-Aug-2010 23:56- i386/27-Sep-2010 20:59- x86_64/ 24-Aug-2010 23:56- Why there are two __identical__ directories under __two__ different names which stand for the same contents? Excerpt from README: What's here The i386 directory contains packages built on 32-bit DragonFly systems. The amd64/x86_64 directores contains packages built on 64-bit DragonFly systems. (amd64 and x86_64 are the same thing here) ^^^ Why the mess? Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpNqSIYjAEiM.pgp Description: PGP signature
Re: Misleading directory names
2010/9/28 Przemysław Pawełczyk pp...@o2.pl: Hi, Listing from http://avalon.dragonflybsd.org/packages/ Name Last modified Size Description Parent Directory - README 18-May-2010 02:45 1.3K amd64/ 24-Aug-2010 23:56 - i386/ 27-Sep-2010 20:59 - x86_64/ 24-Aug-2010 23:56 - Why there are two __identical__ directories under __two__ different names which stand for the same contents? Excerpt from README: What's here The i386 directory contains packages built on 32-bit DragonFly systems. The amd64/x86_64 directores contains packages built on 64-bit DragonFly systems. (amd64 and x86_64 are the same thing here) ^^^ Why the mess? Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl Our x86_64 branch used to be called amd64, it's just legacy. Sam
Re: Misleading directory names
Hi Prezemylaw, I know no OS which is finished. There's always things to do ;) Besides that I think the amd64 symlink could be removed as there's no 2.6/2.7 release with arch. name, but it isn't either a big deal. Cheers, Antonio Huete 2010/9/28 Przemysław Pawełczyk pp...@o2.pl: On Tue, 28 Sep 2010 03:30:28 -0600 Samuel J. Greear s...@evilcode.net wrote: 2010/9/28 Przemysław Pawełczyk pp...@o2.pl: Hi, Listing from http://avalon.dragonflybsd.org/packages/ Name Last modified Size Description Parent Directory - README 18-May-2010 02:45 1.3K amd64/ 24-Aug-2010 23:56 - i386/ 27-Sep-2010 20:59 - x86_64/ 24-Aug-2010 23:56 - Why there are two __identical__ directories under __two__ different names which stand for the same contents? Excerpt from README: What's here The i386 directory contains packages built on 32-bit DragonFly systems. The amd64/x86_64 directores contains packages built on 64-bit DragonFly systems. (amd64 and x86_64 are the same thing here) ^^^ Why the mess? Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl Our x86_64 branch used to be called amd64, it's just legacy. Sam Hi, 1. Having DFBSD so young and calling former releases a legacy is kinda hoity-toity. ;-) AFAIK the DFBSD is not __finished__ yet so former versions were at best development releases. 2. Would you put the information about legacy into every nook and cranny of DFBSD documentation? Nope. What's the purpose then to litter DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be bygones. ;-) Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl
Re: Misleading directory names
* Przemys??aw Pawe??czyk wrote: 1. Having DFBSD so young and calling former releases a legacy is kinda hoity-toity. ;-) AFAIK the DFBSD is not __finished__ yet so former versions were at best development releases. At least a lot of people have DragonFly running on a lot of machines in production environments. All backend servers in our working group are based on DF. 2. Would you put the information about legacy into every nook and cranny of DFBSD documentation? Nope. What's the purpose then to litter DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be bygones. ;-) There might be older installations out in the wild whose tools depend on the amd64/ link, e.g. pkg_radd/pkg_search. So what's the issue with having two entries with the same target in the directory of a mirror server? Even if there is a README which explains that amd64 == x86_64. *scratcheshishead* Matthias
Re: Misleading directory names
On Tue, 28 Sep 2010 12:14:52 +0200 Matthias Schmidt matth...@dragonflybsd.org wrote: (...) 2. Would you put the information about legacy into every nook and cranny of DFBSD documentation? Nope. What's the purpose then to litter DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be bygones. ;-) There might be older installations out in the wild whose tools depend on the amd64/ link, e.g. pkg_radd/pkg_search. So what's the issue with having two entries with the same target in the directory of a mirror server? Even if there is a README which explains that amd64 == x86_64. *scratcheshishead* Doesn't it seem to you like being a bit untidy? And, btw, for how long the legacy will be going on...? With so much changes between 2.6.3 and 2.8.0? Do you really think/know that the legacy systems will be kept running yet after new release (which one)? Manpower shortages define status quo, no doubt about it, as pkg_radd/pkg_search are still unchanged with amd64 links. I tell you sincere, I made research, my posts may testify, how far the system is mature - of course on my terms, not DFBSD developers'. And I didn't buy the production ready hype. Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpzjpDabtbnn.pgp Description: PGP signature
Re: Misleading directory names
On 28/09/10 11:44, Przemysław Pawełczyk wrote: A real example - I installed DFBSD and I wanted to have some applications too. I went to the page: http://www.dragonflybsd.org/docs/howtos/HowToPkgsrc/#index4h2 There is setenv PKG_PATH .../i386/... defining the path to packages' database. For whatever it's worth, if you just mentioned the actual problem first instead of criticizing that there are two different directories for the same architecture on a mirror, your criticism/comments would be very useful from the start. I much appreciate that you let us know which issues you find but raising the actual issue instead of talking around it and only getting to it 3 mails later isn't as useful as it could be. Regards, Alex
Re: Misleading directory names
On Tue, 28 Sep 2010 11:59:02 +0100 Alex Hornung ahorn...@gmail.com wrote: On 28/09/10 11:44, Przemysław Pawełczyk wrote: A real example - I installed DFBSD and I wanted to have some applications too. I went to the page: http://www.dragonflybsd.org/docs/howtos/HowToPkgsrc/#index4h2 There is setenv PKG_PATH .../i386/... defining the path to packages' database. For whatever it's worth, if you just mentioned the actual problem first instead of criticizing that there are two different directories for the same architecture on a mirror, your criticism/comments would be very useful from the start. I much appreciate that you let us know which issues you find but raising the actual issue instead of talking around it and only getting to it 3 mails later isn't as useful as it could be. Regards, Alex That's the same problem Round Robin - whether to keep the info short as everybody else is quick-witted and thus any further discription would be unwelcome (offending), or put it in broader context from the start. I have chosen a middle road - first short message, then description if it would be necessary. Anyway, I will think over your remarks. Thanks. Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpkXorzuwH8q.pgp Description: PGP signature
Re: example of dfbsd deployment or product that based on dfbsd
On Tue, 28 Sep 2010 13:46:13 +0200 Tomas Bodzar tomas.bod...@gmail.com wrote: Starting with Google and archives is every time good idea : http://leaf.dragonflybsd.org/mailarchive/users/2010-09/msg00018.html http://leaf.dragonflybsd.org/mailarchive/users/2010-09/msg00026.html On Tue, Sep 28, 2010 at 9:54 AM, Iwan Budi Kusnanto iwan.b.kusna...@gmail.com wrote: Hi, I just have interest in DFBSD and have some questions. Can someone give me examples of some big/great DFBSD deployment or some product that based of DFBSD ? Is DFBSD proven to be rock solid in real world ? Hi, I would add the following e-mail by Mr Siju George: Re: Why did you choose DragonFly? http://leaf.dragonflybsd.org/mailarchive/users/2010-09/msg00083.html Follow up the hyperlinks included in the post. Regard them as a MUST. :-) Regards -- Przemysław Pawełczyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl pgpUdBmuFqMOd.pgp Description: PGP signature
Re: Misleading directory names
Przemys?aw Pawe?czyk wrote: On Tue, 28 Sep 2010 12:14:52 +0200 Matthias Schmidt matth...@dragonflybsd.org wrote: (...) 2. Would you put the information about legacy into every nook and cranny of DFBSD documentation? Nope. What's the purpose then to litter DFBSD and mirror servers with the Doublespeak? ;-) Let bygones be bygones. ;-) There might be older installations out in the wild whose tools depend on the amd64/ link, e.g. pkg_radd/pkg_search. So what's the issue with having two entries with the same target in the directory of a mirror server? Even if there is a README which explains that amd64 == x86_64. *scratcheshishead* Doesn't it seem to you like being a bit untidy? And, btw, for how long the legacy will be going on...? With so much changes between 2.6.3 and 2.8.0? Do you really think/know that the legacy systems will be kept running yet after new release (which one)? Manpower shortages define status quo, no doubt about it, as pkg_radd/pkg_search are still unchanged with amd64 links. I tell you sincere, I made research, my posts may testify, how far the system is mature - of course on my terms, not DFBSD developers'. And I didn't buy the production ready hype. Regards -- Przemys?aw Pawe?czyk (P2O2) [pron. Pshemislav Paveltchick] http://pp.blast.pl, pp...@o2.pl O.k. I understand you dont like our documentation.. We welcome Ideas and Suggestions about such things. Dfly is new? not really.. for the record.. when I worked at a small isp in atlanta, ga we had a box that had been running for several years without issue. we upgraded software on it.. we did a lot of stuff on it.. however it was never rebooted. legacy systems in the real world exist. We will continue to support those legacy systems. We have done so in many ways including abi support for old binaries. Now to the issue, the real issue I have so far avoided this discussion, for fear that I would say something I shouldnt. Its this simple... sometimes I wish we had the old installer back... the one where you had to manually set everything up.. and cpdup the filesystem over by hand. This pretty much seperated out the poeple who went to install something and complain about every issue they might find with it. I understand that a operating system without users is pretty useless. However berating the developers of that o.s. is pretty useless as well. There will be a day if you continue using Dfly that you will need answers, and the only onees who can provide them are the people that have been insulted in your messages. So tone it down, ask for help, point out the issues you find in a friendly manner and you will find them corrected very quickly. Continue the path that these messages have been headed down, and you will have guys arguing against changes that we should make. Just because you suggested them. Sincerely, Robert Garrett
libthread_xu: FAULT VALUE CHANGE
I triggered the following message printed so stderr for my program (C++, boost::asio, threads, SMP/2cpu) thr_umtx_wait: FAULT VALUE CHANGE 0 - 1 oncond 0x282f0314 thr_umtx_wait: FAULT VALUE CHANGE 0 - 1 oncond 0x282f0344 thr_umtx_wait: FAULT VALUE CHANGE 0 - 1 oncond 0x282f032c What is it? I found lines in source doing fprintf (libthread_xu/thread/thr_umtx.c, line 140), but I not quite understand what happens. Is it harmful and worth debugging, or I should just ignore this? 2.6-RELEASE DragonFly v2.6.3.43.gb67e7
Re: Misleading directory names
On Tue, September 28, 2010 6:58 am, PrzemysÅaw PaweÅczyk wrote: Doesn't it seem to you like being a bit untidy? And, btw, for how long the legacy will be going on...? With so much changes between 2.6.3 and 2.8.0? Do you really think/know that the legacy systems will be kept running yet after new release (which one)? Manpower shortages define status quo, no doubt about it, as pkg_radd/pkg_search are still unchanged with amd64 links. I appreciate what you're saying about having things be clear to users, but this is the alternative to something that would be more confusing. 'amd64' was hardcoded into a number of package tools, including early versions of pkg_radd. The choice is either leave it untidy with a note about the reason for the directory, or break functionality for older machines. Someone was still running a number of 2.0 machines in an environment that couldn't be easily upgraded, last I asked about this, so untidy is a better choice, in this case. The long-term answer that I would prefer is to not have people need to navigate a package hierarchy at all, and instead have the appropriate software selected automatically. We're closer to that with the pkg_radd tool.
Re: Misleading directory names
Justin, How would anyone be using amd64 directory for 2.0 if we didn't have it back then? Anyways this is not a big issue in my opinion. amd64 is a directory and x86_64 a symbolic link to it. It only contains packages for 2.6 and 2.7 and by those releases our 64-bit arch. name is x86_64 so I see no point in having both amd64 and x86_64. I would say wipe out x86_64 symbolic link and rename amd64 directory to x86_64 just for consistency. People navigating with a browser the package hierachy is not as unusual as we might think. For example, when you are looking for a specific package to know its URL so pkg_add works properly fetching all the other dependencies, or when you're looking for the URL to set on pkgin's configuration file. Cheers, Antonio Huete I appreciate what you're saying about having things be clear to users, but this is the alternative to something that would be more confusing. 'amd64' was hardcoded into a number of package tools, including early versions of pkg_radd. The choice is either leave it untidy with a note about the reason for the directory, or break functionality for older machines. Someone was still running a number of 2.0 machines in an environment that couldn't be easily upgraded, last I asked about this, so untidy is a better choice, in this case. The long-term answer that I would prefer is to not have people need to navigate a package hierarchy at all, and instead have the appropriate software selected automatically. We're closer to that with the pkg_radd
OpenSSL Update
I've updated OpenSSL in the base system. As part of the update, the SHLIB_MAJOR got bumped for libssh and libcrypto. This should not break any of your installed 3rd-party software. You'll need to recompile any 3rd-party software that links against libssh or libcrypto if you want to use the new OpenSSL libraries. Additionally, something is broken in ssh causing MAC errors when using SSH2 and MACs other than MD5. I'm working on fix for this, and I expect it to be completed soon. In the mean time, use hmac-md5 if you can. --Peter pgpMjFy6hg0om.pgp Description: PGP signature
Re: A mailing list peculiarity
On Tue, Sep 28, 2010 at 03:44:43PM -0700, Tron wrote: I recently signed up for this list Placed the first post and was very pleased to discover how quickly the community responded. The peculiar thing is, every reply I get to my original post arrives in duplicate. One copy is to: us...@crater... and the other to: my email with cc to us...@crater Now, is that correct server behavior or am I particularly lucky? :) People are likely replying to your email address (since you're the sender) and the mailing list. --Peter pgpZfZQaBOudx.pgp Description: PGP signature
Re: Misleading directory names
On Tue, September 28, 2010 4:31 pm, Antonio Huete Jimenez wrote: Justin, How would anyone be using amd64 directory for 2.0 if we didn't have it back then? Well, no, but if you think about it for a bit you'll realize it's an example to show how long support can be needed for some people, not an history of when packages for amd64 were out. Nature took its course and we ended up having to move older pkgsrc binaries anyway because the archive was getting too big for people to mirror easily.
Re: example of dfbsd deployment or product that based on dfbsd
Justin C. Sherrill wrote: On Tue, September 28, 2010 3:54 am, Iwan Budi Kusnanto wrote: Hi, I just have interest in DFBSD and have some questions. Can someone give me examples of some big/great DFBSD deployment or some product that based of DFBSD ? Is DFBSD proven to be rock solid in real world ? I don't know if these are the scale you are looking for , but I'm looking for production server that used by some company for their mission critical application. dragonflybsd.org, of course, has been DragonFly-hosted for years. My own domain, shiningsilence.com, has been a DragonFly system for... 5 years now? I have been following regular releases and had very little issues.
Re: example of dfbsd deployment or product that based on dfbsd
On Wed, Sep 29, 2010 at 4:17 AM, Iwan Budi Kusnanto iwan.b.kusna...@gmail.com wrote: Justin C. Sherrill wrote: On Tue, September 28, 2010 3:54 am, Iwan Budi Kusnanto wrote: Hi, I just have interest in DFBSD and have some questions. Can someone give me examples of some big/great DFBSD deployment or some product that based of DFBSD ? Is DFBSD proven to be rock solid in real world ? I don't know if these are the scale you are looking for , but I'm looking for production server that used by some company for their mission critical application. Hmm, then maybe you can try to look for it forever as big companies with mission critical application make decisions mostly based on PR materials and donated money from vendors instead of quality or technical merit of solution. dragonflybsd.org, of course, has been DragonFly-hosted for years. My own domain, shiningsilence.com, has been a DragonFly system for... 5 years now? I have been following regular releases and had very little issues. -- “If you’re good at something, never do it for free.” —The Joker
Re: example of dfbsd deployment or product that based on dfbsd
On Wed, Sep 29, 2010 at 10:17 AM, Iwan Budi Kusnanto iwan.b.kusna...@gmail.com wrote: Justin C. Sherrill wrote: On Tue, September 28, 2010 3:54 am, Iwan Budi Kusnanto wrote: Hi, I just have interest in DFBSD and have some questions. Can someone give me examples of some big/great DFBSD deployment or some product that based of DFBSD ? Is DFBSD proven to be rock solid in real world ? I don't know if these are the scale you are looking for , but I'm looking for production server that used by some company for their mission critical application. You mean to say, are you looking for commercial products that uses DragonFlyBSD as framework? I haven't yet found any. I have only known Juniper routers using FreeBSD framework, RedBack routers and Force10 FTOS http://www.101datasolutions.co.uk/wp-content/uploads/2010/06/Force-10-FTOS-Overview.pdf switch routers using NetBSD framework. But yes, I think DragonFly BSD has really now a big potential to be used for commercial products too. I just don't know how licensing can be consider when this OS is used as commercial product. dragonflybsd.org, of course, has been DragonFly-hosted for years. My own domain, shiningsilence.com, has been a DragonFly system for... 5 years now? I have been following regular releases and had very little issues.
ns-flash on df
sorry to cross post for anyone subscribed to both to anyone interested I've posted some updated flash9 docs on the docs@ list- if the current perception is that it isn't working (which was my thought) - it is, for me at least. cheers
Re: example of dfbsd deployment or product that based on dfbsd
On Wed, Sep 29, 2010 at 09:17:29AM +0700, Iwan Budi Kusnanto wrote: I'm looking for production server that used by some company for their mission critical application. My company uses DragonFly on its mail servers and for running its internal ERP application. I'm not sure that really is mission critical tough; we can afford some downtime. -- Francois Tigeot
