login
Search
Mark Murray recently started a thread on the "current" FreeBSD mailing list regarding "the future of Perl on FreeBSD". He says, "The recent removal of the CGI perl module from CURRENT started a very lively discussion on both the perl lists and some FreeBSD ones." The Perl community's complaint is that Perl should be included fully or not at all. The complaints against Perl include it's increasing size and the fact that FreeBSD as an OS makes little use of Perl.
Three possible solutions were suggested: 1) leave Perl in the base and deal with it. 2) split Perl into two pieces, base and libraries. 3) remove Perl and make it a port which a user can add as s/he wishes.
Most responses endorsed the third option, though there is work in making this possible. Matthew Dillon pointed out several core programs that use Perl, suggesting as a workaround adding a 'miniperl' to be included in base that these programs could point to, but that would not conflict in any way with the Perl port.
Josef Karthauser recently posted to the current FreeBSD mailing list, describing the status of recent USB stack changes. He explains, "The background is that I've been porting the developments that NetBSD has had into FreeBSD. In some cases we were two years behind the state of the art. Today we're in a much better shape."
Recently there have been some complaints to bugs in the updated USB stack, some people going so far as recommending the whole change be backed out. Josef's email was a comprehensive update on the project, listing three remaining bugs to be fixed:
Looking ahead to after these problems are resolved, Josef says, "The good news is that once these issues have been resolved we are in a good position to port the drivers that NetBSD have but we've not seen yet. There are lots, like uaudio and uvisor, that we should take avantage of."
Jordan Hubbard recently announced that he was stepping down from the FreeBSD core team, "After giving it a fair bit of thought over the last few weeks, I have decided to step down from core. I am doing this for a variety of reasons, any one of which would probably be sufficient grounds in and of its own and, taken in combination, certainly constitute ample justification for doing so". His reasons included a lack of time and energy, a feeling that the core group isn't what it once was, and a recent lack of personal enjoyment. He currently works for Apple as an engineering manager for the BSD based Darwin Project. He intends to continue contributing to FreeBSD as well.
A recent thread on the FreeBSD hackers mailing list began when Jordan Hubbard reported odd behavior with ssh in the 4.5-STABLE tree. The change in behavior was due to a change in the default setting in the interests of security. During the dicussion another change to default behavior was brought up where X11 now has TCP forwarding disabled, prefering instead that the users tunnel X connections through ssh.
Much of the resulting protest was at how this changes FreeBSD's default behavior, creating confusion. Joerg Micheel said, "The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century."
The attempt is to make the default installation more secure. Terry Lambert points out, "I really don't think there's any way to fully protect a security-unconscious user, as if they had spent the time to learn what was necessary, and chosen the right settings for their site. Nothing can replace a system administrator who knows which end is up."
Finally, as the conversation considered whether such changes were security by obscurity, Robert Watson offered, ""Security by obscurity" refers to a behavioral phenomena in system design and delivery, not to a technical design principle. For example, it refers to using a secret algorithm, but does not refer to using a secret key with a published algorithm. So disabling services in a default configuration reduces risk by reducing exposure, but it's not security by obscurity. "
Hidetoshi Shimokawa recently posted a link to a FreeBSD FireWire driver, pointing out that it allows you remotely run gdb, even when the host you're debugging has crashed:
"As you know, IEEE1394 is a bus and OHCI supports physical access to the host memory. This means that you can access the remote host over firewire without software support at the remote host. In other words, you can investigate remote host's physical memory whether its OS is alive or crashed or hangs up."
Hidetoshi's full email follow's, as well as a security concern raised by Katsushi Kobayashi.
Murray Stokely posted the following to the FreeBSD announce mailing list:
"A Developer Preview release of FreeBSD 5.0-CURRENT is now available for widespread testing. This preview is a significant milestone towards the eventual release of FreeBSD 5.0 in late 2002."
5.0-DP1 is available for the i386, alpha, and sparc64 architectures. Murray's full announcement email follows, with complete details as to what's included in this release and where to get it. Also check out the release notes and errata.
FreeBSD Security Advisories have been routinely sent out in the past to advise of security issues in the base FreeBSD system, as well as occasionaly in third-party applications.
The advisories tend to be a thorough look at the problem, and certainly take time to prepare. In an attempt to be more timely with security issues, Advisories are being split into two parts: Notices and Adivisories. The former are new and are to be used to notify of third party software security issues. Advisories, then, are left for FreeBSD specific issues and will retain their comprehensive format.
To keep up to date on FreeBSD security issues, you can subscribe to the FreeBSD Security Notifications mailing list. All advisories are archived on this web page.
On the FreeBSD-Hackers mailing list, John Regehr discussed a paper he's working on about a tool that measures scheduling behavior on different operating systems. While writing this paper, he noticed an anomaly between the context switches in FreeBSD versus Linux.
Terry Lambert replied to John's query with a lengthy and informative response. In it, he predicts,
"I expect that under real load, the relative performance of FreeBSD vs. Linux will depend on the number of threads in a thread group (threaded process). I expect that under real load, you will see that FreeBSD performs well at 6 for 2 CPUs (that's the expected break-even point of random replacement vs. ordered replacement with starvation), and at more than that, FreeBSD performance will degrade slower than Linux for more threads (processes with shared VM), but degrade faster than Linux for more CPUs.
"I also expect that FreeBSD 5.x, when released, will blow the doors off of most commercial offerings, even though I would have done a lot of things differently (e.g. interrupt threads). I look at these issues as "room for future improvement" that other OS's don't have."
Mike Silbersack recently announced a plan to change the FreeBSD default ephemeral port range from 1024-5000 to 49152-65535. A debate on the usefulness of this change followed. During that debate, Mike explained:
"The ephemeral port range determines the maximum number of simultaneous outbound connections that you can have. As pointed out in a PR (I don't recall the # offhand), our low limit was probably the reason that FreeBSD ran out of steam before the other OSes in the sysadmin benchmark last year."
This greatly increases the outgoing pool, from 3,976 ports to 16,383 ports. You can find information on changing the ephemeral port range in FreeBSD here (allowing you to locally revert the upcoming change if it causes you problems). The same document provides instructions for Linux, OpenBSD, Solaris, Windows and many other operating systems, too.
A recent email brought to my attention the existence of the freebsdforums, a website with online bulletin boards for discussions about FreeBSD. The site looks fairly active...
Dimitar Peikov recently posted a small tool to the FreeBSD-Hackers mailing list. The tool was intended to help him compare malloc between the FreeBSD and Linux kernels. This particular test was faster on Linux than FreeBSD, and he asked why.
The responses by Matt Dillon and Terry Lambert make for an interesting reading, explaining much of the differences between Linux and FreeBSD VMs.
Herve Quiroz recently asked on the freebsd-stable mailing list why the XFree86 4.2 port was no longer available for FreeBSD.
Amidst the resulting discussion, Kevin Oberman explained that it was being redistributed as a meta-port, offering the advantage of being upgraded in pieces. Due to the extremely large size of XFree86, it lends itself well to this strategy.
Additionally, the XFree86 4.2 port was too new and thus insufficiently tested for inclusion in the FreeBSD 4.5 release.
There was a soft updates bug that crept into 4.5-RELEASE, and could cause corruption on shutdown if there was heavy disk activity before the shutdown took place. This hasn't shown up on any lists I read, but it seemed a bit more noteworthy than the latest security hole in some obscure port (no, not PHP).
Robert Watson, of the core FreeBSD team, recently sent a message to the 'Current' FreeBSD mailing list, looking to initiate a constructive discussion to develop guidelines for the use of source control software beyond the main CVS repository. The end goal to create "a set of recommendations to maximize communication and acceptance by the broader community".
This is in response to recent lengthy discussion of the many source code repositories used, and the lack/difficulty of communication between all involved as to what's where. Robert's full email follows.
A recent conversation on the FreeBSD hackers mailing list discussed the possibility of remote kernel debugging, utilizing the polling support of some Ethernet drivers. This is implemented on other systems already, including, it was pointed out, on Apple's Darwin.
The ensuing conversation on the FreeBSD hackers list follows.
