Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Am Montag, 17. Juli 2006 01:00 schrieb walt: Hi James, I'm speaking as someone who's been asking dumb/newbie questions in these groups for several years now. I've never once been treated rudely or with 'attitude' so I hope you won't judge hastily from any one thread. The regulars in these forums have been more than kind and patient with my off-topic nonsense over a long period of time. In fact, I tend to post my dumb questions here because I know I won't be yelled at :o) Please stick around and I'm sure you will see what I mean. James, I as a fairly new (DragonFly-)BSD desktop user second that. The community was friendly and the developers even fullfilled my device driver wishes, The problem is IMHO the lack developers. Thomas
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
James Mansion wrote: Fine. Go and do it, instead of complaining about it. I'm sure you'll check the IP and find that actually I'm not Danial/Dmitri/whatever, but please, take a step back before writing this sort of thing. James, no, we normally don't check IP addresses. Before em1897/Danial/Dimitri (please don't confuse him with Dmitri Nikulin who is a respected community member) hit the stage, I actually wouldn't have thought that this would ever be necessary. If you browse the mail archive a bit, you'll find that his questions were initially responded to with long, friendly and very interesting explanations by Matt (some of which even made it to Justin's DragonFly Digest). It was only after it became clear that his intent was insulting people and their work that more drastic measures were invented. First, threads were simply terminated by making it impossible to continue them, then his email address was banned, now, ultimately, it's his IP address. Please do not base your judgement on this one mail. It has a long and annoying history. Sascha -- http://yoyodyne.ath.cx
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
James Mansion wrote: [...] It really does make me question whether I want to use anything from projects with this attitude... Hi James, I'm speaking as someone who's been asking dumb/newbie questions in these groups for several years now. I've never once been treated rudely or with 'attitude' so I hope you won't judge hastily from any one thread. The regulars in these forums have been more than kind and patient with my off-topic nonsense over a long period of time. In fact, I tend to post my dumb questions here because I know I won't be yelled at :o) Please stick around and I'm sure you will see what I mean.
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
On 7/16/06, James Mansion [EMAIL PROTECTED] wrote: So please, don't respond to customer/user suggestions that way, unless you want to be treated like an amateur having a play to see what you can do. I didn't think that *was* what you wanted. What's he supposed to say? Sure, I'll put down the important work I'm doing to make this system unique and directly applicable to an important niche market, and work on creating Yet Another Linux with no hope of surviving? Do you want a user community? You need to respect users who have no intention of developing your system. They might have enough on their plate solving their own development problems. The developers here are very respectful of users, but they can't reasonably chase every tangent. I do not necessarily agree with the wording, but the point is correct - the developer resources are spread too thin already, and following questionable technical decisions (explained further down) is the last thing they want to do. As it happens, I agree with the original post: if you are too small to define de facto standards, and there is no de jure standard to hide behind (not that they always matter that much in reality) then practicality says that its necessary to go with the flow and find a way to use whatever is there, and if that's an NVidia blob for Solaris or Mac or even Windows, then so be it. I really wish it was that simple, but if we want open source code, we need an immediate problem rather than a long-term one. The long-term problem is that binary blobs might not be supported any more since the profitability for the company drops over time. The short-term problem, which is the good one because it encourages preventing the long-term problem, is that here-and-now a lot of devices simply don't have any driver available. If developers do not see the long-term problem, as has so often been the case, they might decide it's 'good enough' to have the binary blob as the workaround for the short-term problem. Bad enough that these blobs, even now, can have unspeakably terrible security holes, even some deliberate ones, and short of an inhuman reverse engineering effort we'll never really know. OpenBSD's Theo is the most outspoken on the issue of binary blobs - it might be nice for the popularity of a system to support every device, but it's absolutely terrible for the durability. Linux in particular is *already* a tightly knit mass of bugs, hacks and security holes, and when they finally see the terrible situation they're leaving themselves in by actually thanking vendors for binary blobs instead of sending them packing. They have good people on their side - the reverse engineering nForce ethernet driver is what helped OpenBSD folks write nfe(4) which is quite good - but the spirit there is to do everything possible even if it is going to hurt later. They've been re-writing major parts of the kernel between every one or two minor releases, because somebody didn't think ahead. Vendors have to keep up with all of that mess when releasing drivers. BSD in comparison is very easy to develop for, but it's not as profitable, and it's hard to imagine vendors would care about much more. Even if the entire BSD community announced its united love for a single graphics vendor and only bought from them, it'd still be less of a profit gain than releasing a slightly superior device with only a Windows driver and some form of Linux adaptation which works okay on Thursdays, thusly turning over some of the much larger market share from a competitor. Hard to say which would be more expensive to implement, but chances are using the existing masses of hardware and Windows+Linux experts they have is cheaper than the overhead to even get an NDA out to a BSD developer. At no point is releasing documentation viable just because their business is secrecy, so even if we did have vendor support it'd be just like with Linux, with either really poor quality drivers (the Intel PRO Wireless ones) or entirely closed and brittle ones (anything released from ATI or nVidia, ever). In the particular case of graphics drivers, its very much more attractive to target a system which can also be the desktop of choice. Maybe second best would be decent Xen guest support, but it surely must be a distant second. Agreed, I too would really like having an operating system for everything. But as long as vendors, hardware and software alike, refuse to support BSDs, I am often limited in how I can run them as workstations - and as long as Linux is absolute garbage in security, stability and administrative sanity, I will hardly consider running it as a server. Does it matter? Not much, I'm content to Linux as a desktop (I don't, but I imagine I will later), and it's not as though doing so will somehow prevent me from running a BSD server. Remember that it's unreasonable to expect that BSDs could stay as clean and robust as they are now if commercial vendors put their lust for money into them.
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
On Fri, 14 Jul 2006 08:43:48 +0800 Bill Hacker [EMAIL PROTECTED] wrote: Given half a century in information technology, I could fill a website with more good ideas that have been abandoned than kept. That would be a valuable website - one that could be mined for good ideas for decades to come. -- C:WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
--- Bill Hacker [EMAIL PROTECTED] wrote: Martin P. Hellwig wrote: Dimitri Kovalov wrote: cut You have it backwards. The reason BSD is all 'black boxes' is that it is not competitive or good in the video area. *I* have it backwards? We should all be running WinWoes 'cos it is 'good in the video area?' What does we have to do with it? I said BSD isn't prevelant on desktops because its not good at video. Its too much trouble. Productive people use windows, because instead of spending a half a day getting a video card to work, they can do something income-producing. Thats what its all about. Apple can make it work because they sell the whole box and can control the hardware. But the open-source OSes don't have the resources to support video. Not so. You have cause and effect reversed. No I don't. getting vendors to write drivers for 1000s of cards using their programmers who know the hardware is advantages over trusting some guy from some country with way too much time on his hands to write and maintain it. The F/OSS folks who *must have* a good video and GUI to get some *other* set of tasks accomplished simply buy the commodity that suits them. Lots of *n*x developers use a Winbox or Mac with nary a care for the politics or religion, just as they would a twist drill. Not throw-away, but expendable nonetheless. The haven't time to play with these 'appliances', and begrudge even time wasted on updates and fiddling (hence my move form OS/2 to OSX). Very much a minority market vs gadzillions of office-workers and home users. Those who would *like to have* a good video and GUI for reasons *other than* getting some other job done, are more likely to use Linux, and DO spend a good deal of time modifying and updating their personal WS. Mostly they use Windows, not because its a better os, but because it has more options and tools to get the job done. Some people have jobs more complicated than Bill Hacker. I guess from your hole you'd not understand it. One big problem is that you guys, as BSD developers, are not focused on what the public wants, you are focused on your own, unusual needs. Which is why BSD is no good for the public, only for hackers. The developers, who mostly don't understand the real world, develop for other developers. Dimitri __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Joerg Sonnenberger wrote: On Thu, Jul 13, 2006 at 05:04:22PM +0800, Bill Hacker wrote: Old or new branches of X are rooted in a very different architectural philosophy than Win vid, and would have to start over from a clean slate to even match the sort of performance of an Amiga, BeBox, Warp/eCS or OS X deliver(ed) on comparable hardware. While I agree on most point, this needs some comments. The problem of current X11 based GUIs is not the protocol or architecture of the X server. The 99% of the slowdown is to completely broken toolkit design. Seriously, how could it have been possible to use a single 50MHz Power CPU and a 10mbit network for a number of X11 terminals 12 years ago? The difference is that applications and toolkits used an asynchronous protocol and had been greatly optimised to keep as much work as possible in the pipeline. Compare that to todays application. A simple GTK program over a slightly laggy WLAN link is visibly drawing itself a number of times whenever e.g. a menu has to be opened. *That's* why X11 performance today sucks. Everyone wants to program X11 like they program Windows, completly ignoring the roundtrip time. Joerg What is needed is really 'none of the above', IOW, there just *has* to be a better way. Two hints that it is possible include: - the snappy browser interface included with the QNX demo floppy of many years ago. - the Bluebottle/Greenbottle UI on Aos / Oberon. Lean, light, quick across the ground, and nearly indifferent to what video hardware is present, both of them. Plan 9 is another. Not much to look at, but the 'plumbing' is straightforward and low-load. 'X' had a reason to live in its early distanced server-client incarnation. Forget the KDE and Gnome resource hogs - even the so-called 'lite' desktops such as Xfce4 are slow and clumsy compared to a well-tuned Warp/eCS Workplace Shell. Most are arguably inferior to Win 3.11 in responsiveness and polish, given the same hardware. I don't see that much improvement is likely to happen on F/OSS - X or otherwise. OS X has closed the gate at one end, Vista will retain MS dominance even if they lose 30% of what is now a maket so huge an entity can get fats on the leavings. While we are generalizing, the 'C' language has long since become more a part of the problem than of the solution My tool of choice for I/O driver work was AS or Forth with native-code-compiler inlining. Never mind... I know where I can get a couple of nearly-new 17 G4 PowerBooks cheap when this one dies... Meanwhile, back at the data centre, we have migrated the 1U servers to VIA C3 with FreeBSD 4.11-stable and the 2U servers to Intel core-duo and FreeBSD AMD-64 6.1-STABLE. Plus one Xeon using 6.1, i386. Not sure DragonFly does C3 as well as 4.11, and reasonably certain DFLY is not AND-64 ready yet. But we'll keep one eye open... ;-) Bill
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
On Thu, July 13, 2006 9:26 am, Dimitri Kovalov wrote: The truth is that 99% of customers can't do anything with source anyway. Which is the problem with BSD. Its only usable but hackers because its so hard to make the videos/X stuff work. And most 'BSD circles tell you to fix it yourself, you have source', which is bad marketing. No commercial concern want to use something like that. There are people using BSD that have that attitude, but that isn't going to necessarily apply to DragonFly. I know that I certainly want more usability out of the system, like minimal maintenance needs for pkgsrc or a GUI that requires as little setup as possible. In any case, there's no ideological requirement against binary products in DragonFly, as there is with OpenBSD. Binary drivers/programs can and do have poor quality, and that can be frustrating when the resources exist to fix it. (Emiel Kollof and the NVIDIA driver, for instance.) But that doesn't mean a good one won't be used. I can think of a good number of programs that if they existed on DragonFly in binary-only form, I'd buy immediately. Cedega, or BBEdit, for instance. This is a lot of blue-sky talking, anyway. Until we actually have a binary-only driver or application to bitch about, this issue won't have any resolution. There are good vendors. Vendors that write bad drivers, you don't buy from them anymore. Its very easy. This I definitely agree with. Market forces are an excellent way to force quality improvement.
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Er. I don't think it has anything to do with video. It is quite simply the fact that windows has tens of thousands of user-friendly GUI applications and name brand software from thousands of vendors. Even Apple can't really compete with them, and Apple arguably has some of the best video interfaces in existance. I don't really think it is possible for us to compete in that area, at least not by ourselves. We have to rely on the larger open source community, in particular the more linux-centric community, to write and maintain the applications that drive a consumer market. If Open Source has an achilles heal then user-friendly application software is where it is. There are only a handful of OSS applications that are comparable with regards to user friendliness and easy-to-use features, and plenty of really *BAD* examples of UI software gone wrong (gimp's horrendously bad UI comes to mind). The UI is certainly not DragonFly's focus, and it will never be. We have to rely on the rest of the Open Source community to provide that piece of the puzzle. -Matt
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Matthew Dillon wrote: There are only a handful of OSS applications that are comparable with regards to user friendliness and easy-to-use features, and plenty of really *BAD* examples of UI software gone wrong (gimp's horrendously bad UI comes to mind). GIMP's UI is not that bad IMHO, at least compared to PhotoShop. I do not share your view in this, I think there are many OSS apps that have a better gui than their proprietary alternatives. The UI is certainly not DragonFly's focus, and it will never be. We have to rely on the rest of the Open Source community to provide that piece of the puzzle. Sure thing, but in my opinion a serious problem with open source desktops is the poor integration with the base system.
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
--- Matthew Dillon [EMAIL PROTECTED] wrote: Er. I don't think it has anything to do with video. It is quite simply the fact that windows has tens of thousands of user-friendly GUI applications and name brand software from thousands of vendors. Even Apple can't really compete with them, and Apple arguably has some of the best video interfaces in existance. I don't really think it is possible for us to compete in that area, at least not by ourselves. We have to rely on the larger open source community, in particular the more linux-centric community, to write and maintain the applications that drive a consumer market. If Open Source has an achilles heal then user-friendly application software is where it is. There are only a handful of OSS applications that are comparable with regards to user friendliness and easy-to-use features, and plenty of really *BAD* examples of UI software gone wrong (gimp's horrendously bad UI comes to mind). The UI is certainly not DragonFly's focus, and it will never be. We have to rely on the rest of the Open Source community to provide that piece of the puzzle. Creating a wrapper that vendors could use to recompile their windows drivers to work with your OS would solve the resource problem. Maybe its not doable, but conceptually it entices vendors to expand their market with minimal effort. Who would have recommended NDIS for FreeBSD? Modules make many things possible. Complaining that vendors don't make source available is like complaining about the government. You have to work within the environment that exists. So make it easier for them to support your OS, and maybe they will. Dimitri __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
On 7/13/06, Dimitri Kovalov [EMAIL PROTECTED] wrote: [...] Received: from [65.34.182.15] by web55908.mail.re3.yahoo.com via HTTP; Thu, 13 Jul 2006 10:06:16 PDT Message-Id: [EMAIL PROTECTED] From: Dimitri Kovalov [EMAIL PROTECTED] Received: from [65.34.182.15] by web33313.mail.mud.yahoo.com via HTTP; Wed, 14 Jun 2006 11:12:51 PDT Message-Id: [EMAIL PROTECTED] From: Danial Thom [EMAIL PROTECTED] It's safe to ignore him :) -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Ever try to draw a straight line with the GIMP? I had to read a tutorial on the internet just to learn how to draw a straight line. That's just bad UI design. GIMP's UI is not that bad IMHO, at least compared to PhotoShop. I do not share your view in this, I think there are many OSS apps that have a better gui than their proprietary alternatives.
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Dimitri Kovalov wrote: --- Bill Hacker [EMAIL PROTECTED] wrote: AMD-64 6.1-STABLE. Plus one Xeon using 6.1, i386. Talk about an expensive boat anchor! Dimitri Yes, boat anchors, at least for small craft, are considerably lighter and cheaper. But they don't support 2+ Terabyte fast SCSI raid arrays with 4-hour-max on-site warranty service response nearly as well. Horses for courses Bill
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
:On 7/13/06, Dimitri Kovalov [EMAIL PROTECTED] wrote: :[...] : :Received: from [65.34.182.15] by web55908.mail.re3.yahoo.com via HTTP; :Thu, 13 Jul 2006 10:06:16 PDT :Message-Id: [EMAIL PROTECTED] :From: Dimitri Kovalov [EMAIL PROTECTED] : :Received: from [65.34.182.15] by web33313.mail.mud.yahoo.com via HTTP; :Wed, 14 Jun 2006 11:12:51 PDT :Message-Id: [EMAIL PROTECTED] :From: Danial Thom [EMAIL PROTECTED] : : It's safe to ignore him :) I've already told him to get off our mailing listss, several times now. His IP is now filtered. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Joseph Garcia wrote: Bill Hacker wrote: - the snappy browser interface included with the QNX demo floppy of many years ago. Are you talking about that QNX enviroment that fit on just a 1.44MB floppy? That was like 10 years ago wasn't it? I have to admit. That thing was freaking AWESOME! It has a browser, networking, a GUI, start bar, and a few little tools/utilities that fit on FLOPPY! A freaking 1.44MB FLOPPY! Now-a-days you can't fit shit, or apple-butter, on a damn 1.44MB floppy. Yep, that thing was neat. Does QNX still do stuff like that? I guess these days people are impressed if they get the same kind of stuff to fit on a 32MB USB drive. Although, I bet QNX can do alot with 32MB, but I haven't looked at what they can do in almost a decade. Joey Given half a century in information technology, I could fill a website with more good ideas that have been abandoned than kept. Part of the 'challenge' is that the focus on *n*x and 'C', or 'the one true path' limits the scope of our vision. A 'hull-down' or 'foxhole' mentality loses wars, too. Bill
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Dimitri Kovalov wrote: cut You have it backwards. The reason BSD is all 'black boxes' is that it is not competitive or good in the video area. Apple can make it work because they sell the whole box and can control the hardware. But the open-source OSes don't have the resources to support video. It would be a good thing to have a model where vendors could easily take their windows drivers and make them work with BSD as a module. You know that vendors will make drivers for windows, so making it easy for them to port to your OS is good for everytone. Its time for open sourcers to realize they can't do everything themselves. I don't care if a driver is binary if it works. I want to have options. Dimitri A binary driver on a system doing public services? Not on my box! That's about the most important reasons why my windows servers are always in a DMZ and my OSS boxes are mostly not. But for anything else I'll say yes that would be convenient. However I lost the faith in manufactures creating good drivers, whether they are windows or anything else, but I guess that most manufacturers don't want to provide too much specs or source because then it's quite easy to see what a mess they sometimes make of their hardware. -- mph
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
On Sat, Jul 01, 2006 at 01:35:08AM +0200, Jose timofonic wrote: [...] While the following is focused on the NVIDIA FreeBSD graphics drivers, we believe the interfaces discussed below are generally applicable to any modern high performance graphics driver. That's the part where I completely disagree with. The first time I read the text I thought Oh, they could use this feature and this feature and this feature. But that wouldn't work on Linux. I guess that pretty much boils down my position. And what Emil said. Joerg
NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Hello, I found this on osnews (http://osnews.com/story.php?news_id=15056) and maybe it can be interesting for DragonFly too... http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html Here is a small part of the text: NVIDIA has been looking at ways to improve its graphics driver for the FreeBSD i386 platform, as well as investigating the possibility of adding support for the FreeBSD amd64 platform, and identified a number of obstacles. Some progress has been made to resolve them, and NVIDIA would like to summarize the current status. We would also like to thank John Baldwin and Doug Rabson for their valuable help. This summary makes an attempt to describe the kernel interfaces needed by the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with the Linux/Solaris graphics drivers, and/or required to make support for the FreeBSD amd64 platform feasible. It also describes some of the technical difficulties encountered by NVIDIA during the FreeBSD i386 graphics driver's development, how these problems have been worked around and what could be done to solve them better. While the following is focused on the NVIDIA FreeBSD graphics drivers, we believe the interfaces discussed below are generally applicable to any modern high performance graphics driver. Personally I don't like the use of closed-source device drivers, but maybe some suggestions mentioned on that message thread can be good for giving some ideas and improving DragonFly in many tasks too. Devs: What are your think about it? :) Best regards, timofonic PS: Sorry for the older message, I'm not in home and did a mistake when sending the message. __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com
Re: NVIDIA FreeBSD Kernel Feature Requests, interesting info for dfly?
Op zaterdag 1 juli 2006 01:35, schreef Jose timofonic: Hello, I found this on osnews (http://osnews.com/story.php?news_id=15056) and maybe it can be interesting for DragonFly too... http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html It's probably not. Here's why: Short answer: NVIDIA apparently has no interest in DragonFlyBSD. Long Answer: I used to be the maintainer of the DragonFlyBSD NVIDIA driver when the FreeBSD 4 userland and ours were the same ABI-wise. The only thing I needed to port was the kernel parts, and they were more or less open source (modulo one blob object which contained some OS-independant things). Suddenly, NVIDIA decided to ditch the FreeBSD 4 userland support and the only reply I got from them was similar to the short answer above minus the word apparently plus a lame excuse about not having the resources to release for another platform (which they contradicted by releasing drivers for Solaris). Porting the kernel bits is easy, because hey, that stuff has source I can muck with. The userland parts are closed up and they won't provide binaries that are compatible with our userland. So that leaves us stuck. Unless of course they suddenly contact us again about supporting DragonFlyBSD, but that doesn't seem likely. The real fix here would be for NVIDIA to stop being bone-headed and just open source that stuff so more people can have a go at it, or, and that's a pretty big or, them talking to a developer (like, oh, say, me for example) that will do the porting for them. Unless they suddenly see the light, fat chance they will go for either. [snip text from nvidia] Personally I don't like the use of closed-source device drivers, but maybe some suggestions mentioned on that message thread can be good for giving some ideas and improving DragonFly in many tasks too. I doubt it. Devs: What are your think about it? :) My opinion? Well nice for FreeBSD. But it's most probably not for us. Cheers, Emiel -- You need more time; and you probably always will. pgpVtFd8d2k6v.pgp Description: PGP signature
