The process is pretty much straight forward, and Ryo ONODERA has verified the prerequired Windows versions and Linux packages, and has sent instructions on how to bootstrap pkgsrc on Windows 10. Now who's the first one to post a screenshot with output of pkgsrc/misc/cowsay running "cowsay hello pkgsrc"? :-)

[Tags: bash, linux, microsoft, windows]

• BSD-related radio-show "bsdtalk" has published an interview with NetBSD's Andrew Doran in its March 2009 issue. Besides covering Andrews work, the upcoming NetBSD 5.0 release is also discussed. Available as mp3 and ogg.

• Cross-compiling pkgsrc packages is a long-standing dream, and it's yet waiting for someone to do it. For the time being, Jared McNeill has come up with an HowTo on how to build 32bit packages on amd64 (and probably other 64bit systems).

• Jared McNeill's been hacking on more stuff recently, and one thing includes changes to the framebuffer console support on x86 (i.e. both i386 and amd64). In short, the recent changes are just a stop on the way to move the splashscreen code and esp. image data from the kernel to userland. I.e. that you can put something like

   menu=Boot NetBSD:vesa 1280x800;splash /logo.bmp;boot netbsd 

  into your /boot.conf in the future. But we'll see a separate announcement when that part is done. Let's stay tuned! :)

• Martti Kumparinen has tackled generating a UFS file system on a "large" (~5.5TB) disk. As the process is not straight forward, he has posted a howto that may help in the future. Any takers for adding comments and integrating this into The NetBSD Guide? :)

• Manpages are a major component of every Unix system. If you have ever tried to write such a manpage, you 'll have learned that they are in a funny text-based format similar to LaTeX and HTML, with its own processor - *roff. There are several *roff implementations, and the one used in NetBSD currently is the GNU implementation. To provide an alternative here is good for both removing GPL'd code from the NetBSD codebase, and also because groff is written in C++, which is slow to compile, and - well - requires a C++ compiler.

  A change for that situation may arise eventually, as Kristaps Dzonsons has been working on a groff replacement to format Unix manpages recently. See his posting and his homepage for further information.

• I've talked about Xen support for PCI passthrough recently, and Manuel Bouyer has finished his work to get full support for passing in access to specific PCI devices from the Xen Dom0 to DomUs. See his posting to port-xen for more details!

• Staying at Xen for a moment, David Brownlee has written instructions on Installing Windows XP in Xen under NetBSD. Just in case anyone needs to run a legacy system... :)

• The NetBSD operating system supports many different hardware and CPU platforms. For a specific platform, binaries are compiled with a specific compiler, and there is a set of binaries for each platform. This results in a rather big number of different sets of binaries - currently about 50. A different approach with historic precedence is to have one binary work on may hardware platforms, so-called "fat" binaries.

  Gregory McGarry has posted suggestions on how to modify NetBSD's toolchain to produce fat binaries. An interesting concept which would solve a number of problems (think: support, updates, pkgsrc!)

• Qt is a user-interface library found in widespread use in the Unix/Linux world. It's not exactly small, and its prerequirement of the X Window System doesn't it make a #1 choice for embedded systems at the first look. A Qt variant - Qt/Embedded - can be ran without X, though, and which thus avoids all the configuration and hardware support trouble of X in one go.

  On NetBSD, Qt/Embedded could talk to the wscons driver directly, and Valeriy 'uwe' Ushakov has posted about his work on patches to adopt Qt/Embedded to wscons. Who's first to post some screenshots?

(Unless someone shows me the only reason *I* run Windows works on OpenBSD -> Counter Strike :-)

[Tags: openbsd, windows]

``[...] it's just that it does not make any sense to need a technician to increase you're security on the installation of an operating system! That's crazy... but that's microsoft. Technicians should be spending their time making things work, such as hardware with the operating system, or network issues. Instead, we're all fighting a malware war and finally giving up and making our own primary home operating systems BSD(Unix-NetBSD,FreeBSD,OpenBSD) or Linux(SuSE,Slackware,Red Hat,Knoppix) while not telling our customers. Our customers don't know what it's like to use a system that doesn't get viruses on a user level, and we all have receding hairlines because of it.''

See the webpage!

[Tags: Security, windows]