Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 17 Jan, Atom Smasher wrote: > thanks john. > > i've been a long-time (10+ years) freeBSD user (desktops, laptops, > servers, and anywhere else i can run it) and advocate (encouraging others > to at least check it out) and also a long-time satisfied johnco customer. > > my freeBSD days seem to be coming to an end. > > i bought myself a LENOVO T510 when it first came out, around early 2010. > it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i > STILL can't run xorg properly with it. linux has run fine with it since i > opened the box. last i checked, freeBSD will be support this GPU in R9... > or maybe R10...? > > i really like freeBSD's robustness, especially compared to linux, among > other things. i like that freeBSD is genetically a "real" unix... what's > the real difference between BSD and linux? BSD was developed by unix > hackers porting the OS to PC hardware; linux was developed by PC hackers > trying to make their own version of unix. these origins are still very > apparent, if one knows where to look. > > i like that i can set up a freeBSD bare-bones (eg secure) mail-server or > web-server in an afternoon. > > but none of that matters if the damn thing just doesn't work. > > over the last two years, and it pains me to say this, i've been running > linux on that T510. but it gets worse... i've been finding that i'm simply > more productive on that machine, and spending more time in front of it, > and more time getting useful things done. > > i understand that it's ultimately a matter of manpower and resources, and > linux seems to have more momentum and "sex appeal", but i'm finding myself > in a real crisis of faith... the OS that i've been using and loving for > 10+ years seems to be dying, from any real usability perspective. > > and for now, i'm slowly and reluctantly migrating towards linux. My experience has been pretty much the opposite. I've been using FreeBSD since 2.1 both as part of my job and also for personal use. I've been using Linux for work for about the last ten years. I'm currently running FreeBSD 8.2-STABLE for my personal computing needs. My experience is that the base system has been very solid and the only problems that I run into have been with the ports. The last major problem that I had with the base system was USB printer support in 7.x, which was incomplete and flakey and then deteriorated to the point of being unusable. This motivated me to migrate to 8 which has a rewritten USB implementation. At work, our major software vendor only supports their software on Red Hat Enterprise Linux and SUSE Linux Enterprise. Since our budget is tight, we run CentOS, which is essentially a repackaged version of RHEL. We've been running CentOS 4.x, but are switching to CentOS 5.x now that 4.x has been EOLed. My experience with CentOS is that new features and support for recent hardware lags quite a bit. A few years ago I had a motherboard that I liked a lot that ran Fedora just fine, but CentOS lacked support for. It took a very long time before CentOS supported NFS over TCP. This was especially painful because we rely heavily on NFS across a WAN to support access to the same data from diferent sites. In addition our WAN is implemented using IPSEC tunnels, which have a smaller MTU, and Linux doesn't support manually setting the MTU on a per-route basis (and I wasn't able to get PMUTD to work). What I observed was that the NFS packets would first be fragmented to the default 1500 byte MTU and then the firewall would fragment each of those packets into one large packet followed by a tiny one. This, along with the lack of TCP's congestion control, was not beneficial to NFS performance ... Bugs are also slow to get fixed. For a very long time I had problems with gam_server running away. I'd frequently start top and see gam_server pegged at 100% CPU, stealing time from my simulations. If I killed it, it would get respawed, and would then behave itself for a few days before running away again. This bug eventually got fixed, but there's a kwin bug in CentOS 4 that still hasn't been fixed. Every now an then, kwin will stop working and I can no longer move windows around my desktop. I'm pretty sure this is fixed in a newer version of KDE, but RHEL/CentOS tend to stick with one major version of their "ports" forever, so I probably couldn't expect to see this fixed until I upgrade to the next version of CentOS. Things might be different if I was a paying RHEL customer and was able to motivate Red Hat into back porting patches for particular bugs. Another "feature" that I get to enjoy on a daily basis is that the kernel in CentOS 4 does not like my KVM switch. When switching to my CentOS machine, I have about a 50% chance that any mouse movement will cause the cursor to fly all over the screen and spew random mouse clicks all over my desktop. This typically causes a bunch of windows to pop up, and it also usually causes
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
"Mike Meyer" pisze: > On Wed, 25 Jan 2012 00:05:55 +0100 > vermaden wrote: > > > > I have now filled these PR's here: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 > > > Thanks. This makes these issues visible. > > One of them is already closed ... with ZERO changes, > > the reason from the person that closed it: > > "This is intended, as vsftpd is started by inetd" > > ... great, but not ALL FreeBSD users want to use inetd, > > why force them to compile it, is that one file that big > > or painful that it can not be added to the port? > > I don't know why the PR was closed this way, but given that the bug > report is simply a statement of a fact, without saying why you > consider this fact to be a bug, or any other justification for wanting > the change, closing it as "works as intended" seems like a perfectly > reasonable response. > > If you had explained *why* you wanted that changed, and provide some > justification for doing so (i.e. - point out that no inetd compliant > program, so the default config of the port won't run on the default > config of FreeBSD), you might have gotten a different response. > > Of course, that kind of discussion isn't really appropriate for a PR, > since it's really a feature request. As such it deserves a bit of work > finding out why it's that way to begin with. All of is covered in the > problem-reports document already mentioned in this thread: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ I have sent this in reply to that cosed PR: --- ... and if someone DOES NOT WANT to run it by INETD? Why force people to (definitely needless) compile process while this little option/small fail can make like so much easier for everyone that do not use inetd? There are multiple threads at FreeBSD Forums that this script is missing from the package. Also I do not no ANY OTHER package for daemon that has RC_NG script as an option, all of them provide RC_NG script by default, so that is what a user/admin is expecting. Adding this file does not break INETD functionality and only adds a sollution to start it by RC_NG script. Its just one harmless file, why is it such a big problem? --- Regards, vermaden ... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, 25 Jan 2012 00:05:55 +0100 vermaden wrote: > > > I have now filled these PR's here: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 > > Thanks. This makes these issues visible. > One of them is already closed ... with ZERO changes, > the reason from the person that closed it: > "This is intended, as vsftpd is started by inetd" > ... great, but not ALL FreeBSD users want to use inetd, > why force them to compile it, is that one file that big > or painful that it can not be added to the port? I don't know why the PR was closed this way, but given that the bug report is simply a statement of a fact, without saying why you consider this fact to be a bug, or any other justification for wanting the change, closing it as "works as intended" seems like a perfectly reasonable response. If you had explained *why* you wanted that changed, and provide some justification for doing so (i.e. - point out that no inetd compliant program, so the default config of the port won't run on the default config of FreeBSD), you might have gotten a different response. Of course, that kind of discussion isn't really appropriate for a PR, since it's really a feature request. As such it deserves a bit of work finding out why it's that way to begin with. All of is covered in the problem-reports document already mentioned in this thread: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> > It would also be good to have some wiki.freebsd.org page that > > would describe what information is needed to fill a good PR > > See: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ Thanks, I will read it. > > I have now filled these PR's here: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 > > Thanks. This makes these issues visible. One of them is already closed ... with ZERO changes, the reason from the person that closed it: "This is intended, as vsftpd is started by inetd" ... great, but not ALL FreeBSD users want to use inetd, why force them to compile it, is that one file that big or painful that it can not be added to the port? > > So its time for another article/page on wiki.freebsd.org, how to become > > a committer and help to solve PRs' > > See: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ > http://wiki.freebsd.org/BecomingACommitter Thanks I did not knew them, seems that there are a lot of useful materials/articles that are mostly known by developers/commiters and not 'casual' users, maybe a 'The Wall' page on freebsd.org with all these useful articles/pages? Kind regards, vermaden ... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 24 Jan 2012 15:23:47 -0600 Mark Linimon wrote: > On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote: > > It would be also good to have a wiki.freebsd.org page describing > > what is needed and in what format a user should send the > > documentation changes > > Perhaps there should be a docs analogue to the following: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ > > doc folks, any takers? You mean something like: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/ Making it a bit easier to find would probably be a good idea. http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote: > It would also be good to have some wiki.freebsd.org page that > would describe what information is needed to fill a good PR See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ . Your suggestion to include things like dmidecode is a good one, and we should add those. > I still was (or at least felt) that was a FreeBSD newbie that time, > so I did not knew if my 'handbook part' was just rubbish, or stupid, > or ... whatever, no one responded, so I assumed that its not > needed/useless and moved along. I'm hoping that the forums are a better place for new users to ask questions these days, than the high-volume mailing lists. In theory it should be a more appropriate venue. (Having said that, I don't participate in the forums due to lack of time, but I understand there is a community of moderators and seasoned users on it.) > It would be also good to have a wiki.freebsd.org page describing > what is needed and in what format a user should send the > documentation changes Perhaps there should be a docs analogue to the following: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ doc folks, any takers? > I have now filled these PR's here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 > http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 Thanks. This makes these issues visible. > So its time for another article/page on wiki.freebsd.org, how to become > a committer and help to solve PRs' See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ http://wiki.freebsd.org/BecomingACommitter > how to add your mirror to FreeBSD project See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/index.html So, let me add in conclusion, I'm willing to give a hearing to constructive criticism such as this posting. There are some good, concrete, suggestions here. If I've given the impression in my earlier response that I'm not, I'm sorry. OTOH I see a lot of non-constructive criticism go by and you'll have to excuse me for being rude to those posters. After the Nth posting like that it's simply too much for my patience. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, On Tue, Jan 24, 2012 at 4:10 PM, Mark Linimon wrote: >> On 24 January 2012 18:36, Arnaud Lacombe wrote: >> It is less a problem of having the tools than having the will to do >> everything publicly. From experience, committers loves to do all kind >> of things privately/secretly. > > Perhaps it's human nature because of all the increasingly nit-picky, passive- > agressive, whiny, sarcastic, and generally asinine postings such as yours. > You are indeed right. However, I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happens. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. regards. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
> On 24 January 2012 18:36, Arnaud Lacombe wrote: > It is less a problem of having the tools than having the will to do > everything publicly. From experience, committers loves to do all kind > of things privately/secretly. Perhaps it's human nature because of all the increasingly nit-picky, passive- agressive, whiny, sarcastic, and generally asinine postings such as yours. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 24 January 2012 18:36, Arnaud Lacombe wrote: > Hi, > > "Mark Linimon" pisze: >> We don't have a way to track emails that various users send to individual >> maintainers. With a PR open, we have a way to do that. We also track >> maintainer-timeouts, and these can eventually lead to a maintainer reset. >> > It is less a problem of having the tools than having the will to do > everything publicly. From experience, committers loves to do all kind > of things privately/secretly. Hm, a bit of a paradox-- I now deny that anything like that happens secretly, then you ask for proof? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Hi, "Mark Linimon" pisze: > We don't have a way to track emails that various users send to individual > maintainers. With a PR open, we have a way to do that. We also track > maintainer-timeouts, and these can eventually lead to a maintainer reset. > It is less a problem of having the tools than having the will to do everything publicly. From experience, committers loves to do all kind of things privately/secretly. - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Speeding up the loader(8).
2012/1/23 Edward Tomasz Napierała : > Some time ago I've spent some time on trying to speed up loading > modules by the loader(8). Result can be found at: > > http://people.freebsd.org/~trasz/fast-loader-3.diff > > This patch solves three issues: > > 1. As it is now, the code in biosdisk.c tries very hard to split > reasonably sized (up to 64kB, IIRC) requests into smaller ones. > > 2. The code in biosdisk.c rereads the partition table and probably > some filesystem metadata every time a file gets opened, i.e. > for every module. These reads bypass the bcache. > > 3. The code in bcache.c doesn't really implement an LRU - it implements > 'least recently added' algorithm, i.e. a kind of queue. Not that > it matters much, since it flushes the elements two seconds after > caching them anyway. I replaced it with Least Frequently Used. > LRU didn't behave well, as it tended to replace metadata with data > used only once. 4. it flushes cache on access to a different drive which means that cache does not help on multi-disk ZFS setups. I've posted a patch some time back. See http://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012527.html Feel free to combine the changes. --Artem > > In my tests under VMWare Fusion, this cut the modules loading time > by half. I don't intend to commit the patch as-is - the first part > looks dangerous (the splitting was probably done for a reason), > the second is hackish, and the third doesn't improve anything by itself. > I'm working on something else at a moment; feel free to pick this up. > > -- > If you cut off my head, what would I say? Me and my head, or me and my body? > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
"Mark Linimon" pisze: > On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote: > > I submit PRs and try to help test them as some developer/committer > > will pick up the PR, submit a patch to test, but it was MANY times > > that the response from developer/committer was way too long that > > I even DID NOT HAVE THE HARDWARE anymore ... > > I don't have a magic wand to solve this problem. I've spent a lot > of time thinking about it and it's just a hard problem to solve in > general. There are several aspects: > > - so many computers are very broken (specifically, horrible BIOS >bugs). > > - most committers only have one or two computers that they work with. > > - most committers have their own tasklist, and "support users" is >something they never have time to get around to. > > "support users" is, in general, something Open Source OSes do not > do very well (at least without a paid support staff, as is the case > in some of the Linux distros.) > > But what's discouraging for the people that try to clean up the stale > PRs is that they get yelled at when they try to do so. Thus, they > tend to get demotivated as well. > > Support/bug triage is hard and unrewarding work. People can tend to > feel that they're being blamed for bugs that they had nothing to do > with creating, and burn out. Hi, I do not have anything against You, or any other commiter/developer, maybe the answer to that PR should be 'I have checked that and that, but I do not have that hardware so no luck ...' It would be also great to have FreeBSD base system tool, that would collect all system data, dmesg, uname, hardware configuration, literally EVERYTHING, that would provide some useful input for a commiter/developer. It would also be good to have some wiki.freebsd.org page that would describe what information is needed to fill a good PR if such tool is not going to 'happen', I could write a simple SH script myself, that would collect dmesg/dmidecode/uname and more output from other commands, but I do not know what knowledge You need, so that simple program to get all that useful data can help a little, at least in theory. > > Here is one of the messages that I sent by then to the mailing lists: > > http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012507.html > > > > ... and NOTHING HAPPENED, no one told me what to do next, > > should I sent a SGML version or anything ... or just GTFO. > > I'm sorry that nothing happened, but unfortunately that's common. > Submitters sometimes have to be persistent, and maybe even catch > new committers when they sign up. Our documentation is certainly > in need of updating. I still was (or at least felt) that was a FreeBSD newbie that time, so I did not knew if my 'handbook part' was just rubbish, or stupid, or ... whatever, no one responded, so I assumed that its not needed/useless and moved along. It would be also good to have a wiki.freebsd.org page describing what is needed and in what format a user should send the documentation changes, currently its just wasting developers' time for asking them how to do that and that, what format, where to send it ... > > What I have done about these 'Ports issues'? I contacted these > > ports maintainers and said that both RC script and AIO support for > > samba should be enabled by default by linking to several threads > > at FreeBSD Forums that the problem is known and exists ... and I > > did not get ANY RESPONSE till this very day, not even a GTFO > > (which would probably be better then nothing). > > When you don't get a response from a maintainer, your best bet is to > file a PR against the port. If the maintainer doesn't respond, then > after 2 weeks any FreeBSD ports committer is free to work on the PR > and, if they agree with you, commit it via maintainer-timeout. > > We don't have a way to track emails that various users send to individual > maintainers. With a PR open, we have a way to do that. We also track > maintainer-timeouts, and these can eventually lead to a maintainer reset. I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 > > It's not that people does not try to help, a lot tried (and I am still > > trying), but its VERY unpleasant to have awareness, that you dedicated > > your time, tried to help as much as possible, made some steps to achieve > > that ... and no one even cares about that. > > I think it's not "don't care", I think it's that "unable to cope with > number of incoming PRs and other requests for changes and support". > As I type this, there are 1122 ports PRs (6272 total PRs). On most > days, around 40 come in. It would take a few dozen more volunteers > to be able to keep up with them all. > > mcl So its time for another article/page on wiki.freebsd.org, how to become a commiter and help to solve PRs', how to add your mirror to FreeBSD project, etc, etc ... Regards and have a n
