DragonFly MBR
Hi Everyone, I wrote an MBR at one point - it's quite similar to FreeBSD's, except instead of function keys it looks something like this: Windows > DragonFlyBSD FreeBSD Uhm, paste that into vi or something that has a set font size and it will make sense! Anyway, you use the arrow keys and pick an OS. Of course, I could change how any of this works (like the F1, F2, etc if everyone prefers). I thought maybe DragonFly could use its own MBR instead of having a slightly modded one from FreeBSD. Just say the word and I'll fire the source off your way - it's in nasm. I'll need to mod it to add support for other things though, like multiple hard disks. (FreeBSD has an "F5-Disk2" option). - BC
RAIDFrame
Is anyone planning to port RAIDFrame to DragonFly?
Re: Speeding up networking, worth a read.
On Wed, Mar 08, 2006 at 05:13:44PM -0800, walt wrote: > I'm just thinking about how to keep software as free from bugs as > possible. Linus once said: 'All bugs are shallow, given enough eyes.' > > Wouldn't moving kernel code into userspace increase the number of eyes? The Thousand Eye Ball Theorem is a very old and very common myth. It doesn't work in reality for many problems. How many people do you believe have a reasonable understanding of the internals of TCP/IP, well enough to trace down bugs in the stack? I don't think very many do. This equation doesn't change *at all* if the implementation moves to userland. That said, VJC argues that the complexity of TCP/IP is partly a result of having to deal with the kernel buffering. I disagree with that rhetoric. E.g. the second loop between kernel and userland is tightly coupled enough that in almost any situation the outer loop is dominating and the inner loop vanishes effectively. This changes when the link is fast enough to overpower the local CPU, but the proposed fix is nothing but a fancy congestation control. That's the technical point where I disagree :-) Joerg
Re: Speeding up networking, worth a read.
Matthew Dillon wrote: > :Simon 'corecode' Schubert wrote: > : > :> ...we don't feel comfortable with a tcp stack in userland... > : > :Could you explain in basic bonehead terms why not? I've long > :been a fan of the microkernel which runs *everything* in > :userland. [...] > In a traditional microkernel architecture things like the TCP stack would > run in their own processes and, indeed, this WOULD improve stability > simply by exposing bugs more quickly due to the protection space > separation that each subsystem enjoys. I think this is a fine idea *IF* > your sole goal is to have an ultra reliable system rather then an > ultra fast system... Well, I'm just an amateur. I can't hope to advance any technical arguments which might convince any techno-people like you guys. I'm just thinking about how to keep software as free from bugs as possible. Linus once said: 'All bugs are shallow, given enough eyes.' Wouldn't moving kernel code into userspace increase the number of eyes? Yes, this implies a performance penalty, but there is a cost attached to every benefit in life, alas! How about letting each user choose whether he wants to participate in debugging 'kernel code' (like the TCP stack) or go for maximum performance? I know that I would choose reliability (and debugging chores) over speed. Others would do the opposite. No biggie! Thanks for your answer -- I learned from it.
Re: Speeding up networking, worth a read.
On Wed, Mar 08, 2006 at 04:14:14PM -0800, Matthew Dillon wrote: > It would be disaster. It would become extremely difficult to track down > bugs. And because of that I think its an ultra bad idea. It is not > worth the ~1 uS savings per system call. It just isn't. Esp. since I don't believe the actual number of system calls to go down. What is better in this approach is buffering for connections with high bandwidth delay product (I can't get more than 10 MByte/s for non-local TCP links, even though the link is far from being saturated, since parallel TCP connections are fine). Another important aspect is the processing latency is not necessarily going down as well. As a matter of fact, something like having a great number of mostly CPU bound daemons pushing out the results of the calculation (think PHP) can now result blocked transmission for the duration of a full time slice. That's something the kernel normally handles. Joerg
Re: Wiki spam
Peter Avalos wrote: On Wed, Mar 08, 2006 at 09:37:59PM +0100, Jonas Trollvik wrote: Wouldnt it be possible to add some kind of graphical confirmation that displays a gif with a code that can't be ocr scanned like a lot of message boards / places do? This would at least prevent automated spam -Jonas But then you restrict people to graphics-capable web browsers. --Peter Some time ago I saw an anti-spam-script, which required some text (like "NO SPAM") in the summary. Maybe this could help... -- reezer
Re: Speeding up networking, worth a read.
:Simon 'corecode' Schubert wrote: : :> ...we don't feel comfortable with a tcp stack in userland... : :Could you explain in basic bonehead terms why not? I've long :been a fan of the microkernel which runs *everything* in :userland. : :But (as my wife would quickly tell you) I'm an idiot :o) :Is your objection based on performance, or security, or -- :what? Well, what they are talking about is different from microkernel type architectures. They are talking about moving all the protocol code into the same context as the user program that is making the connection. The entire performance benefit comes from not having to context switch into the kernel and back out again. There is some argument for cache locality of reference, but personally speaking I think there are plenty of other ways to localize data accesses that do not require running everything in one context (such as what we've done with our threaded TCP protocol implementation). In otherwords, you lose the protection between functional subsystems. Now, its true that everything running in the kernel is also running in a single context (the kernel context), but I would argue that the danger here is that you are suddenly asking application programmers to debug the TCP stack, and kernel/protocol programmers to debug a massive user application when things go wrong. It would be disaster. It would become extremely difficult to track down bugs. And because of that I think its an ultra bad idea. It is not worth the ~1 uS savings per system call. It just isn't. In a traditional microkernel architecture things like the TCP stack would run in their own processes and, indeed, this WOULD improve stability simply by exposing bugs more quickly due to the protection space separation that each subsystem enjoys. I think this is a fine idea *IF* your sole goal is to have an ultra reliable system rather then an ultra fast system. Most people need a mix of the two, with emphasis on performance, which is why microkernel architectures don't fare so well in the real world. There are also issues with distributability. On a UP system or a 2-way SMP system, or in situations where you have many forked processes running, you might get some performance gains from localizing the TCP protocol stack to the application making the connection. But who is to say that that situation is going to persist as we continue to move forwards? If SUN has their way, we'll be running on 256-way machines in the household 20 years from now and all of that serialized protocol code will destroy performance rather then improve it. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: bsdtalk022 - Interview with Matthew Dillon from DragonFly BSD
Matthew Dillon wrote: Heh. You beat me to the posting. Yah, Mr Backman interviewed me yesterday! This was a great interview! I hope the bsdtalk folks keep this up as they are doing a great service to the BSD Community. Scott
Re: Wiki spam
On Wed, 2006-03-08 at 13:58 -0800, Devon H. O'Dell wrote: > Sun's blog method is interesting; it provides another form > field that requires one to answer a simple mathematical > question (e.g. What is 75+22). The question about user input got me thinking too and I thought of Sun's blog also, I just recently tried it to check out zfs and this caught my attention too; it's simple, spam-proof (in some way then, I guess you still might need javascript to 'mangle' it) and everyone can use it. gr, Axel signature.asc Description: This is a digitally signed message part
Re: Wiki spam
On Wed, Mar 08, 2006 at 01:55:52PM -0700, Peter Avalos wrote: > On Wed, Mar 08, 2006 at 09:37:59PM +0100, Jonas Trollvik wrote: > > Wouldnt it be possible to add some kind of graphical confirmation that > > displays a gif with a code that can't be ocr scanned like a lot of > > message boards / places do? > > > > This would at least prevent automated spam > > -Jonas > > But then you restrict people to graphics-capable web browsers. > > --Peter Sun's blog method is interesting; it provides another form field that requires one to answer a simple mathematical question (e.g. What is 75+22). --Devon
Re: Wiki spam
On Wed, Mar 08, 2006 at 09:37:59PM +0100, Jonas Trollvik wrote: > Wouldnt it be possible to add some kind of graphical confirmation that > displays a gif with a code that can't be ocr scanned like a lot of > message boards / places do? > > This would at least prevent automated spam > -Jonas But then you restrict people to graphics-capable web browsers. --Peter pgp9qUBLIqfZ2.pgp Description: PGP signature
Re: Wiki spam
Wouldnt it be possible to add some kind of graphical confirmation that displays a gif with a code that can't be ocr scanned like a lot of message boards / places do? This would at least prevent automated spam -Jonas On 3/8/06, Axel Scheepers <[EMAIL PROTECTED]> wrote: > On Wed, 2006-03-08 at 11:18 -0800, Ben Cadieux wrote: > > Scripts to automate abusing wikis? What's wrong with people... > > > > Hi Ben, > > Well, that's life these days. I wish it was all love and peace all over > again but I'm affraid these days are gone.. :( > > > I think their IPs should be PF'ed out of all dragonfly-related > > systems. Wikis record them, don't they? > > > That doesn't work quite well(manual work) and could (if done by a script > for example) block things you don't want blocked if you're not carefull. > > As for the given precautions I'd say please do, it will make it more > easier to contain. Just my 2cts. > > Kind regards, > > Axel Scheepers > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBEDzHGvOFCXiGjP+ARAt1tAJ4l4PsgsDpXdKTdu4lmW+RxT7EVmgCgqnKw > RBcEzwmaR26LPA7mKuhAAxo= > =u8l9 > -END PGP SIGNATURE- > > >
Re: Wiki spam
On Wed, 2006-03-08 at 11:18 -0800, Ben Cadieux wrote: > Scripts to automate abusing wikis? What's wrong with people... > Hi Ben, Well, that's life these days. I wish it was all love and peace all over again but I'm affraid these days are gone.. :( > I think their IPs should be PF'ed out of all dragonfly-related > systems. Wikis record them, don't they? > That doesn't work quite well(manual work) and could (if done by a script for example) block things you don't want blocked if you're not carefull. As for the given precautions I'd say please do, it will make it more easier to contain. Just my 2cts. Kind regards, Axel Scheepers signature.asc Description: This is a digitally signed message part
Re: Speeding up networking, worth a read.
Simon 'corecode' Schubert wrote: > ...we don't feel comfortable with a tcp stack in userland... Could you explain in basic bonehead terms why not? I've long been a fan of the microkernel which runs *everything* in userland. But (as my wife would quickly tell you) I'm an idiot :o) Is your objection based on performance, or security, or -- what?
Re: Wiki spam
: :Scripts to automate abusing wikis? What's wrong with people... : :I think their IPs should be PF'ed out of all dragonfly-related :systems. Wikis record them, don't they? They're usually run from compromised machines, just like normal spam is sent from compromised machines. So mapping out the IP is an exercise in futility, normally. I think giving known contributors operator privs and making it read-only for the remainder is a fine idea. Is there a way to allow normal users to contribute but for the changes to not go active until an operator reviews them? -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Wiki spam
Scripts to automate abusing wikis? What's wrong with people... I think their IPs should be PF'ed out of all dragonfly-related systems. Wikis record them, don't they?
Wiki spam
Hi all, recent spam characteristics in the Wiki indicate that spammers are setting up scripts to automate their spamming more and more. So far our stategy has been to manually revert the change and block the user name (this is about as much as Wikimedia allows, at least from what I've seen). This worked well for a time but lately I've gotten tired of this. And I guess Trevor (Kendall) is too, who fought most of the spam back with me in the past. So my spam plan is this: 1) Go through the user's list and see who contributed DragonFly related stuff in the past. 2) Grant all these users operator privileges. The difference from an ordinary user is: they can delete/undelete and protect pages, revert changes easily and block users. 3) Protect all pages against editing from normal users. 4) Add a note to the main page that everyone who wants to contribute should drop me a quick mail so I can check back and grant operator privileges. 5) When a new page is created by someone, he has to protect it. I'd like to hear your opinions on this. Here's why I think this would work: * Being a Wiki sysop doesn't give you the right to turn others into sysops. The bureacrat flag is needed for this and would of course not be set for the majority of users. So not much danger there. * I don't believe that having many sysops would cause much abuse. So far everything has been very peaceful except for the spam. There haven't been any hot disputes or edit wars (and I don't see where they could arise). * I don't believe that many spammers would write a mail to someone to get access for spamming. And if they did, it would be easy to find out. One more thing, let's please not discuss this to death. If someone comes up with a better solution it should be one that is realistically doable. I know that we should better hack Wikimedia, write our own Wiki, move to a different Wiki etc. But these things take time which I don't have. So the plan is to use what's there to stop it. Sascha -- http://yoyodyne.ath.cx
Re: limited space upgrade
:On Tue, 8 Mar 2006, [EMAIL PROTECTED] wrote: : :> I've got 1.4.0 installed and I am trying to get to 1.4.2 After :> cvsuping the src I am left with 617MB on /usr. Ultimately, as a :> firewall this will be quite adequate. However, I've demonstrated to :> myself that it is not enough room to make buildworld. :> :> Any suggestions or experience chunking up the process? : :Do you have other partitions to do the build on? : :Or maybe use tarballs of the binaries instead? : :(I don't remember: maybe BSD Installer provides a upgrade option?) : : Jeremy C. Reed : :echo '[EMAIL PROTECTED]:;6<754372=9=?48812=7043:>' | tr '0-@' 'wutrofn mlkige.ca' Or use an NFS mount from another machine with more space. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: bsdtalk022 - Interview with Matthew Dillon from DragonFly BSD
: :Matt on bsdtalk podcast! : :http://bsdtalk.blogspot.com/ : :Sync'd through to my iPod fine and I listened to it on the train to :work - very interesting! : :Cheers Steve Heh. You beat me to the posting. Yah, Mr Backman interviewed me yesterday! -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Speeding up networking, worth a read.
Miguel Filipe wrote: I think the dragonflyBSD team must read this, and apply the same principles to make the DFly networking stack "super-hot". of course we already read this paper. i quickly discussed this with matt, and i think we agree that we don't feel comfortable with a tcp stack in userland. on the other hand, having the stuff van jacobson implemented in dragonfly to try out is something else, but i doubt it would go into cvs. we already do batch processing, basically. i think bsds always did this due to the soft interrupt nature (i might be horribly wrong there). while VJ shows some impressive numbers, i'm not sure how they would apply to dragonfly. but in case you are eager to implement this, don't let me stop you! it might turn out to be reall cool[tm], but e.g. for tcp we already do something simmilar. we don't use these lock-free lists, but we queue messages to ports. but of course i appreciate your heads-up to this paper! maybe you want to play with the network stack a little bit? 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 / \
Speeding up networking, worth a read.
Hi, I recently read a presentation about how to speed up networking, from Van Jacobson. I think the dragonflyBSD team must read this, and apply the same principles to make the DFly networking stack "super-hot". I also should point out that some of the ideias/principles are allready considered in the DragonFly BSD filosofy, and Matthew has shown a very good insight of the root problem.. Basically.. I think this paper is a _must_ read for any modern OS trying to evolve into something significantly better.. and also.. it is specially in sync with dragonfly BSD because it fits very well together with the dragonfly BSD filosofy/mentality. A excerpt from the introductory text follows: " Although the best of its breed, the linux kernel networking architecture closely follows a design first laid out in the early 80s (as do Windows, Solaris, MacOS, ...). While this design met the needs of its day, and many days beyond, it has some fundamental flaws. By re-architecting a small part of the networking code, network device drivers and the network buffer model, it's possible to get dramatic increases in performance (we have measured factors of 2X to 4X improvement in network intensive grid and web application benchmarks) and in system scalability (e.g., the new architecture has *no* locks in any part of the packet send/receive path). It is easy to convert existing drivers to the new model and the result is both simpler and smaller (e.g., a 30% reduction in size for the 2.6.11 E1000 driver). And since the new architecture is completely backward compatible, conversion can be done incrementally. " http://lca2006.linux.org.au/abstract.php?id=382 http://www.lemis.com/grog/Documentation/vj/ http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf -- Miguel Sousa Filipe
bsdtalk022 - Interview with Matthew Dillon from DragonFly BSD
Matt on bsdtalk podcast! http://bsdtalk.blogspot.com/ Sync'd through to my iPod fine and I listened to it on the train to work - very interesting! Cheers Steve
