Slashdot Mirror

I'm not aware of a FreeBSD foundation or a NetBSD foundation.

Okay, time to get up to speed then:

The FreeBSD Foundation

Donations to The NetBSD Foundation

RT.

But the same OS can run handhelds, desktop and servers. NetBSD or Linux fits all.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NetBSD Security Advisory 2014-001

Topic: Stack buffer overflow in libXfont

Version: NetBSD-current: source prior to Tue 7th, 2014
NetBSD 6.1: affected
NetBSD 6.0 - 6.0.2: affected
NetBSD 5.1 - 5.1.2: affected
NetBSD 5.2: affected

Severity: privilege escalation

Fixed: NetBSD-current: Tue 7th, 2014
NetBSD-6-0 branch: Tue 7th, 2014
NetBSD-6-1 branch: Tue 7th, 2014
NetBSD-6 branch: Tue 7th, 2014
NetBSD-5-2 branch: Tue 7th, 2014
NetBSD-5-1 branch: Tue 7th, 2014
NetBSD-5 branch: Tue 7th, 2014

Teeny versions released later than the fix date will contain the fix.

Please note that NetBSD releases prior to 5.1 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract

A stack buffer overflow in parsing of BDF font files in libXfont was
found that can easily be used to crash X programs using libXfont,
and likely could be exploited to run code with the privileges of
the X program (most nostably, the X server, commonly running as root).

This vulnerability has been assigned CVE-2013-6462

Technical Details

- From the X.org advisory:

Scanning of the libXfont sources with the cppcheck static analyzer
included a report of:

[lib/libXfont/src/bitmap/bdfread.c:341]: (warning)
scanf without field width limits can crash with huge input data.

Evaluation of this report by X.Org developers concluded that a BDF font
file containing a longer than expected string could overflow the buffer
on the stack. Testing in X servers built with Stack Protector resulted
in an immediate crash when reading a user-provided specially crafted font.

As libXfont is used to read user-specified font files in all X servers
distributed by X.Org, including the Xorg server which is often run with
root privileges or as setuid-root in order to access hardware, this bug
may lead to an unprivileged user acquiring root privileges in some systems.

This bug appears to have been introduced in the initial RCS version 1.1
checked in on 1991/05/10, and is thus believed to be present in every X11
release starting with X11R5 up to the current libXfont 1.4.6.
(Manual inspection shows it is present in the sources from the X11R5
tarballs, but not in those from the X11R4 tarballs.)

Solutions and Workarounds

Workaround: restrict access to the X server.

Solutions: a fix is included in the following versions:

xorg: xsrc/external/mit/libXfont/dist/src/bitmap/bdfread.c
HEAD 1.3
netbsd-6 1.1.1.2.2.1
netbsd-6-1 1.1.1.2.6.1
netbsd-6-0 1.1.1.2.4.1
netbsd-5 1.1.1.1.2.2
netbsd-5-2 1.1.1.1.2.1.4.1
netbsd-5-1 1.1.1.1.2.1.2.1

xfree: xsrc/xfree/xc/lib/font/bitmap/bdfread.c
HEAD 1.4
netbsd-6 1.2.8.1
netbsd-6-1 1.2.14.1
netbsd-6-0 1.2.10.1
netbsd-5 1.2.2.1
netbsd-5-2 1.2.12.1
netbsd-5-1 1.2.6.1

To obtain fixed binaries, fetch the appropriate xbase.tgz from a daily
build later than the fix dates, i.e.
http://nyftp.netbsd.org/pub/NetBSD-daily////binary/sets/xbase.tgz
with a date 20

I understand it is the same beast as the COMPAT_NETBSD32 option that has been available in NetBSD for 15 years now. It works amazingly well: one can throw a 64 bit kernel on a 32 bit userland and it just works, except for a few binaries that rely on ioctl(2) on some special device to cooperate with the kernel.

NetBSD even had a COMPAT_LINUX32 option for 7 years, which enables running a 32 bit Linux binary on a 64 bit NetBSD kernel. Of course the Linux ABI is a fast moving target, and one often misses the latest system call that a given Linux binary requires, but it is funny to see that Linux feature was supported on non Linux OS first.

I understand it is the same beast as the COMPAT_NETBSD32 option that has been available in NetBSD for 15 years now. It works amazingly well: one can throw a 64 bit kernel on a 32 bit userland and it just works, except for a few binaries that rely on ioctl(2) on some special device to cooperate with the kernel.

NetBSD even had a COMPAT_LINUX32 option for 7 years, which enables running a 32 bit Linux binary on a 64 bit NetBSD kernel. Of course the Linux ABI is a fast moving target, and one often misses the latest system call that a given Linux binary requires, but it is funny to see that Linux feature was supported on non Linux OS first.

You mean like practically everyone?

Not quite like everyone, stupid.

I do not trust commercial routers, not because of NSA-weakened crypto, but because of plain old security holes like unclosed developper backdoors or web administrative interface full of CRSF vulnerabilities

I use a Soerkis box with a PCI DSL board, and I run NetBSD on it

things tend to go slow. Real slow. If you want things now, now, now, pay the man/men. It is free, as in someone-else-will-do-it, so you get what you, that's right, didn't pay for.

Fortunately, eventually people found this hobby project worth paying for, although I think it proved its worth before the big money started pouring in.

There are, of course, some other hobby projects that also manage to support a little more hardware than the Hurd does without huge amounts of money poured into them.

Debian is the only project on Earth that maintain so much architectures from the same code base and build system.

Don't forget NetBSD.
I don't know whether NetBSD has more archs than Debian (and refutes your statement), nevertheless still worth mentioning.
(yeah yeah, Netcraft etc.)

Well, I was talking about BSDs in general. But on the other hand, I today saw the official Products based on NetBSD list to mention Darwin. Maybe Darwin pulls from various BSDs?

Honest question, who uses NetBSD?

Well I do, and moreover I personally have written ~30 thousand lines of code for NetBSD which has been used in other OS projects (the other BSDs, and OpenSolaris at least - see Bluetooth code) in varying amounts, and I am certainly not the only one to have had code re-used. The NetBSD libc is being used for Android now, I believe.

Also, many companies do use it, though they don't always advertise that fact.

Seriously, after 25 years in the business I've never seen or heard about anyone using NetBSD in production ever.

The licence is liberal, and companies are not obligated to mention their usage.

Last I checked, Itanium was not supported - it is supported on FreeBSD. Does NetBSD support it now, or have they abandoned plans of supporting it?

There is a work in progress port, but no formal release. I do not know how usable it is

> if they could port ZFS from FreeBSD they'd have a winner on their hands

What are you talking about?
  * http://wiki.netbsd.org/users/haad/porting_zfs/
  * http://netbsd-soc.sourceforge.net/projects/zfs-port/

Considering FreeNAS is based on TinyBSD, and ZFS is already available for Linux,
      http://zfsonlinux.org/
Not sure what issues you are having with NetBSD & ZFS.

ZFS for Linux was dead easy to get up and running ...
  1. Download spl
  2. Download zfs
  3. ./configure ; make
  4. zpool import /dev/...

Just pulled in 4x 1.5 TB drives in a 2.3 TB Raid-Z2 pool with ZFSonLinux that had already been setup in FreeNAS.

Please subscribe to the port-sgimips mailing list and tell that you are ready to lend the machine to someone that would pick it up or pay shipping. You will get an answer or not, but at least you will have tried

Here is a good starting point.

There are a lot of kernels built for ARM platforms, but you will probably want to tweak and rebuild your own. This can be cross-built from your favorite Linux box, it is as simple as

• downloading the source tarballs from ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1/source/sets/
• unpack
• run ./build.sh -U -m evbarm tools to build the toolchain (-U for unprivilegied if you are not root, -m for target platform)
• copy a kernel config file from sys/arch/evbarm/conf, and change whatever you need
• run ./build.sh -u -U -m evbarm kernel=YOUR_KERNEL_FILE to cross-build your custom kernel (-u for update, it does not rebuild what you already have, which will be useful when you will tweak things)

Kernel are ELF, so if you already have an ELF bootloader, it should be straightforward

Here is a good starting point.

There are a lot of kernels built for ARM platforms, but you will probably want to tweak and rebuild your own. This can be cross-built from your favorite Linux box, it is as simple as

• downloading the source tarballs from ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1/source/sets/
• unpack
• run ./build.sh -U -m evbarm tools to build the toolchain (-U for unprivilegied if you are not root, -m for target platform)
• copy a kernel config file from sys/arch/evbarm/conf, and change whatever you need
• run ./build.sh -u -U -m evbarm kernel=YOUR_KERNEL_FILE to cross-build your custom kernel (-u for update, it does not rebuild what you already have, which will be useful when you will tweak things)

Kernel are ELF, so if you already have an ELF bootloader, it should be straightforward

Here is a good starting point.

There are a lot of kernels built for ARM platforms, but you will probably want to tweak and rebuild your own. This can be cross-built from your favorite Linux box, it is as simple as

• downloading the source tarballs from ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1/source/sets/
• unpack
• run ./build.sh -U -m evbarm tools to build the toolchain (-U for unprivilegied if you are not root, -m for target platform)
• copy a kernel config file from sys/arch/evbarm/conf, and change whatever you need
• run ./build.sh -u -U -m evbarm kernel=YOUR_KERNEL_FILE to cross-build your custom kernel (-u for update, it does not rebuild what you already have, which will be useful when you will tweak things)

Kernel are ELF, so if you already have an ELF bootloader, it should be straightforward

Not sure about shops, but you can buy discs from several online vendors if you don't have the bandwidth to download: http://www.netbsd.org/sites/cdroms.html

Furthermore, I don't really see the difference between delivery via streaming packets vs delivery via post of a physical item from a logical viewpoint.

The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all...Everything there is compiled from source based on some pretty beefy makefiles.

Binary packages are also available for many ports, this is not a new thing for the ports collection or pkgsrc which is what DragonFly BSD uses. In addition to the various formats software may be obtained from the ports collection there are various branches one may follow: unstable, stable, and release. With regards to staying up to date, FreeBSD uses a rolling release for their ports so staying on top of things can become involved if one is using a release machine in a desktop role, ya know with lots of client side libraries for Gnome/KDE/etc. If you're updating multiple machines a build server is one way to go, here is an interesting discussion addressing updating FreeBSD.

While I like FreeBSD keeping it up to date requires more effort, than say Debian, this will become apparent when there are multiple machines to tend to.

This is insanely cool...

Seriously.

an IDE is only beneficial for large projects with complicated build or deployment procedures with more than a couple developers.

Well, there must be other constraints to the projects you experienced. NetBSD has a source repository of more than 6 millions LoC, more than 200 developers scattered worldwide, it targets 16 CPU types. And nobody use an IDE when dealing with it.

Well, emacs is an IDE, and I guarantee lots of NetBSD developers use some flavor of it, so you're quite laughably wrong. Perhaps you're conflating "IDE" and "visual interface builder", like the moron in TFA? If so, please stop, you're getting your stupidity all over our internet.

an IDE is only beneficial for large projects with complicated build or deployment procedures with more than a couple developers.

Well, there must be other constraints to the projects you experienced. NetBSD has a source repository of more than 6 millions LoC, more than 200 developers scattered worldwide, it targets 16 CPU types. And nobody use an IDE when dealing with it.

You can use MacOS X and install the (pkgsrc) which is very portable. This gives you a ton of the free software library you are talking about.

Porting to a new ARM SoC

--libman

I work at a multinational corporation with 30,000 employees worldwide.

Accessing netbsd.org from our corporate network gives permission denied

The explaination for the site access ban is netbsd=hobby site by the ranking of the net filtering service my company uses

Your net filtering service is broken. I suggest you complain to them.

Do you really need a net filtering service anyway?

The summary obviously meant to say "sixty thousand", but it used a non-English convention amidst English text (comma vs period for decimal mark vs thousands separator). The donation page itself says "60,000", with a comma.

The current national conventions are as follows:

Countries where a dot "." is used to mark the radix point [(called "decimal point" when dealing with base-10)] include: Australia, Botswana, British West Indies, Brunei, Canada (English-speaking), Dominican Republic, Guatemala, Hong Kong, India, Ireland, Israel, Japan, Kenya, Korea (both North and South), Lebanon, Luxembourg (uses both marks officially), Macau (in Chinese and English text), Malaysia, Malta, Mexico, Mongolia, Nepal, New Zealand, Nicaragua, Nigeria, Pakistan, Panama, People's Republic of China, Philippines, Singapore, Sri Lanka, Switzerland, Taiwan, Tanzania, Thailand, Uganda, United Kingdom, United States (including insular areas), Zimbabwe.

Countries where a comma "," is used to mark the radix point include: Albania, Andorra, Argentina, Armenia, Austria, Azerbaijan, Belarus, Belgium, Bolivia, Bosnia and Herzegovina, Brazil, Bulgaria, Cameroon, Canada (French-speaking), Chile, Colombia, Costa Rica, Croatia (comma used officially, but both forms are in use elsewhere), Cuba, Cyprus, Czech Republic, Denmark, Dominican Republic, Ecuador, Estonia, Faroes, Finland, France, Germany, Georgia, Greece, Greenland, Honduras, Hungary, Iceland, Indonesia, Italy, Kazakhstan, Kirgistan, Latvia, Lebanon, Lithuania, Luxembourg (uses both marks officially), Macau (in Portuguese text), Macedonia, Moldova, Mongolia, Morocco, Netherlands, Norway, Paraguay, Peru, Poland, Portugal, Romania, Russia, Serbia, Slovakia, Slovenia, South Africa (officially), Spain, Sweden, Tunisia, Turkey, Ukraine, Uruguay, Uzbekistan, Venezuela, Vietnam.

Although I was born in Russia, I think the English / USA'ian / majority-Asian way (period for decimal point) is better than the continental European way, and the whole world should get on the same page. Think of it as a victory prize for USA winning the Cold War... or a consolation prize for Englishmen (and someday USA'ians too) abandoning their "imperial system" for the much-superior metric system. ;-)

The world already uses periods as logical separators in dotted decimal notation of IP addresses, DNS (though sadly little-endian), member separators, etc.

As for the decorative thousands separation - any character except a period would do, with comma being the tradition, but I think the underscore is best. Commas only cause grammatical confusion. Sixty thousand is 60_000. Seems perfectly natural to someone with experience in a programming language like perl, ruby, or nimrod.

--libman

I work at a multinational corporation with 30,000 employees worldwide.
Accessing netbsd.org from our corporate network gives permission denied
The explaination for the site access ban is netbsd=hobby site by the ranking of the net filtering service my company uses

I can feel it in my bones, this is the year of FreeBSD! I"ve always had a soft-spot in my heart for BSD of any flavor. Fond memories of running NetBSD on my Mac LCIII are coming back!

Ever heard of NetBSD? That and A/UX are the only *nixen I've ever run on my 68k Macs.

FWIW, latest NetBSD 6.0 still supports mac68k fine, and has never ceased to do.

Alright, here's my shtick... It's a great race between two open source software ecosystems: copyLEFT and copyFREE.

The copyFREE side is a more amicable pacifist bunch, with more freedoms and more choices, and it has been gaining ground in the last decade in all software categories but one - the kernels. The copyLEFT side was founded by a bunch of militant hippies trying to destroy capitalism, and it had several years' head start, so its viral licenses were grandfathered into some of the most important pieces of open source software. The OS projects within each team like to share code, and the copyLEFT team can also mooch copyFREE code as well, but not the other way around...

This race is contested on many fronts, and one obscure comparison (that I just came up with) is: while running the race forward, to still maintain support for the 80386 platform. Only UNIX systems (sorry, sorry, sorry) that can run on a 80386 PC (sorry, sorry) with actively maintained current versions (sorry) are to be included. Let's see how the two teams compare:

THE COPYLEFT TEAM:

(1) Linux - now i486, as mentioned in this article.

THE COPYFREE TEAM:

(1) FreeBSD - i486 since 2005.

(2) OpenBSD - i486 since 2007.

(3) NetBSD - i486, "80386 support removed" in 2007.

(4) MINIX 3 - i586, 32mb RAM, 635mb HD.

So it looks like the copyLEFT camp had this little "current UNIX on 80386" advantage, and now lost it...

--libman

A well written history of BSD is available as part of "Open Sources: Voices from the Open Source Revolution":

http://oreilly.com/openbook/opensources/book/kirkmck.html

Basically NetBSD was the transition from a "one company" (cathedral) project to some internet centered adventure not unlike Linux (bazaar), hence the "Net" prefix.
At the time the only other variant was FreeBSD which targeted i386 and was more "user friendly", from that it evolved to be a run-anywhere highly customisable OS used in computing experiments as well as toasters.

STABLE is just the branch release. It means if you track the STABLE tree, you'll only get bugfixes. If you track CURRENT, you get stuff that'll go into the next version of NetBSD, but stuff will change on you (requiring you to update scripts and such). See the release map for a better explaination.

It has nothing to do with the stability of the OS itself. I can't comment on that, since I haven't used it much, but from what I hear it's pretty good.

If you need a hand, ask on the netbsd-users mailing list (http://www.netbsd.org/cgi-bin/subscribe_list.pl?list=netbsd-users). Especially with the new release just being out there should be plenty of people willing to help with whatever issue you have.

(Since you've been running betas for a while you probably know about the mailing lists, so this is more of a PSA for anyone else)

Check it out, from the horses mouth.

You are looking at the wrong horse.

The BSD portion of the OS X kernel is derived primarily from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features.

Check it out, from the horses mouth.

NetBSD is used by Apple for a large portion of the user-space commands and tools in their Darwin project, and Darwin is the UNIX-based core used by Mac OS X. NetBSD source tends to pay attention to issues of portability and correctness, and is virtually all BSD licenced, which avoids commercial problems with the GNU General Public Licence. At least one of the Apple developers has access to the NetBSD source tree and has fed back some useful changes

There are precedents. For instance NetBSD has dedicated releases to its deceased developers a few times.

From NetBSD-5.1 releases notes

NetBSD 5.1 is dedicated to the memory of Martti Kuparinen, who was the victim of a traffic accident in June 2010. Martti's technical contributions are too many to list here in full. He created and maintained numerous packages in pkgsrc, updated two packet filter solutions distributed with NetBSD and improved several hardware drivers. Beyond that, he was always helpful and friendly. His example encouraged users to contribute to the project and share their work with the community. Some of these users later became NetBSD developers themselves thanks to Martti's efforts.

There are precedents. For instance NetBSD has dedicated releases to its deceased developers a few times.

From NetBSD-5.1 releases notes

NetBSD 5.1 is dedicated to the memory of Martti Kuparinen, who was the victim of a traffic accident in June 2010. Martti's technical contributions are too many to list here in full. He created and maintained numerous packages in pkgsrc, updated two packet filter solutions distributed with NetBSD and improved several hardware drivers. Beyond that, he was always helpful and friendly. His example encouraged users to contribute to the project and share their work with the community. Some of these users later became NetBSD developers themselves thanks to Martti's efforts.

What do you think this is, the reenactment of Iwo Jima?

Don't you mean the reenactment of NetBSD's founding? :)

No, this isn't 'Interresting', rather mod as 'Blathering'.

Well, there is no point denying that Theo isn't the most malleable person. But, as has been said here on /. before: while he comes through as whining most of the time, he's also correct most of the time. Many people tries to interpret his statements from the common commercial viewpoint (like in, how to develop a successful software product and make PROFIT, or at least achieve world domination), but rather his goal is quite simple: develop a free, fast and secure Unix OS. That's all. No grand plans of IPOs or commercial success. Theo is quite happy getting by on selling those CDs, living in his little house, and occasionally traveling around the world climbing mountains and hacking Unix. You gotta read goal.html and observe him and the project for a few years to really understand that.

Theo, ranting, is why he got kicked off the NetBSD project.

While this is true, the history also proved him correct on many things (Charles Hannum was on the core team that did the kicking).

Theo, ranting, is why OpenBSD's drivers for Broadcom chipsets stink. (Look up how the original author tried to resolve the licensing problems of sticking his GPL drivers in an OpenBSD kernel and was ignored, then screamed at by Theo for making the issue public.)

That whole mess sucked. The OpenBSD developer that made the port (which was supposed to be a re-implemenation) f*cked up big time and imported GPL-files into the tree. The only thing positive in the whole affair is perhaps Theo's unconditional backing of his developer.

Theo, ranting, is why OpenBSD doesn't properly handle booting from software RAID.

It does (I believe the kernel must be on a non-RAID slice/disk, but that's no different to most other implementations).

Theo, ranting, is why the OpenBSD installer works like the UNIX crap I learned to loath back in 1985 and can't store the state of what you've already selected or go back, you just have to start over from scratch.

Actually, the very minimalistic installer is often hailed as one of the best and fastest in the industry. I don't think that there are that many installers where you can do the install by repeatedly pressing enter (and writing the hostname once) in that short time. And well, it's doesn't remember the state, but then again, you can restart it (a shell script) and start over without rebooting - that can't be said about many others.

Theo, ranting, is why OpenSSH has no built-in support for chroot cages.

This seems to disprove that. Unless you have different definition of 'chroot cage'.

Theo, ranting, is why OpenBSD has no virtualization server capability.

In many aspects virtualization contradicts the goal of security. Also, most VM solutions are proprietary, thus does not run on OpenBSD.

Theo, ranting, is why OpenSSH still stores both host keys and by default, user private keys in clear text with no expiration, and has no plans to fix this.

Yes, in clear text. Do you propose they should be encrypted? And where should the crypto key be placed? Perhaps... on disk? Hashed? If you are paranoid - use whole disk encryption. Because physical security is the key issue here as I see it. The keyfile is supposed to be user-readable only...

What is a reasonable default expiration time? No, there is no plan because the feature doesn't improve anything.

Theo, ranting, is why the "compatiblity chart" is a list of chipsets that don't match the actual chipsets published by the manufacturer, and usually are from chipsets at least 4 years old.

Uhmm, wha

http://www.netbsd.org/ports/pmax/ :)

As far as other open source solutions BSD kernels generally do not have such good support for hard real time applications.

Well, CERN makes extensive use of Force10 network appliances, and they are all NetBSD-based.

Without a reliable, high speed/low latency network, I bet there wouldn't be anything to compute or analyse.

What's the point of TFA anyway? Nowadays, everything is used as an excuse to put Linux to the front, while its role is not more important than the other technological pieces used (compilers, C++, userland apps and infrastructure, ...). *sigh*

It's been a long time since I had time to browse any of the code repositories out there, but last time I looked, the BSD people (Free, Net, Open, ...) all had their own BSD-licensed unixy command-line tools.

Speaking as a NetBSD user (and developer) we do have something that looks similar to busybox under /rescue, a statically linked binary which acts differently depending on how you call it. See the "list" file at cvsweb for common utilities included and the build seems easy enough to configure your own utilities as required. rescue(8)

FreeBSD at least has a simlar tool, not sure about OpenBSD..

Considering that the BSD network stack is pretty much THE reference, whatever you code has to stay compatible with it.

"Compatible" at the API level or "compatible" at the network level? ("Compatible" at the API level is irrelevant, as it's not going to happen; PE is not a.out or ELF.)

So you're going to need to copy ALL the BSD constants,

No, you're not. Nobody's going to give a damn about AF_DATAKIT/PF_DATAKIT, for example. You're only going to have to copy the names of the ones that matter, namely AF_INET and AF_INET6.

and ALL the BSD typedefs,

Again, you'll only have to copy the ones used in socket calls.

So, tell us, how are you going to write something that complies with the standard without those constants, typedefs, and api? Magic? Time machine? Million Monkeys?

So, tell us, how are you going to write something that complies with various UN*X standards without using the code of an existing implementation?

As indicated, you don't have to copy the exact definitions of the constants; even the existing *BSDs don't all have the same numerical value for AF_INET6 (28 in FreeBSD and DragonFly BSD and 24 in NetBSD and OpenBSD; it's 30 in Mac OS X and presumably iOS).

In any case, even if they copied and pasted some typedef calls, that, in and of itself, doesn't mean that it's derived from the BSD code in any interesting way.

As for the "api", an API isn't code, it's documentation. There are a number of cases where multiple implementations of an API exist without sharing code. (You may have heard of some software called "the Linux kernel" and "the GNU C library" - and those APIs include more than the socket calls, so arguing that the Linux networking code may have been in part based on the BSD socket code is insufficient to dismiss those examples.)

So if I invent a robot with my own ai code but it uses GPL apis

Presumably you mean "GPLed libraries"; I don't know of any interfaces that are GPLed in any sense, e.g. somebody could reimplement a GPLed library, duplicating all its APIs, and release it under the BSD license without violating the GPL. I guess you could see legal arguments about, say, header files for the library, but those arguments may already have come up and been resolved.

What if I onvested 5,000,000 making the code? Whoops competitors now use my code and undercut me because they didnt have to invest the 5,000,000. I go out of business.

Then whoops maybe you should have invested a little more to implement that functionality yourself, or paying somebody else to implement it, or even just to try to find a free-as-in-beer-at-least implementation with a non-GPL license, rather than using the work of somebody else who doesn't want you to use it in a fashion where you don't have to make source code available under the terms of the GPL.

Google gets a free ride because they are not redistributing. For everyone else who makes smart appliances you are screwed.

If a smart appliance maker is going to invest a lot of money in the software, they're not "screwed", they're just required to invest a little more money making or buying or finding non-GPL software. If their "secret sauce" is the hardware, and giving away the source to the software doesn't make it significantly easier for others to make that hardware - or if they have a patent on the hardware - they may not be "screwed" at all.

Small business owners are too. You cant sell your company as that too counts as redistribution.

A small business using GPLed software most definitely can sell their company. It's not as if using GPLed software GPLs your entire company, including the office desks and the software you bought to run on your computers and your customer lists and the software you've developed without incorporating GPLed code into it.

Just google router xompanies? Gnu went after them

...because they used GPLed code without complying with the requirements for doing so. A company that makes Wi-Fi access points managed to find an alternative to GPLed software for their access points.

Interesting!

I moved over to FreeBSD .....It's a good operating system, but package management is a pain. If only if someone could port APT over to FreeBSD... sigh.

Totally.

apt-get install sumpackage
is so much more comprehensible and understandable, and totally not a pain, whereas,

pkg_add sumpackage
is out of control, a total pain, and whomever came up with such a nonsensical and grotesque idea is a really disturbed individual.

I keep telling people... read the book first. If you watch the movie first, you'll forever incorrectly believe the movie was better than the book. The movie is apt, but the book is the true source. And even the sequel is better than the movie.

This comment comes from someone who used to volunteer at CSOS (Computer Science Outreach Services) at Oregon State University back from 1990 to 1994. CSOS is what eventually became PEAK, now a commercial Internet provider in Corvallis. I used to work directly with folks like Jason Thorpe (NetBSD), Jason Downs (NetBSD/OpenBSD), Jeremy McDermond, John Sechrest (who oversaw everything... sort of), and a couple other equally important folks but whose surnames slip my mind.

CSOS was an interesting project intended to provide access to networked computers (all UNIX of course) and Internet access to the general community of Corvallis. It consisted consisted mainly of NetBSD boxes of all flavours, particularly on HP300 boxes (a couple did run HP/UX), some Wyse/DEC-like terminals, a very large dial-in modem pool (eventually migrated to a couple Annex devices). I believe there was a machine or two which ran 386BSD as well. There were also some other volunteers who did things like Radio Free RAT, which to my knowledge was the first "Internet radio station" streamed live via MBONE and had some electronica bands like Violet Arcana come to the datacenter/offices for an interview and a brief session. At one point they even had a public IRC server (which was connected to what it now called EFNet; irc.csos.orst.edu). I would provide links to all of these things, but there really isn't much on the web about CSOS; about all you can find are the old machines: jacobs, kira, nyssa, king, and poe.csos.orst.edu.

I was never sure where the funding came from, but I imagine the university was the main source, in addition to members of the community (individuals and companies) giving donations.

My points are that 1) CSOS played a small but important role in the overall development of NetBSD and general Internet and community services (again keep in mind the decade in which this was being done!), and 2) Oregon State has a history of doing things like this. I really did expect to see mention of CSOS in Lance's slides, but I digress.

For OSX its the opposite. For every small task that i want to accomplish, i seem to need to pony up. Every small time programmer tries to make a buck with his little program.

You might want to look into using the NetBSD Package system, called pkgsrc, on on OSX. The NetBSD community is used to porting things around, and the NetBSD package system itself has been ported to run on a lot of different OSes. It's a very source-based packaging system with a robust dependency chain.

NetBSD mirrors use AFS, CVSup, SUP, rsync, FTP, HTTP...

http://www.netbsd.org/mirrors/

Where does Linux fail where BSD succeeds?

For some people it's the licensing (BSD vs GPL). For others it is the coherence of the system (how many places hide an IP address in Red Hat?). For others, it is a question of style (BSD vs AT&T type Unix). For some, its functionality (I always liked the way the BSD _______ command worked). From some, it's the simple Joy of BSD, or the McKusick - take your pick. For some, it could be the approach taken to a particular problem taken by one of the BSDs, such as the continuous OpenBSD code audits. For some it might be a particular platform maintained as part of the main distribution. For some, it may be the continuing BSD innovations. For some it might be the counter-culture aspect BSD in the Linux world. Plenty more reasons that people could have, including: Linux - 5 letters, BSD - 3 letters. Do the math.

You could say that the only truly popular Unix desktop is Apple's Macintosh running OS X.
Mac OS X: What is BSD?

What's The Greatest Software Ever Written?

OpenBSD FreeBSD NetBSD PC BSD

FreeBSD Mall BSD Magazine

To each his own.