FreeBSD Foundation Newcons Project Highlight

Spring Fundraising Campaign - Newcons Project Highlight

Our Spring Fundraising Campaign is in full swing, and we couldn't be more grateful for all your support! We are honored to be the stewards of your donations for the FreeBSD Project and community. Around half of our funding goes towards project development to help keep FreeBSD an innovative, reliable, and high-performance operating system

During our Spring Fundraising Campaign, we are highlighting the projects we are funding to show our commitment to helping FreeBSD. Please take a moment to read about the Newcons project.

What is the Newcons project?
The Newcons project provides a replacement system console for directly-attached displays, keyboards, and mice.  It replaces the legacy syscons driver, sc(4), and is short for “new console.”  Because it won’t be “new” forever and will become just “the console,” it is more correctly known by the name of the device driver, “vt.”

Why does FreeBSD need a new console?
Newcons provides a number of benefits, including support for Unicode and UTF-8, and double-width characters.  This eliminates the historical text-mode limit of 256 characters, and allows for Chinese, Japanese and Korean (CJK) and other character set support on the console.

Without Newcons it’s not possible to switch back to the console after starting the X graphical environment.  Newcons allows this by integrating with Kernel Modesetting (KMS), the method of changing graphics modes used by current display hardware drivers and X.org releases.  This integration also enables high-resolution consoles.

Newcons also provides an improved infrastructure that is not user-facing, but enables simplified support for new hardware.

What work is the Foundation sponsoring?
The Foundation awarded a development grant to Aleksandr Rybalko to implement missing functionality, and finish integration tasks.  Completed tasks include history buffer improvements, kernel mode setting integration, and additional hardware device support.  This work is already available in FreeBSD-CURRENT.

Documentation and performance improvements are the main outstanding tasks; font setting and other user interface features are also in progress.  The “vt” driver is expected to be available in the FreeBSD 10.1 release.


Donate today to help us continue and increase our support of the FreeBSD Project and community worldwide! To make a donation go to: http://www.freebsdfoundation.org/donate/.

Weekly Feature Digest 27 — Software System Redesign

PC-BSD has long been very flexible about how you can install software. You have PBI’s, packages, and ports available with just a couple clicks or via a couple of simple terminal commands. For a long time the PBI format has served as an excellent solution for people who may need an offline package install, or just simply prefer the ease and simplicity the PBI format has to offer especially via the AppCafe. Perhaps the “Achilles’ Heel” of this situation is that we have also been severely limited on the amount of software that the AppCafe has to offer as packages had to first be converted into the PBI format.

This week we are announcing a radical change that we think will benefit all PC-BSD users in ways that were previously unthinkable. The PC-BSD team has begun work during the last couple of weeks redesigning our PC-BSD utilities (AppCafe, Update Center) to work with our pkgng software repository that we are currently building to contain detailed information about all the software available through packages and PBIs. What this means for you is that in the near future PC-BSD will have a much broader software pool to pull from, and will not be limited anymore by only having a small subset of PBI’s. You will now be able to install packages and PBI’s in one place, while also being able to update and manage both in one place.

You may be asking yourself “why the change?”. Over the last several months we have noticed a considerable amount of our time has been going into compatibility and fixes for PBIs. So much time in fact that other important development had to be postponed and / or sidelined while we worked on bringing PBIs up to speed. We are hoping by adopting appcafe and the PBI format to work in tandem with pkgng, that we will be able to refocus our efforts on other important endeavours.

We will have more information available soon as development continues on how you can get involved with testing out the new features and submitting ideas to help the project along. Let us know what you think about the changes. Are we headed in the right direction? Do you have ideas related to the redesign that you’d like to contribute? Let us know!

Key Features:

Much larger software library. Instead of 800 available appcafe applications think more like 10000+
Detailed information on all the software available including packages in one place
Ability to search and filter your results to show
Improved compatibility across desktop environments
New rating system is being developed for grading the quality of packages in the AppCafe library

FreeBSD Foundation Spring Fundraising Campaign – Funding Highlights

Spring Fundraising Campaign - Funding Highlights
As we embark on our 15th year of serving the FreeBSD Project and community, we are proud of what we've done to help FreeBSD become the most innovative, reliable, and high-performance operation system. During our Spring Fundraising Campaign, we are going to highlight where some of our funds are going to show our commitment to helping FreeBSD.

The first project we are highlighting is the UEFI Boot Support. Please take a moment to read about the work going on in this area.

What is UEFI and why is the FreeBSD Foundation sponsoring this work?
UEFI is the Unified Extensible Firmware Interface, a new standard for boot firmware -- the software that runs from the time a computer powers on, until the main operating system is loaded.  It was originally developed for Intel’s “Itanium” CPU many years ago, with x86 and ARM support arriving later. 

Many desktops and servers sold today provide the option to choose between UEFI and legacy BIOS boot modes, but some support only UEFI. UEFI-only systems will become increasingly common in the future, so supporting UEFI boot is a requirement for FreeBSD to remain viable on contemporary hardware.

Why did we need a new boot firmware?
The PC BIOS is over three decades old, and was designed with different goals than are relevant today. It was responsible not only for booting, but for providing runtime services like reading files or printing characters on the screen.  As operating systems evolved from 16-bit code to 32- and 64-bit, the BIOS was relegated to providing only the initial boot functionality, but limitations of 16-bit code from the 1980s persisted.  BIOS boot does not inherently support features like large disks, multiple operating systems, or network booting that are now standard.

These issues have all been worked around with various add-ons, but often in a vendor-specific or inconsistent way.  UEFI replaces the workarounds and layers of complexity with a consistent and powerful set of boot services.

What work is the Foundation sponsoring?
In 2013 the Foundation sponsored Benno Rice to perform some initial investigation and infrastructure work for amd64 UEFI booting, which resulted in a working proof of concept.  Ed Maste later refined that work and brought it to the main FreeBSD development branch, giving FreeBSD-CURRENT the ability to boot via UEFI.

Ed and Foundation staff members Glen Barber and Konstantin Belousov will continue with work to build snapshot images, fix bugs, address hardware compatibility issues.  We’re committed to finishing UEFI boot integration, documentation, and installer support, and appreciate the support of the FreeBSD community’s collaboration on some of these pieces.  Initial UEFI support will appear in the FreeBSD 10.1 release, due later this year.

Donate today to help us continue and increase our support of the FreeBSD Project and community worldwide! To make a donation go to: http://www.freebsdfoundation.org/donate/.

Quick Lumina Desktop FAQ

I am seeing lots of interest and questions about Lumina since it was mentioned in the PC-BSD weekly update last week, so I am just going to try and answer some of the big questions that I have been seeing.

(1) What is Lumina?
Answer: Lumina is a lightweight, BSD licensed, standards-compliant desktop environment based upon Qt and Fluxbox. It is being developed on PC-BSD, and is being packaged for distribution on the PC-BSD package repository as well (although I believe the FreeBSD port is going to be submitted to the FreeBSD ports tree by the PC-BSD project as well).

(2) How complete is it?
Answer: It is currently alpha version 0.1, so lots of things are still unfinished. It has full backend XDG-compliance through the “lumina-open” utility for launching applications or opening files/URLs, but the graphical interface is still being fleshed out. It also has a plugin framework for toolbars, toolbar plugins, and desktop plugins already written, even though there is not many plugins written to actually use yet.

(3) Since it is an alpha, is it usable?
Answer: Yes, if you are used to very minimalistic desktops. I would currently label it a step above pure Fluxbox for usability, since it uses the XDG compatibility to provide access to system applications and desktop files, and is tied in to xdg-open on PC-BSD so that individual applications can open files/URLs using the current system default for that type of file/URL. The main thing is that the interface is extremely bare at the moment (no desktop icons/plugins yet), so you just end up with a background and toolbar(s). It is also still missing some configuration utilities, so you might be stuck with the current defaults for the moment.

(4) Why create a new desktop environment? Whats wrong with KDE/GNOME/XFCE/<other>?
Answer: There are many reasons for needing a new desktop environment instead of using the existing ones, mainly because all the major existing DE’s are developed on/for Linux, not BSD. This causes all sorts of problems on BSD, and I am going to try and list a few of the big ones here:

(4-a) Porting time
Since the DE’s are written on/for linux, they have to be ported over to BSD, and this introduces a (sometimes significant) time-delay before updated versions are available (GNOME 3 anyone?).

(4-b) Porting quality
It takes quite a bit of time/effort to port a DE over to BSD, and I have to give lots of thanks to the people who volunteer their time and energy to make them available. The problem is that quite often “linuxisms” still bleed through the porting process and cause system instability, desktop/X crashes, and loss of usability on the part of the user. This is particularly true when you start looking at KDE/GNOME/XFCE because of the large number of individual pieces/applications/plugins that have to be checked during the porting process, and it gets quite difficult to check everything while doing the port.

(4-c) Linux development trends
As Linux trends continue to diverge from BSD through reliance on Linux kernel functions or Linux-specific systems/daemons, the porting process over to BSD is going to get even more difficult and take longer to accomplish. This means that if we want to have a reliable/stable desktop on BSD going forward, we have to have one designed specifically for the BSD’s.

(4-d) Linux dependency bloat.
If you look at current DE dependency lists, it is easy to see that when you install a desktop, you might be getting a lot more than you bargained for (such as additional compilers/programming languages, network libraries/daemons, audio/video daemons/applications, etc). While there might be some debate on this, my opinion is that it comes from the Linux distro mentality. Just as a Linux distribution is the Linux kernel + the distro’s favorite packages, the desktop environment is becoming the graphical interface for the system + all the favorite applications/libraries of the developers, whether or not they are actually necessary for satisfying the actual purpose of a desktop environment.
I feel like the approach on BSD is quite different because the OS is a complete entity, independent of the packages that get added later, and simply provides the framework for the user to do whatever they want with system. By this same approach, a desktop environment should simply provide the graphical framework/interface for the user to easily interact with the system, independent of what applications are actually installed on the system. Now, I understand that at this point in time a user expects that certain types of applications are expected to be available out-of-box (such as a file manager, audio/video player, pdf viewer, text editor, photo viewer, etc..), but is that really the realm of the DE to decide what the defaults are, or should it be left to the distributor of the OS? I think a point can be made that the file manager is considered essential to integrate with the DE appropriately, but I think that things like audio/video applications, text editors, pdf viewers and such are really up to the preferences of the distributor, not the DE. The DE just needs to provide a simple framework to setup those initial default applications for the distributor, not require a ton of additional applications by default. Because of this, I am taking the approach that Lumina will have a very limited number of applications included by default (there are only about 2–3 that I can think of, all written from scratch for Lumina), and will try to include basic user-level functionality within these few applications to try and cover 90% of standard user needs (at a basic level) without any additional dependencies. For example, the Lumina file manager will have basic audio/video playing and image viewing capabilities built-in because those types of abilities are available through the Qt framework without many/any additional dependencies.

(5) What kind of graphical appearance are you planning for Lumina?
Answer: Highly configurable… :-)
By default, I am planning for Lumina to have a single toolbar on the top of the primary screen with the following item (from left to right): UserButton, DesktopBar, TaskManager, SystemTray, and Clock. This toolbar can be configured as the user desires (or completely removed), and other toolbars can also be added as well (only two per screen at the moment, one on top and one on bottom).
I do *not* plan on having the desktop be covered with the traditional desktop icons (that is taken care of with the DesktopBar toolbar plugin). Instead, it is simply a graphical canvas for the user to place all sorts of desktop plugins (directory viewers, picture viewers, notepads, application launchers, and other “stuff”).  I have not decided on any default desktop plugins yet, simply because I have not written any yet.

(6) What is the “User Button”?
Answer: This is what would correspond to the “Start” button on other desktops. This provides a central place for the user to do things like launch an application, open up one of their directories, configure their desktop settings, or close down their desktop session. Basically, an easy way for the user to interface with the system.

(7) What is the “Desktop Bar”?
Answer: This is a toolbar plugin that takes the place of the traditional system of desktop icons. The original purpose of desktop icons was to provide quick shortcuts for the user to open applications or put links to commonly-used files/directories, but quickly became abused with people putting everything on the desktop — destroying the intended purpose of the desktop by forcing the user to spend a lot of time trying to find the particular item they need in the chaos that became the desktop (I am sure you have all seen this many times). The desktop bar takes the original purpose of the desktop, and refines it to provide the quick access the user needs even if there is tons of “stuff” in the ~/Desktop folder. It does this by an intelligent system of sorting/categorization, splitting up the desktop items into three main categories: application shortcuts, directories, and files. Each of these three categories gets it’s own button on the toolbar with items sorted alphabetically (if there is anything in that category), so that it is easily accessed by the user at any time, even if you have the desktop covered with open windows, or you have a lot of that type of item. Additionally, it also separates out the actual files in the desktop folder by type: audio files, video files, pictures, and “other”. This should also help people find “that one file” that they need with a minimum of effort.

(8) Is Lumina the new default desktop for PC-BSD?
Answer:  NO!!! While Lumina is now available on the PC-BSD package repository, it is by no means the new default desktop.

 

(9) Will it become the default desktop for PC-BSD eventually?

Answer: Possibly, it really depends on how well the development on Lumina goes and if  the PC-BSD development team decides to make the switch to it at a later date.

 

(10) Will it become the *only* supported PC-BSD desktop?

Answer: Definitely not!! PC-BSD will continue to support multiple desktop environments and window managers through both the installer and the post-installation package manager.
I hope this help to clear up some of the questions you have!

Dark Patterns

The term dark pattern was coined (I believe) by Harry Brignull to describe practices in user interface design intended to make it easy for your users to accidentally select a more profitable (for you) option and hard for them to revert, cancel or unsubscribe.

This is not news. We all know how, for instance, low-cost airlines try to trick you into ordering travel insurance, or software installers try to trick you into installing browser toolbars. But it’s something we usually associate with slightly dodgy outfits like RyanAir or Oracle.

I recently learned that Adobe really, really wants you to buy Acrobat XI Pro. It costs twice as much as Adobe XI Standard and is loaded with features that few people need. Arguably, few people need Acrobat XI Standard either—but I have a lot of papers to scan and if there’s one thing Acrobat does better than any other software I’ve encountered, it’s scan and post-process documents.

Go to Adobe’s front page and select Acrobat from the Products drop-down. You get your average product page with product information, testimonials, awards, stock photos of happy people (presumably, Acrobat is what makes them happy), and a sidebar that offers you the Pro and Standard versions. The sidebar doesn’t list the full price, however, because Acrobat is pretty expensive. Instead, they show you the price of an upgrade from a previous version. They also offer you a free evaluation license, but there’s no evaluation license for Acrobat XI Standard. So you download and install an evaluation copy of Acrobat XI Pro and use it for a while and start to really like it. It keeps popping up a dialog nagging you to buy a full license, and finally you decide to do so and click the “Buy” button. It brings up the Adobe Store in a browser window with Acrobat XI Pro already in your shopping cart, and you think “No! I wanted the standard version!” and try to change your order, but you can’t actually convert the item in your cart from Pro to Standard, so you end up having to empty your card and navigate through the store until you find the correct version. You pay and download and run the installer, but it refuses to run because you already have a better version installed (i.e. your unlicensed evaluation copy of Acrobat XI Pro) which you have to manually uninstall before installing your licensed copy of Acrobat XI Standard.

But at least you can scan.

Weekly Feature Digest 26 — The Lumina Project and preload

This week the PC-BSD team has ported over preload, which is an adaptive readahead daemon. It monitors applications that users run, and by analyzing this data, predicts what applications users might run, and fetches those applications and their dependencies to speed up program load times. You can look for preload in the next few days in edge packages and grab it for testing on your own system.

There is an early alpha version of the Lumina desktop environment that has been committed to ports / packages. Lumina is a lightweight, stable, fast-running desktop environment that has been developed by Ken Moore specifically for PC-BSD. Currently it builds and runs, but lacks many other features as it is still in very early development. Grab it from the edge packageset and let us know what you think, and how we can also improve it to better suit you as a user!

Other updates this week:

* Fixed some bugs in ZFS replication causing snapshot operations to take
far longer than necessary
* Fixed an issue with dconf creating files with incorrect permissions
causing browsers to fail
* Added Lumina desktop ports / packages to our build system
* PC-BSD Hindi translation 100% complete
* improvements to the update center app
* Update PCDM so that it will use “pw” to create a user’s home directory if it is missing but the login credentials were valid. This should solve one of the last reported issues with PCDM and Active Directory users.
* Bugfix for pc-mounttray so that it properly ignores the active FreeBSD swap partition as well.
* Another small batch of 10.x PBI updates/approvals.

Have you never been to BSDCan?

I remember a time when I’d never been to a conference related to my passions. Once I went, things changed. I realized that making strong working relationships with others who share my passion is important. Not only does this solidify the community of which you are a member, it also helps you personally. Every conference [...]

PC-BSD Weekly Feature Digest 25

Most of you have already heard of the Heartbleed vulnerability, the flaw in OpenSSL encryption. For any of you that may not be aware (which is probably precious few), the Heartbleed vulnerability is basically a flaw that may allow a malicious user to gain access to information that is supposed to be kept safe through OpenSSL. The good news is that the FreeBSD project and PC-BSD have both released fixes that will apply to versions 10.x. If you are currently running a machine with PC-BSD 9.x you are using an earlier version of openSSL that does not have the vulnerability, so no action is necessary to protect yourself from this. If you are running PC-BSD version 10.x make sure to use the “system updater” to apply the security patch to openSSL. After applying the fix reboot your computer and you should be good to go.

Kris has finished a new PBI run-time that will fix a number of stability issues users may have been experiencing while using PBI’s. The fix has also subsequently helped speed up load times for some of the larger PBI’s that may have been hanging or taking a long time to load.

Update Center is moving foward, and has received some fine-tuning this week to help bring it into PC-BSD as the one-stop utility for managing updates. We’d like to add a special thanks to the author Yuri for primary design and layout for the update center. Ken will also be working to help smooth out GUI design elements and help with integrating it fully into PC-BSD.

Other Updates / Bug Fixes:

* Updated openssl packages for 10.0 PRODUCTION/EDGE
* Patched issue with KRDC using FreeRDP version in ports
* A new 9.2 server has been spun up and building PBIs for 9.2 again. (Server failed earlier this week)
* Started work on PBI runtime for Linux compat applications
* Another large chunk of work on Lumina
* Bugfixes for pc-mixer (showing the proper icons)
* Life-Preserver bugfixes
* Large update to the available 10.x PBIs. All updates are finished, a few new applications were also added.
* Bugfixes on a number of PBI’s (waiting on rebuilds to test/approve the new fixed apps)
* Hindi translation project now about 75% complete

FreeBSD Foundation Spring Fundraising Campaign!

We're kicking off our Spring Fundraising Campaign! Our goal this year is to raise $1,000,000 with a spending budget of $900,000.

As we embark on our 15th year of serving the FreeBSD Project and community, we are proud of how we've helped FreeBSD become the most innovative, realiable, and high-performance operating system. We are doing this by:
  • funding development projects,
  • having an internal technical staff available to work on small and large projects, fixing problems, and areas of system administration and release engineering,
  • providing legal support,
  • funding conferences and summits that allow face-to-face interaction and collaboration between FreeBSD contributors, users, and advocates,
  • and advocating for and educating people about FreeBSD by providing high-quality brochures, white papers, and the FreeBSD Journal.

We can't do this without you! You can help by making a donation today.

Help spread the word by posting on FaceBook, Twitter, your blogs, and asking your company to help. Did you know there are thousands of companies that wil match their employee's donations? Check with your company to see if you can automatically double your donation by having your company match your donation.

Thanks for your support!

FreeBSD Journal Issue #2 is Now Available!



The FreeBSD Journal Issue #2 is now available! You can get it on Google Play, iTunes, and Amazon. In this issue you will find captivating articles on pkg(8), Poudriere, PBI Format, plus great pieces on hwpmc(4) and Journaled Soft-updates. If you haven't already subscribed, now is the time!

The positive feedback from both the FreeBSD and outside communities has been incredible. In less than two months, we have signed up over 1,000 subscribers. This shows the hunger the FreeBSD community has had for a FreeBSD focused publication. We are also working on a dynamic version of the magazine that can be read in many web browsers, including those that run on FreeBSD.

The Journal is guided by a dedicated and enthusiastic editorial board made up of people from across the FreeBSD community. The editorial board is responsible for the acquisition and vetting of content for the magazine.

You can find out more information about the Journal by going to https://www.freebsdfoundation.org/journal. Or, subscribe now by going to the following links for the device you'd like to download to:

amazon-apps-store





Available_on_the_Mac_App_Store_Badge

Google Button







Your subscriptions and the advertising revenue the Journal receives will help offset the costs of publishing this magazine. So, consider signing up for a subscription today! 

We know you are going to like what you see in the Journal! Please help us spread the word by tweeting, blogging, and posting on your FaceBook page. You can also help by asking your company to put an ad in the Journal. For advertising information contact [email protected]

And, don't forget you can support the Journal and FreeBSD by making a donation today!

OpenSSL Security Update

Many users have asked us about the recent OpenSSL Heartbleed bug.  This only applies to users of PC-BSD 10.0, users of 9.x and earlier will not be effected.

A patch has gone out this morning to correct the issue, which includes the following FreeBSD security advisories:

http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc
http://www.freebsd.org/security/advisories/FreeBSD-SA-14:05.nfsserver.asc

By running the graphical “System Updater” you can apply the bug fixes, or via “freebsd-update” at the command-prompt. After applying this fix, please reboot and the systems version should now show 10.0-RELEASE–p9

PC-BSD Weekly Feature Digest 24

Another week bites the dust and we’ve got some fantastic new features heading your way. Just a quick update this week so let’s get right to it. The FreeBSD mailing list has put a call out to the community to know if you are interested in having some custom DirectX patches applied to wine. You can view the e-mail here if it interests you. If you’d like to respond directly to the e-mail list you can do so @ [email protected]

New Features:

* Tons of new PBI updates for 10.0
* Committed the new PBI runtime implementation for 10.x
* Fixed some edge cases with new runtime and particular apps
* Added support for running 32bit apps in new PBI runtime
* Patched RTLD and pushed out freebsd-update to prepare systems
* Added improved callback functionality for PBIs to run system commands
* Added umplayer as the new out-of-box default CD audio / DVD video player
* Merged latest FreeBSD ports and Gnome3 / Cinnamon ports
* Added options to set exec= and suid= options on ZFS datasets to installer
* Added “vagrant” development environment utility to PC-BSD base system
* Began builds of EDGE packages with all the above fixes

Bug Fixes:

* Fixed issue with missing English dictionary in KDE text-processing apps
* Fixed bug with Life-Preserver which was pruning snapshots too
aggressively with replication enabled
* Don’t provide localization option to FAT mounting routine for english locales
* Clean up the usage of ntfslabel to make sure that extra outputs don’t get included in the name for Win8 NTFS devices.

The Short List #8: Using #lldb with a core file on #FreeBSD

Debugging qemu this evening and it took me a minute or two to figure out the syntax for debugging a core file with lldb.

lldb mips-bsd-user/qemu-mips -c /mipsbuild/qemu-mips.core

Make sure you have permissions to access both the binary and the core, else you get a super unhelpful error of:

error: Unable to find process plug-in for core file ‘/mipsbuild/qemu-mips.core’

But, after that, you can start poking around:

Core file ‘/mipsbuild/qemu-mips.core’ (x86_64) was loaded.

Process 0 stopped

* thread #1: tid = 0, 0x00000000601816fa qemu-mips`_kill + 10, name = ‘qemu-mips’, stop reason = signal SIGILL

frame #0: 0x00000000601816fa qemu-mips`_kill + 10

qemu-mips`_kill + 10:

-> 0x601816fa: jb 0x60182f5c ; .cerror

0×60181700: ret

0×60181701: nop

0×60181702: nop

(lldb) bt

* thread #1: tid = 0, 0x00000000601816fa qemu-mips`_kill + 10, name = ‘qemu-mips’, stop reason = signal SIGILL

* frame #0: 0x00000000601816fa qemu-mips`_kill + 10

frame #1: 0x000000006003753b qemu-mips`force_sig(target_sig=<unavailable>) + 283 at signal.c:352

frame #2: 0x00000000600376dc qemu-mips`queue_signal(env=<unavailable>, sig=4, info=0x00007ffffffe8878) + 380 at signal.c:395

frame #3: 0×0000000060035566 qemu-mips`cpu_loop [inlined] target_cpu_loop(env=<unavailable>) + 1266 at target_arch_cpu.h:239

frame #4: 0×0000000060035074 qemu-mips`cpu_loop(env=<unavailable>) + 20 at main.c:201

frame #5: 0x00000000600362ae qemu-mips`main(argc=1623883776, argv=0x00007fffffffd898) + 2542 at main.c:588

frame #6: 0x000000006000030f qemu-mips`_start + 367

 

How I killed 13 500 000 pages in the Google search engine

Talk about a loaded title, en par with the quality (or lack there of) of the various click bait titles on the postings I see on Facebook and friends...

I was told by my hosting provider that my index to the FreeBSD mailinglists at http://www.mavetju.org/mail/ was using more bandwidth alone than all of their public websites together. Now this is not much of a record, since they have only low-bandwidth websites, but still...

Looking through the logs, I saw that the Googlebot and the Bingbot and some bot from China were happily fighting over CPU and bandwidth to index all of the files. Going at it on a speed of about 50 requests per seconds for 24 hours per day.

So what could I do? Checking in Google for site:mavetju.org/mail/, I saw that there were about 13 500 000 pages indexed. For what goal? Not much anymore, I have stopped following all except the FreeBSD Announcement mailinglists a couple of years ago. I still use it on my laptops, but that is all.

So... That mailinglist archive has been shut down. You can still find the cached version of it in Google by using the above search terms, but that will disappear too.

And that is the story on how I killed 13 500 000 pages in Google. I wonder how much many computers in their data center that frees up for other things. Probably none...

Ports 2014Q2 branched

I am pleased to announce that we have created the 2014Q2 branch of the ports
tree.

Because the first 2014Q1 branch was experimental you might not have heard of it
yet.

January 2014 saw the release of the first quarterly branch, intended at
providing a stable and high-quality ports tree. Those stable branches are a
snapshot of the head ports tree taken every 3 months and currently supported
for three months, during which they receive security fixes as well as build and
runtime fixes.

Packages are built on regular basis on that branch (weekly) and published as
usual via pkg.FreeBSD.org (/quarterly instead of the usual /latest).

They are signed the same way the /latest branch is.

While packages for 2014Q1 were only built for 10 (i386 and amd64) 2014Q2 will be
built for both FreeBSD 9 and 10 (i386 and amd64).

The first build of 2014Q2 will started this morning (wednesday at 1 am UTC) and should
hit your closest mirrors very soon.

On behalf of the port management team
Bapt

Sometimes you have to sit down and write #FreeBSD documentation

When working on new projects or hacks, sometimes you just have to stop, think and start writing down your processes and discoveries. While working on bootstrapping the DLink DIR-825C1, I realized that I had accumulated a lot of new (to me) knowledge from the FreeBSD Community (namely, Adrian Chadd and Warner Losh).

There is a less than clear way of constructing images for these embedded devices that has an analogue in the Linux community under the OpenWRT project. Many of the processes are the same, but enough are different that I thought it wise to write down some of the processes into the beginning of a hacker’s guide to doing stuff and/or things in this space.

The first document I came up with was based on the idea that we can netboot these little devices without touching the on-board flash device. This is what you should use to get the machine bootstrapped and figure out where all the calibration data for the wireless adapters exist. This is crucial to not destroying your device. The wireless calibration data (ART) is unique to each device, destroying it will mean you have to RMA this device.

The second document I’ve created is a description of how to construct the flash device hints entries in the kernel hints file for FreeBSD. I found the kernel hints file to be cumbersome in comparison to the linux kernel way of using device specific C files for unique characteristics.

Its interesting stuff if you have the hankering to dig a bit deeper into systems that aren’t PC class machines.