I've updated the Perl port to 5.10.1. However, I noticed later in the day there is a known security issue with Perl 5.10.1 in relation to utf-8 characters. I'll look into a patch tomorrow.
http://rt.perl.org/rt3//Public/Bug/Display.html?id=69973
http://perl5.git.perl.org/perl.git/commitdiff/0abd0d78a73da1c4d13b1c700526b7e5d03b32d4
MidnightBSD current contains Perl 5.10 which is not vulnerable.
I started the day with a little development work on MidnightBSD. Many people think I'm wasting my time working on an open source project, particularly when it hasn't taken off like they think it must to "beat" ubuntu. The reason I keep working on this project is two fold. First, I enjoy the experience. It's fun to work on a long term project with many different aspects to it. I can work on anything from an installer to a device driver to a port of an application that I like to use. Sometimes, I find it quite relaxing. it's different from the Java based web development that I do at work. Second, I am convinced that a UNIX desktop environment is the best approach. Sure some things have to be changed to make it fit that environment. Some days I just look at Mac OS and see what is possible. Apple didn't make all the right choices in my mind, but it certainly proves that it's possible. BSD on the desktop is a good idea.
Many of us in the open source community have been arguing and duplicating effort over the years. Sometimes there are good reasons for it, but many times it's just a big terrible twos style tantrum. Many people were angry at me when I started this project. How dare I fork a server OS for a desktop? The FreeBSD community at that time did not care about the desktop. Sure, there were ports for this or that but it was not even on their radar. Today, they've been pulled into embedded systems and some desktop exposure due to PC-BSD and DesktopBSD. There were improvements in their ports infrastructure, list of applications, utilities and updating tools for the OS, and even a little improvement in the attitude their developers have toward the desktop. Some people within the project have passion about the desktop. Still, you mostly hear excitement about embedded systems where they can get corporate assistance and funding (freebsd foundation, etc.) There's nothing wrong with that, but embedded systems is a completely different direction from what I see as a good desktop OS. Embedded space is huge but traditional systems are very small. Any electrical engineer will tell you that. I intentionally chose a subset of the full x86 market because I feel users need special attention to their daily computing habits. They need a stable, secure, virus free environment with structure and consistency. The linux community can't offer this consistency due to the adhoc nature of development between the kernel and various components. We're also limited by the X.org development and the fuss around various components, but at least the base system is under our control.
I was sent an e-mail this even asking for assistance with another project. Many other developers from this and other BSD communities received the same e-mail. I thought about the best way to respond for some time. I believe in BSD on the desktop, but for the reasons found in that projects forums, I know that this can only be accomplished with greater control. I did not make a distro of freebsd because I don't feel we could maintain a stable system with enough stability. It is not possible to keep throwing bandaids on an OS that differ as it targets routers and cell phones for your desktop. It just doesn't make sense. FreeBSD is a damn good server OS. It may turn out to be an ok embedded system, but frankly I think NetBSD has that market.
Since we appear to be near the last man standing (like highlander?), it appears I can't give up on my dream.
tags: desktop future midnightbsd os direction
graphics/cairo: 1415
AMD64 MidnightBSD 0.3-CURRENT works using WITHOUT_LIB32=yes in /etc/make.conf. We're working on the 32bit libs problem. That means i386 and AMD64 can be built on current again. I'm hoping to start sparc64 testing soon.
I've spent the last week getting the mports tree back in order. We let a number of ports get stale while working on other projects. It's time to get caught up.
These results are poor, but roughly 100 ports now work that did not before. We had some X.org dependancies fail; I checked in the corrections for those ports. A new run was just started. We should have the results in about two days.
Ports such as libdvdread, libtool, gtk, and browser 3 all had some tlc this week. We're also updating PHP, Apache HTTPD, Lighttpd, and a few other web related ports. Many perl ports have been updated, particularly database related. Bind 9.5 was removed in favor of 9.6. Some of these changes are not present in the results below.
Ports we need to get updated or working:
virtualbox, firefox 3.5 unbranded, p5-DBD-Pg, remaining gnome ports (50% of 2.26 is in), KDE4, GNUstep (updates), Etoile, postgres (updates)
Here are the last results from Magus on AMD64 0.2.1-p10
I just spent most of the evening swapping out components into another case + motherboard only to find the heatsink was dead. I didn't notice until the system powered off with a CPU temp of 86C! So I had to go back to the Pentium D. it looks like the plastic clips broke. I'll have to get one with a backplate when I replace it.
I was looking forward to a decent database server for home and work...
graphics/cairo: 1359
I've been trying to catch up on some ports work I've let slip by during the 0.3 development. This week I've updated to libtool22 (with some help from smultron), removed autoconf 2.61, updated some X ports, and about half of the ports in mail.
I also updated mysql to 5.1.38.
I've been working on getting some of the ports fixed lately. We've still got over 100 ports that are currently broken. I've managed to update part of Gnome, and add MySQL GUI tools (Administrator and query browser) ports.
I've found a number of bugs in the latest version of X on MidnightBSD. I'm trying to get my new laptop up to snuff so I can perform testing on different hardware.
Our magus run is almost complete. I've already fixed several ports found to be
broken during the run.
We've had our ipv6 tunnel down since Thursday morning. Apparently, some users of sixxs have experienced problems with static tunnels from the chicago POP. I'm hoping that it will be resolved soon.
Over the weekend, I got an opportunity to update some mports wtih fetching errors per the last AMD64 0.2 magus run. The results are as follows:
I just purchased a Toshiba L305-S5955. It wasn't my first choice, and I had neglected to do proper research on a few points. This laptop comes with an Intel Celeron 900 2.2Ghz single core cpu, 2GB of RAM, 160GB hdd, Realtek pciE NIC (10/100) and a Realtek USB wifi 802.11b/g card. That's right, the wifi is on the USB bus inside the laptop.
Obviously, since we don't have native support for this wifi card and it's usb there is no way to use it. Our ndis wrapper does not support USB wifi devices.
Interestingly, the ethernet adapter does not work either. This is one of Realtek's newer parts and it is not supported by rl or re. Due to the pciE nature, I'm going to work on getting this integrated into re(4).
The laptop is fully supported in Ubuntu Linux, so we're certainly trailing on hardware support for newer systems.
The sad thing is the realtek card works much better in windows or ubuntu than my previous linksys pccard with a broadcom chipset. (yeah i really pick em)
Aside from the hardware support issues, I've been pleasantly surprised by the build quality of this laptop considering it's low cost. It's not at the same magnitude as my old T30 Thinkpad, but it's good.
All dns ports have been checked for security updates and updated including BIND 9.5 and 9.6. I've removed BIND 9.4 from mports as it's included with the base system (current) and it's the oldest version still supported. It's also three versions back at this point.
For the few people using MidnightBSD as a server platform instead of a desktop, there is a security update available for named(8). A denial of service attack is possible against BIND using dynamic update packets. It causes named to exit.
There were a few issues on this run. First, the tarball used wasn't setup properly for linux ports. It was assumed that linux base fc4 was used by the indexer, yet fc8 was setup in make.conf by accident.
mport.create seems to hang on bouml-doc for no apparent reason. No disk activity is in progress. It just consumes cpu cycles for hours. This port works with the old tools.
I'm going to attempt to rerun the ports with internals. That appears to be a node problem.
I recently purchased new video cards for my system. I wanted to get the new cards working in CURRENT with the latest version of X from mports. After several lockups and other odd behavior, I found that I had to disable the second graphics card (crossfireX in windows) in the X configuration along with removing the keyboard and mouse configuration. I was then able to start the X server with the radeonhd driver. Don't expect acceleration yet.
If you've had trouble building db45, db46 or db47 on current, try updating your sources. A fix was included in the world that corrects the problem. There have also been recent updates to fix crashing bugs with SSL enabled mports on current.