Re: SILI-3132 driver progress report.
Matthew Dillon wrote: What? I thought Matt was only going to do an AHCI driver? Well, after diving the Silicon Image data book and looking at the OpenBSD and Linux driver code for it I figured I could do a full driver using the AHCI driver as a base, and I figured I could do it in three days. Wow! you are faster than God himself! I have the idea that some people whom i will not mention will turn green reading that ... -- Michel Talon
Re: fdisk implementation
Freddie Cash wrote: On Thu, Jul 10, 2008 at 3:43 AM, Jost Tobias Springenberg Sorry, couldn't tell you about that. I'm just a user of sfdisk, don't know anything about its internals. Apparently it doesn't depend on much: niobe% ldd /usr/local/sbin/sfdisk /usr/local/sbin/sfdisk: libdialog.so.6 = /usr/lib/libdialog.so.6 (0x28086000) libc.so.7 = /lib/libc.so.7 (0x280a3000) libncurses.so.7 = /lib/libncurses.so.7 (0x281a) But of course it is deficient in that it doesn't see logical partitions. With it you can edit 4 primary partitions, period. No logical, no bsd partitions. In other words, it is of very limited utility, in my opinion. A good partitioning tool is still lacking for FreeBSD, able to do at least what Linux cfdisk does so simply. I suppose the geometry problems which plague FreeBSD sysinstall are also present on sfdisk. -- Michel Talon
Re: SMP question
Haidut wrote: Like I said in my first email, all I need is a rough estimate - 1 month, 2 months, etc. Assume full-time, 40 hour week. It may be relevant to have an idea of the time it took to get a working SMP implementation (by working i mean, such that N processors offer an advantage proportional to N with respect to 1 processor) for Linux and FreeBSD. It was certainly several years for Linux (with a *lot* of developers, and several paid full time) and about 5 years for FreeBSD. So i hope your project is not a short term one ... PS. By the way, FreeBSD is still not completely fine-grained locked (for example the tty system is not) and one better take N=8 above to get satisfactory results. Linux is better in that domain because it enjoys using proprietary techniques covered by patents, which have been donated by IBM, SGI, etc. and that no BSD system can use, at least without circumventing the patents. To take another exemple it took many years Solaris to be considered better than the good old slowlaris system. -- Michel Talon
Open Mosix
I think it is not irrelevant to mention here the announcement: http://sourceforge.net/forum/forum.php?forum_id=715406 Moshe Bar, openMosix founder and project leader, has announced plans to end the openMosix Project effective March 1, 2008. The increasing power and availability of low cost multi-core processors is rapidly making single-system image (SSI) Clustering less of a factor in computing. The direction of computing is clear and key developers are moving into newer virtualization approaches and other projects.
Re: To be a new DFly commiter
Matthew Dillon wrote: I personally believe that postfix is superior. I personally do not mind running GPL'd code. But I also would prefer to have as little GPL'd code in our managed code base as possible. What does this mean? I would dearly like to integrate portions of pkgsrc managed packages into our buildworld and installworld system, that is have the buildworld create a little package building jail and build and install selected packages, with appropriate defaults, as part of the base system build. Then we would not have to import or maintain the sources for at least the larger integrated pieces (such as sendmail/postfix, bind, etc). If i can allow myself to comment Matt's opinion, i think that the two statements above are true and excellent. More generally, there are pieces of traditional BSD installations, such as sendmail, etc. which have better non BSD variants, so that an integrated mechanism to get rid of such base system tools ( i mean only selected few ones ) and import external packages. b) Add imap-uw as simple pop3 and imap4 daemon. I'd prefer this be maintained via pkgsrc. Yes, in particular when imap-uw is a notorious buggy, insecure and bad performing application. I don't think a single person would be able to maintain an alternative. Simply keeping up to date with all the new versions of various things that occur every day would be difficult. Another excellent statement! Maintaining a decent ports system is a task for hundred people. FreeBSD has aroud 200 people doing that, Debian, around 1000. One has to be totally unaware of realities to suggest tools from obscure Linux distributions, wether they are good or bad, when such distribution may collapse at any moment. Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. The NetBSD people have replaced the horrible mess which is the 4000 lines bsd.port.mk by a similar horrible mess except it is scattered over many 5 lines files. Like in many cases it is OpenBSD which is doing the good work, and in particular they have understood the obvious, that is a ports system must be centered about binary packages, not recompiling source. This is true for at least two reasons: - first, today users don't want to lose time compiling - second, it is *impossible* to guarantee reliability of a system based on source code, because two people may compile the same software on different background, and obtain different result. This is a fundamental issue that nobody will be able to solve.
Re: To be a new DFly commiter
Joerg Sonnenberger wrote: One has to be totally unaware of realities to suggest tools from obscure Linux distributions, wether they are good or bad, when such distribution may collapse at any moment. Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. Package counting like comparing penis length. There are more important parameters... I've spoken with at least one member of FreeBSD's portmgr who cursed the current size of the tree, making it very hard to maintain or move forward. A friend also just reminded me that ports has over 8700 (!) Perl modules in the list, factoring that out reducing the divisor a lot. rose% uname -a FreeBSD rose 6.2-RELEASE FreeBSD 6.2-RELEASE #1: Sat Feb 3 12:51:15 UTC 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROSE i386 rose% find . -depth 2 -maxdepth 2|grep p5|wc -l 2684 and this picks php5 stuff and perhaps other. The reality is that on FreeBSD i find everything i want in the ports, even more easily that in Ubuntu, while on several other BSD and Linux systems i don't, by a very large margin. This is not pissing contest, for me the wide abundance of ports in FreeBSD is by far the most important reason why i am using it. It is certainly not because the kernel is more stable or more performing that on a Linux system, which would not be true, it is because each time i want to use some software i find it. OpenBSD has an excellent packaging system recently revamped by Marc Espie, but it is severely lacking ports coverage. What FreeBSD and NetBSD lack is a good system for management of binary packages. Marc has very well understood that, and has made every effort so that updates work smoothly. To my knowledge OpenBSD is the only BSD which has a working update mechanism, fully integrated. I have written something experimental for FreeBSD: http://www.lpthe.jussieu.fr/~talon/pkgupgrade because i think there is no future for an OS without a binary packages management system,for the reasons that i have mentioned. Sorry, i don't buy Steve's arguments. It is not because One person wants to build sane without gimp support that All users have to endure the pain of building all their ports. The solution is simply that Steve uses an alternative mechanism, involving compilation, when he wants to install sane. If moreover the reason for such desire is to avoid bloat on the hard disk, then i call that an exercise in futility.
Re: Plans for 1.8+ (2.0?)
Rupert Pigott wrote: On Thu, 01 Feb 2007 09:39:30 -0500, Justin C. Sherrill wrote: True, but Matt has explained that ZFS doesn't provide the functionality that DragonFlyBSD needs for cluster computing. ZFS solves the problem of building a bigger fileserver, but it doesn't help you distribute that file system across hundreds or thousands of grid nodes. ZFS doesn't address the issue of high-latency comms links between nodes, and NFS just curls up and dies when you try to run it across the Atlantic with 100+ms of latency. I don't know if IBM's GridFS does any better with the latency, but it certainly scales a lot better but the barrier for adoption is $$$. It costs $$$ and it costs a lot more $$$ to train up and hire the SAs to run it. There are other options like AFS too, but people tend to be put off by the learning curve and the fact it's an extra rather than something that is packaged with the OS. Of course it is none of my business, but i have always wandered about the real usefulness of a clustering OS in the context of free systems, and you post allows me to explain why. People who have the money to buy machines by the thousands, run them, pay the electricity bill, etc. should also have the money to pay $$$ to IBM, and not count on the generosity of unpaid developers. Small installations are the natural target of free systems, and in this context i remain convinced that the clustering ideas have an utility next to null. And frankly, i doubt they have any utility for big systems if you don't use high speed, low latency connects which are far more expensive than the machines themselves. And even with this highly expensive hardware, if you don't have high brain programmers able to really make use of concurrency. On the contrary, the disks of Joe User are becoming bigger and bigger, his processor is getting more and more cores, so there is clearly a need for file systems appropriate for big disks and sufficiently reliable ( ZFS being an example ) and operating systems able to use multicores efficiently.
[no subject]
Subject: Re: What would you like in DF 1.8? Newsgroups: dragonfly.users Date: Tue, 18 Jul 2006 15:20:06 +0200 References: [EMAIL PROTECTED] [EMAIL PROTECTED] User-Agent: KNode/0.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 34 NNTP-Posting-Host: 82.227.32.26 X-Trace: 1153228808 crater_reader.dragonflybsd.org 776 82.227.32.26 Xref: crater_reader.dragonflybsd.org dragonfly.users:6491 Steve O'Hara-Smith wrote: Well since all of that can be obtained elsewhere I would be very happy to see it stacked behind the clustering behaviour that Matt has already outlined as the primary goal because that *cannot* be obtained elsewhere. I must be dreaming, what are running all those high performance clusters which appear in the Top500, and are supposed to be based on Linux? Perhaps something like http://openssi.org/cgi-bin/view?page=features.html I could not swear it, but from memory it is more than 5 years and perhaps much more than functional solutions exist for Linux, with all kernel hooks and much more than have been proposed here. Not to mention older distributed computing projects like amoeba by Tanenbaum. And by the way, who has the money to run such clusters, besides big corporations and big academic labs? How much does cost Myrinet and other Infiniband hardware necessary to ensure low enough latency so that distributed computing has a small chance of being a realistic proposition? The present and foreseable future of affordable computing is multiprocessor machines, with perhaps up to 32 virtual processors (Sun machines). Being scalable on such hardware is a realistic goal, Solaris does it, Linux does it, both using traditional solutions. Maybe Dragonfly can do it with innovative solutions. PS. Can I have the bikeshed in sky blue pink with yellow dots. -- Michel Talon
Re: Upgrade problem (1.2.x -- 1.3.x)
Steve O'Hara-Smith wrote: On Tue, 22 Nov 2005 15:20:06 +0100 Sascha Wildner [EMAIL PROTECTED] wrote: Steve O'Hara-Smith wrote: Personally I think there really should be a 'reboot to single user mode' instruction between installkernel and installworld. So do i. Single user mode minimises the amount of the old world that is running which may be a good idea especially if there are a lot of services turned on. Personally i have been bitten once on FreeBSD 3 or 4. There had been changes in the kernel NFS stuff, i rebooted inadvertently multiuser, instant panic when mounting NFS shares. Rebooting single user should be a required step in the upgrade procedure, unless it is absolutely impossible (collocated machine) and in this case i suspect no reboot at all is less risky. Even if the make installworld doesn't succeed completely, there is good chance that a reboot to multiuser will work and allow to do it a second time. -- Michel Talon
Re: Interesting ubench scores for FreeBSD 4.11, 5.4, 6.0beta3 and DFly-Preview
Kris Kennaway wrote: When using the same binary, the CPU scores are statistically indistinguishable between the different FreeBSD versions. This makes sense since there's little kernel involvment in running userland integer/FP computations. When running the gcc 2.95 binary all versions of FreeBSD were 31% *faster* on this test than when running a gcc 3 binary (both compiled with -O only). FreeBSD 5.x and above show a 6.3% drop on the memory test relative to 4.x (with the same 4.x binary). I reran ubench with kernel profiling enabled and found that this drop is mostly due to the vm locking present in FreeBSD 5 and above (via vm_fault). This locking is also responsible for the dramatic performance increases on SMP machines seen in other benchmarks, so it would be more interesting to test on SMP machines. I'm not set up to do this on my hardware though. Wonderful exposition, Kris, and a proof that benchmarks have to ba taken with a grain of salt. It may also depend considerably on the hardware, for example AMD machines have faster locking primitives than Intel ones, and hyperthreading can degrade considerably the result. To give a perfectly subjective appreciation, and with a limited range of desktops and laptops, for me FreeBSD-5.4 works very well, and certainly much better than FreeBSD-4. If it has a solid contender, it may be DragonFly, but much more obviously Linux, kernel 2.6.
Re: Compatability with FreeBSD Ports [debian package tools]
Raphaël Marmier wrote: This would answer the needs expressed many time in an acceptable compromise: - upgrading an app without breaking another in the process - able to install multiple versions of a package - allow piecemeal upgrades - allow updating a single package - you can have several admins each concentrating on his stuff without the fear of breaking the colleague's stuff. - piece of mind Let me add that this sytem is precisely the system advocated by Apple and by PC-BSD, and that PC-BSD seems to be very well received at least by the newbie part of the community (http://distrowatch.com/), which is very important. In fact the various experiences - Debian, FreeBSD, NetBSD, etc.- show that package management systems create more problems that they solve. For instance in the Debian case, the requirement of a fully working system directly causes extreme stagnation. One of the aims of many package management systems is to clean the hard disk of old cruft and so on. Nothing is more costly at the end that this stupid goal of economizing something which is basically gratis (hard disk space). For me it is one of the redeeming features of portupgrade that is keeps stuff under compat, instead of throwing it away like a direct make in the ports tree. I thought it was one of the goals of Dfly to introduce vfs magic precisely to be able to do that, to have several coexisting versions of the same soft, etc. without trouble. this is why i am a little surprised by all these discussions about pkgsrc, etc.
Re: Compatability with FreeBSD Ports [debian package tools]
Garance A Drosihn wrote: I have had very good luck with portupgrade, on multiple freebsd systems on multiple platforms. I do avoid the biggies like KDE or Gnome, which obviously helps. Since half the ports i have on my machine, if not 3/4 require one or the other of Gnome libraries, using portupgrade and avoiding Gnome seems to me a contradictory position. Of course if you limit yourself to some simple ports, with very limited dependencies, then i have no problem beleiving portupgrade works for you. At least portupgrade minimally avoids some breakage by keeping old libraries under compat. Regarding KDE, i have never encountered any problem with it, personnally. I have always seen it compiling straight away. In the past it was not always running without glitches and core dumps, but now i don't see such behavior any more. I cannot say the same of a lot of other softs.
