Date: Thu, 20 Dec 2001 14:07:25 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Anthony Atkielski <anthony@freebie.atkielski.com> Cc: Jeremiah Gowdy <jeremiah@sherline.com>, advocacy@FreeBSD.org, Gilbert Gong <ggong@cal.alumni.berkeley.edu> Subject: Re: Microsoft Advocacy? Message-ID: <XFMail.011220140725.jhb@FreeBSD.org> In-Reply-To: <025a01c189a0$8f750c70$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Dec-01 Anthony Atkielski wrote: > John writes: > >> No. Stop being paranoid. > > It's not paranoid at all. Ever _read_ those employment contracts you sign > when you hire on as a software engineer? Even when your employer doesn't > claim rights to whatever you write outright, you may still be required to > give him first crack at buying any code you write, which can interfere with > writing anything intended to be open-source. Having a software company > claim rights on a chunk of FreeBSD because of such an agreement would be a > very, very serious problem. Yes, I have read them. I also note that the ones I am willing to sign do not make restrictions on the open source software I develop. >> Spin mutexes in the kernel don't need to actually >> have a lock to spin against since the disabling >> of interrupts that they perform is sufficient >> protection. > > What about multiprocessor systems? What about unmaskable interrupts? Uh, this is _specifically_ for UP machines. Why don't you actually read my messages rather than cutting out the half that answers your questions? Unmaskable interrupts are usually fatal machine exceptions where we are about to panic anyway, so they are not a concern. > I prefer spinning against locks, myself. Better safe than sorry. This only serves to display your ignorance. >> It doesn't, because they aren't that different. > > If it makes no distinction, it cannot give either type of process > preference. You missed my point: this design goal came from worrying about user needs (desktop) rather than server needs. FreeBSD paying attention to the desktop and making some optimizations for it can result in helping out server performance as well. >> The way it works is that when a process >> performs I/O, it's priority gets bumped if it >> blocks waiting for I/O, and processes get >> "punished" for using the CPU. > > What a striking innovation. It was when it was first done in BSD. Please gain some perspective. I am attempting to provide examples to explain a bigger picture idea, but apparently you insist on ignoring/bashing/picking apart/whatever each example rather than seeing the bigger picture. *sigh* -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011220140725.jhb>