Slashdot Mirror

Or just simply NetBSD [....] IMHO, build.sh is just the way to go.

Finally! I think it's amazing that we're discussing embedded systems, Linux, BSD... yet ignoring NetBSD, which is the flavor that most caters to embedded systems!

build.sh is a great example of one of those unheralded "little things". If I'm on my Mac OS X laptop and want to build a NetBSD ARM kernel or distribution for my embedded single board computer, I don't have to go fussing around with finding and downloading cross-compiling toolchains and figuring out how to make them go, etc. I just add a single flag to the normal build script that's part of the OS source code:

./build.sh -m evbarm kernel=MYKERNELCONFIG

And that's it. It will build the toolchain and then the kernel. It's so simple, it's brilliant.

NetBSD tends to get ignored a lot, but IMHO undeservedly. It is on a par with Linux 2.6 and FreeBSD in terms of speed, is flexible and feature-rich, has a nice ports/packages system and doesn't suffer from a lot of "superfluous redesign" (Linux, I'm looking at you). It's a really nice clean system and it's easy to get the basics done. It deserves more attention than it gets.

That said, the original question was "Linux 2.4 or 2.6?" If you can strip 2.6 down to fit within the confines of your embedded system, by all means go for it. This is especially true for new small x86 devices, where 2.6 is typically the baselined kernel anyway. On other architectures, it varies. On many ARM flavors, 2.6 is getting shaken out and 2.4 is still often the default. I suspect that the transition will complete this year.

Or just simply NetBSD [....] IMHO, build.sh is just the way to go.

Finally! I think it's amazing that we're discussing embedded systems, Linux, BSD... yet ignoring NetBSD, which is the flavor that most caters to embedded systems!

build.sh is a great example of one of those unheralded "little things". If I'm on my Mac OS X laptop and want to build a NetBSD ARM kernel or distribution for my embedded single board computer, I don't have to go fussing around with finding and downloading cross-compiling toolchains and figuring out how to make them go, etc. I just add a single flag to the normal build script that's part of the OS source code:

./build.sh -m evbarm kernel=MYKERNELCONFIG

And that's it. It will build the toolchain and then the kernel. It's so simple, it's brilliant.

NetBSD tends to get ignored a lot, but IMHO undeservedly. It is on a par with Linux 2.6 and FreeBSD in terms of speed, is flexible and feature-rich, has a nice ports/packages system and doesn't suffer from a lot of "superfluous redesign" (Linux, I'm looking at you). It's a really nice clean system and it's easy to get the basics done. It deserves more attention than it gets.

That said, the original question was "Linux 2.4 or 2.6?" If you can strip 2.6 down to fit within the confines of your embedded system, by all means go for it. This is especially true for new small x86 devices, where 2.6 is typically the baselined kernel anyway. On other architectures, it varies. On many ARM flavors, 2.6 is getting shaken out and 2.4 is still often the default. I suspect that the transition will complete this year.

"Of course it runs NetBSD"

http://support.apple.com/kb/HT1222
https://help.ubuntu.com/community/AutomaticSecurityUpdates
http://www.debian.org/security/
http://www.freebsd.org/security/advisories.html
http://www.netbsd.org/support/security/

Don't be a pretentious prick. Every OS out there has to have security updates.

I honestly don't think NetBSD runs on as many devices as Linux does.

it runs on 59 platforms currently (including a toaster). and I can compile the code or get binaries right now for any of them, no crazy patching or anything. and that's for the whole OS (mostly) not just the kernel.

``When I tell my PC to shut down, all it really needs to do is make sure that no files are currently being written to disk, force a dismount of all drives, and then cut the power.''

That's pretty much how it works on OpenBSD and NetBSD (at least when I used them). They do run /etc/rc.shutdown, but that script generally doesn't do very much. So you are right: much of what other systems do on shutdown is unnecessary and a waste of time.

If you really want to shut down your system quickly, I guess you could use halt -f or shutdown -n, but I'm not sure that would be a good idea, because it really won't run any shutdown scripts at all, as far as I understand.

Viruses - THis is not a OS problem, its a user problem.

I used to think that to, but really, it's a Windows problem. Viruses could hypothetically infect other systems, just like I could hypothetically spontaneously quantum-tunnel my way through the wall - there's no technical reason why it couldn't happen but it never has. On modern OSes, only Windows has a malware problem. Don't start with that BS about market share either because there's enormous infamy to be gained by being the first virus author to hit Linux or OS X.

Drivers - Add all the drivers to the kernel? So the manufacturers of devices have to wait till the kernel maintainer decides on his own sweet time when to integrate patches. AND THEN wait till picks them up downstream. Nice solution. Doesnt scale, buddy.

Linux has much better hardware support than Windows and this has been true for several years. Let's reverse your argument: I bought a Microsoft Wi-Fi card for an old laptop, but unsurprisingly it didn't come with drivers for OpenBSD. The card was based on a common chipset with a well-supported driver, but no one had told the driver that it should work for that card. So I told it to, submitted the patch upstream, and now everyone using *BSD (or Linux, which I think uses the same driver) now has working support for it out of the box. I'm certainly not a driver expert, but I was able to do the little tweak that fixed the problem once and for all.

Contrast with Windows, where I've had a capable driver installed on a machine but no way to get it to speak to a piece of hardware without invoking a disassembler. You're sitting at the whim of the manufacturers, and until they decide to let you use your hardware, you're stuck. I won't even go into the joy of trying to use older printers on Vista.

NetBSD has a SYN cache instead of using SYN cookies to deal with SYN flood attacks. The difference may be enough to prevent the attack on the SYN cookie mechanism from working. The differences are discussed in this article, which I'll admit up front that I have not read.

NetBSD has a SYN cache instead of using SYN cookies to deal with SYN flood attacks. The difference may be enough to prevent the attack on the SYN cookie mechanism from working. The differences are discussed in this article, which I'll admit up front that I have not read.

And that we can thank our Dear RMS for.

Where do you get this "we" crap white boy?

forgot one

http://www.netbsd.org/

Clear, irrefutable proof that BSD is dying.

I know, it seems like only nine years ago it was a four-clause license, now all three major BSDs have gone to two-clause licenses. Within a decade it'll be a zero-clause license and BSD will finally die...

*unzips*, Pees the following in the snow:
NetBSD even runs on toasters: http://www.netbsd.org/gallery/in-Action/

*zips up*

Any questions?

Open Solaris - http://opensolaris.org/

FreeBSD - http://freebsd.org/ (excellent bridged IPless firewall capability)

NetBSD - http://netbsd.org/

Really good interview found here.
http://www.netbsd.org/gallery/schueth-interview.html

Hey now, that Amiga if not being used as a Video Toaster, makes a pretty damn good BSD machine. :-)

For the HPCs with MIPS processor, there's the NetBSD HPCMIPS port.

For the HPCs with MIPS processor, there's the NetBSD HPCMIPS port.

Screw that, try a real man's OS.

sorry, but stuff like Linux only works BECAUSE of copyright... The only reason if i modify the kernel source and distribute the binary, that I HAVE to give the source with it, is because of copyright. Otherwise I could just take the code that was released, make a closed source software, and watch as people interested are forced to decompile it to figure out my changes.

Also, when addressing userland issues on Solaris, you can't download sourcecd-4.0.iso and get the entire source trees of the userland _and_ kernel. Well, maybe you can download something like that from OpenSolaris (haven't looked in awhile,) but it's not a production release. I just spent part of the New Years holiday fighting with Solaris on some Sparc hardware. Right now I'm installing NetBSD 4.0 on some of it instead.

What I like a LOT about NetBSD is that that same source tarball set will build and run on all my various systems, from modern Pentium 4+ systems, Sparcs, my old MicroVAX, and my Macintosh SE/30 (well, don't build kernel and userland on an SE/30, a 16 MHz 68030 box, because there will probably be a new release before your build is completed.)

That means a lot more than 'well, someone has cobbled together a 'distro' that runs on this arch and another on that arch, etc. etc.' which is all most Linux people claim. Cross-platform just isn't important to other systems, but it keeps the whole thing honest and robust for it to be continuously buildable across a wide array of hardware.

Yup. And I just spent over $100 on shiny new disks. Old school, I know.

Iron and Wine, Fiest, The National, Over The Rhine, some others...

Already ripped to my media server, I no longer own a 'cd player' other than in the car, the new disks safely filed in the basement with all the others. The music industry dead? Not quite, but in turmoil for sure. I still find a lot that I enjoy though.

Also, I did not order the disks on-line. Bought at the local music store in town, http://www.jacksmusicshoppe.com/web/index.html. Considering the shipping cost from online, I only paid a little more, and the guy pays local property taxes, and he helps support the local music scene.

I take my five year old with me when I go and we check out all the instruments in back. Shiny brass, lacquered wood, snap a finger nail on the cymbals as we walk by. Rows of harmonicas in the display case, silver flutes all in a row. Give the small percussion instruments a shake, clack a stick against the plastic blocks. You cannot get that from shopping online. Then afterward, we walk to Zebu for a gelato for him and a coffee for me. Open the disks and check out the liner notes. Then head for home.

The music industry is going through changes, and ultimately it will survive in some form. My biggest lament is that the production quality has dropped. Even my old worn ears can tell the difference between a well mastered track and a poorly mastered track, even after it is ripped to MP3 (256kbps, high quality).

Hope you all had a good Solstice and wish you all a healthy and happy New Year going into 2008.

Try to think of those less fortunate than yourselves, and remember, the NetBSD foundation is looking to hit a donation target.
http://www.netbsd.org/donations/

So I'm rather puzzled by your statement. Of course, there could be a BSD license out there somewhere that does make such restrictions. I just haven't seen it or heard about it.

Though I don't recall which BSD license it is, or if there are more than one, but there's one that allows code to be closed. The only requirement is that for any code a programmer uses that someone else wrote using the license they have to be given credit. Here it is, the NetBSD license: "The Berkeley license is a rather liberal license. All it requires is that the author of the work be given due credit for their creation, and that their name not be used to promote products based on their work. It allows free distribution, as long as the terms are followed, and also allows people to modify the work and not distribute it, if they so choose. Some contributors also omit the third clause."

Further down it says this: "One thing that some people don't realize about Berkeley-style licenses is that they allow licensees (the users of the licensed work) to sell the code, in any form, with or without modification, and that they make no requirement that licensees give away the source code, even if they're selling binaries. This provides a striking contrast to the license terms granted by the GNU General Public License, because the GPL requires that, if you're distributing binaries, you must be willing to give away the sources to build those binaries."

Major achievements in NetBSD 4.0 include support for version 3 of the Xen virtual machine monitor, Bluetooth, many new device drivers and embedded platforms based on ARM, PowerPC and MIPS CPUs. New network services include iSCSI target (server) code and an implementation of the Common Address Redundancy Protocol. Also, system security was further enhanced with restrictions of mprotect(2) to enforce W^X policies, the Kernel Authorization framework, and improvements of the Veriexec file integrity subsystem, which can be used to harden the system against trojan horses and virus attacks. Please read below for a list of changes in NetBSD 4.0.

http://www.netbsd.org/releases/formal-4/NetBSD-4.0.html

Major Changes Between 3.0 and 4.0

The complete list of changes can be found in the CHANGES and CHANGES-4.0 files in the top level directory of the NetBSD 4.0 release tree. Some highlights include:
Networking

* agr(4): new pseudo-device driver for link level aggregation.
* IPv6 support was extended with an RFC 3542-compliant API and added for gre(4) tunnels and the tun(4) device.
* An NDIS-wrapper was added to use Windows binary drivers on the i386 platform, see ndiscvt(8).
* The IPv4 source-address selection policy can be set from a number of algorithms. See "IPSRCSEL" in options(4) and in_getifa(9).
* Imported wpa_supplicant(8) and wpa_cli(8). Utilities to connect and handle aspects of 802.11 WPA networks.
* Imported hostapd(8). An authenticator for IEEE 802.11 networks.
* carp(4): imported Common Address Redundancy Protocol to allow multiple hosts to share a set of IP addresses for high availability / redundancy, from OpenBSD.
* ALTQ support for the PF packet filter.
* etherip(4): new EtherIP tunneling device. It's able to tunnel Ethernet traffic over IPv4 and IPv6 using the EtherIP protocol specified in RFC 3378.
* ftpd(8) can now run in standalone mode, instead of from inetd(8).
* tftp(1) now has support for multicast TFTP operation in open-loop mode, server is in progress.
* tcp(4): added support for RFC 3465 Appropriate Byte Counting (ABC) and Explicit Congestion Notification as defined in RFC 3168.

File systems

* scan_ffs(8), scan_lfs(8): utilities to find FFSv1/v2 and LFS partitions to recover lost disklabels on disks and image files.
* tmpfs: added a new memory-based file system aimed at replacing mfs. Contrary to mfs, it is not based on a disk file system, so it is more efficient both in overall memory consumption and speed. See mount_tmpfs(8).
* Added UDF support for optical media and block devices, see mount_udf(8). Read-only for now.
* NFS export list handling was changed to be filesystem independent.
* LFS: lots of stability improvements and new cleaner daemon. It is now also possible to use LFS as root filesystem.
* vnd(4): the vnode disk driver can be used on filesystems such as smbfs and tmpfs.
* Support for System V Boot File System was added, see newfs_sysvbfs(8) and mount_sysvbfs(8).

Drivers

*

Audio:
o Support for new models on drivers such as Intel ICH8/6300ESB, NVIDIA nForce 3/4, etc.
o Added support for AC'97 modems.

Of course it runs NetBSD

Ah, so I go and look at the licenses for FreeBSD, OpenBSD and NetBSD, which all seem to come with strings attached, no matter how loose. Note that each of these licenses are based on the premise that copyright law is valid and enforceable.

trolling is a stupid sport. copy&past trolling is even more boring.

let me be the first to say: "old post!"

A system for which the complete run (homebrew copies aside) was 200 units?

I think you're confusing Linux with NetBSD.

PCC is actually extremely old ... and apparently it still carries the advertising clause.

FWIW, NetBSD does that, too.

does it runs linux?

Obviously not, but perhaps

"Of course it runs NetBSD".

http://www.netbsd.org/

(That said, Debian running here anyway...)

Not sure why I'm responding to such a clear troll (you didn't even call the MacBook Pro by its correct name) when I have mod points, but what the heck.

1. You don't have to buy a computer - even a laptop - with *any* OS. You can also, with some vendors, refuse the MS license and demand a refund for the OS if you format it off the hard drive. Finally, there are a couple companies selling Linux laptops (System76 sells nothing else).

2. Although I personally rarely interact with Macs except when my computer-illiterate friends and family members need me to troubleshoot theirs, one source I've found for installing a lot of great F/OSS programs is NetBSD's pkgsrc, a package management tool that can work with either binaries or (more often) build from source. Although not the same as the Ports system found on other BSDs, it has a similar ability to almost completely automate the whole installation and updates process, including configuration of source packages. More importantly, it runs on a wide variety of platforms, including Interix in Windows (see #3) and Darwin (Mac OS X). It's pretty easy to install and generally works well.

3. In Windows, if you want a POSIX environment and shell (I prefer bash but zsh is also available) you can install the Services for Unix (SFU, WinXP and earlier NT versions) or Subsystem for Unix Applications (SUA, Server 2003, Vista, and above), which will install what I guess could be called a "parallel OS" called Interix. The only particularly noticeable lack is that it still goes through the NT kernel for device IO (using the POSIX subsystem rather than the Win32 subsystem, but the same at the kernel's lowest level) which offers no direct block device access. You don't have to worry about finding compatible drivers though. It's not fantastic but it makes the XP machine I'm forced to use at work usable. I haven't managed to get a native X server running, but there are Windows-based X servers and they work well enough for a desktop environment, let alone XEmacs. In theory it should be possible to install KDE or similar, although you'll need to compile from source. All the common Unix shells, including zsh, are available (although only csh and ksh are initially installed). You can get more software for it either from Interopsystems.com (binaries built specifically for SUA/SFU) or NetBSD pkgsrc (will require building most packages from source).

Some of my thoughts, in no particular order:

- The Officially Sanctioned API (TM) for OS X apps is Cocoa. This is basically an extension of OpenStep. So is GNUStep. GNUStep even aims to implement Cocoa's extensions so as to allow Cocoa apps to be linked with GNUStep. However, for the time being, compatibility is incomplete and only at the source level. You might have some luck compiling GNUStep apps on Cocoa/OSX, but not running compiled Cocoa apps on GNUStep/Linux.

- Some people tried to get Darwin binary compatibiltiy into NetBSD. However, the project is now dead, purportedly due to lack of user interest. This is the only Darwin binary compatibility project I am aware of. What this means is that, at the moment, you can only run Darwin (AKA OS X) executables on Darwin.

- QEMU is a fast and open source emulator that can be used to emulate, among others, x86 PCs, AMD64 PCs, and Power Macs. This should allow you to run OS X as a guest OS. If you use QEMU to emulate an x86 on an x86, or an x86 or AMD64 on AMD64, it should run close to native speed. That is, as far as the CPU is concerned. Other hardware, graphics hardware in particular, will not have native performance.

- I've been a GNU/Linux user for over ten years. I also used Mac OS X for a couple of years. Eventually, I got frustrated with it and installed Linux on my iBook. I've never looked back. Of course, I am primarily a GNU/Linux and BSD user, which causes the little (sometimes significant) oddities of OS X to frustrate me. If you're primarily an OS X user, this will likely work the other way around.

- GNU/Linux does have some definite advantages over OS X. Just throwing down a few: more customizability, easier maintenance (given a decent package manager, such as apt-get), better compatibility with open-source software, and several possible advantages that depend on your choices: lower memory usage, lower latency, lower disk usage.

- Given that you have a Mac, OS X also has some advantages over GNU/Linux. Among others: it supports your hardware (what you get from Apple, anyway; Linux has the edge when it comes to third-party hardware), companies are more likely to support it (think software, hardware, and manuals), and ... well, can't think of anything more right now.

- As for why there is no compatibility layer yet: probably just because it's a monumental task. Think about how old Wine is and how well it works. Then think about Apple's yearly OS upgrades. Then consider that Apple has also moved architectures (PPC -> x86) since the introduction of OS X, and probably will again (x86 -> AMD64 - they ship that hardware, but the OS is still at least mostly x86). Then look at GNUStep and the instructions for building it (you're allowed to shiver at this point). A Mac OS X compatibility layer won't happen anytime soon.

For 2000 and XP, you want Windows Services for Unix or SFU. The download includes a complete - though basic - POSIX environment, a working GNU build toolchain (and yes, sources for all GPL code), and NFS server and client abilities. You shouldn't need to do anything except run the self-extracting download archive and run setup.exe. The installer will provide options to enable setuid and case-sensitive behaviors in the filesystem used within the subsystem, which should be used as a number of programs need them. The version of Perl included with the installer is obsolete and probably not worth installing; I'll get to that in a sec.

For Server 2003 and Vista, you must first enable the Windows component called the Subsystem for Unix Applications (SUA). This can be done by going to the (Add/Remove) Programs control panel - there's an option on the side for enabling Windows components. In Vista at least, you can also enable NFS and Unix-style printer connectivity here. You will then need to install the Utilities and SDK for the SUA, which is available for Vista/Longhorn and for Server 2003. On Vista there will be an additional install option to enable su-to-root behavior, required for programs like sudo - this option is important because by default, the Administrator account is disabled in Vista and privilege escalation is achieved through UAC. Although UAC can be used to start a Unix shell as root/admin, it cannot be used to change a shell's permissions while it runs. If you install sudo this becomes possible.

In all cases, you will get two Unix shells, the Korn shell and the C shell, in your start menu. Either one will start the subsystem and run a login process that creates the necessary environment variables and such. However, there are a few notable lacks. One of them is that while x11r5 and x11r6 client libraries are installed (with the r6 libraries used by default), there is no X server. Thus far I haven't managed to port x.org to Interix (the name of the subsystem "OS") so I use a win32 X server, specifically xming which runs on everything including Vista. The second major lack is a package manager or any software beyond the most basic requirements. For resolving this issue there are a couple options; the two I have tried are InteropSystems and NetBSD pkgsrc.

Both provide a good number of commonly used programs, and support the Interix platform. However, there are some major differences: InteropSystems primarily distributes binaries, with an eye to very easy package management and rapid usability. It also integrates better with Windows, doing things like adding a Start menu link for the Bash shell if you install their package. There is a fairly good forum for assistance and mostly it's a very easy out-of-box experience. However, their package tree is somewhat limited, and installing older versions of some libraries is trickier than it might be. They suuport all versions of Interix, from 3.5 (XP-era SFU) up to 6.0 (Vista's SUA). NetBSD's pkgsrc, on the other hand, is mostly source-based (although there are some pre-built packages for Interix; roughly as many as InteropSystems has, in fact). It takes longer to compile from source, and the initial download is hefty. However, a much wider selection of packages is available (although there's no guarantee they'll all work; indeed some, such as the X server, are flagged to not even attempt to build in Interix) and the packages are presumably optimized at least somewhat for your system during compilation. It's harder to find the right packages at times, though, and I have yet to get even the source-based boo

Really now? Ever heard of a thing called ACPI? If you have a laptop and have used the hibernation mode, you're executing code that is more or less in the BIOS.

That's true of APM - the OS actually made Bios calls and the Bios responded to events like pressing the suspend button directly. Since the Bios is real mode and non reentrant that was an issue. But it's not true of ACPI - the bios has methods in AML byte code but the OS is responsible for executing them via an interpreter. And the reason it uses byte code rather than native code is because it was designed to work on both x86 and Itanium. So EFI uses ACPI too for power management. Of course byte code in a virtual machine is hopefully a bit safer too.

And lets not forget that booting is still an important role in itself. Not only is there hardware initialisation, but there's the important role of loading the OS and/or boot loader. In fact, the reason that boot loaders exist (e.g NT boot loader, LILO, GRUB) is because the PC BIOS (interface) is so simple and unable to do anything more than load the first sector from a device and jump into it.

Which is an excellent place to stop. Trying to do more like ACPI or ARC firmware which it evolved from means you need to have filesystem drivers and network stacks in ROM. And magic system partitions which you need to start the machine and are mean a reinstall of everything if they get corrupted.

Booting from the network or other unusual devices has always been a little difficult. OpenBoot and now EFI makes this stuff easy because it's based on an extensible framework instead of hacks and workarounds for the backward-compatible legacy from an ancient platform (the original IBM PC, over a quarter of a century ago).

You can boot off the network with a normal Bios. Or anything else - you just need an option Rom which implements int 19h. Or the Bios itself could support network booting. And just because you don't understand it, don't assume it's a mass of hacks and workarounds.

I'm running Slackware NetBSD (slackware+pkgsrc)

While I realize you specifically asked about Linux, it is probably worth pointing out that NetBSD has been used as an embedded OS on ARM for quite a while. See NetBSD's embedded page for more information.

I can't find any evidence of the realtek comment in the linux tree and since the driver its from is has a four clause BSD it seems unlikely it was ever in linux. It does seem to be in all 3 of the major BSD variants though.

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic /rtl81x9.c?rev=1.68&content-type=text/x-cvsweb-mar kup
http://crypto.riken.go.jp/pub/OpenBSD/src/sys/dev/ ic/rtl81x9.c
http://fxr.watson.org/fxr/source/pci/if_rl.c

In realteks defense mind you i think the worst PCI ethernet controller comment is a bit unfair, sure its a bit heavy on the CPU and annoying to drive but it seems to be a pretty stable chip and its damn cheap.

TBH i suspect you will find lots of comments about hardware issues in any driver source unless its been through a comment stripper. Hardware has bugs and design flaws that can't really be fixed in the hardware either due to the cost of a respin or due to the fact that units are already in the wild. Some of those bugs will be in the IC makers errata but getting them to add newly found issues to the errata can be very hard. I strongly suspect the only difference is that linux/freebsd make those comments fully public whereas with propietry operating systems you'd probablly need a source license to see them.

Real linux users use BSD, http://www.lemis.com/grog/

http://www.freebsd.org/
http://www.apple.com/macosx/
http://www.openbsd.org/
http://www.netbsd.org/
http://www.dragonflybsd.org/

That condition is not a whim, is the only mechanism known to work to protect Free as in Speech in software. Free code as in the BSD and MIT licenses is how software was created at the beginning, and it quickly derived into an incompatible set of compiting closed, proprietary systems.

Yeah, it was awful. All the BSDs went away, and nobody used their code anymore.

Seriously, though, the BSD license has worked out well for many projects. I don't know who said this, but "the goal of the GPL is to make all software free; the goal of the BSD license is to make all software better."

The biggest advantage Windows has over everything else is that it will generally work with any hardware or software a person might pick off the shelf of any podunk software store anywhere on earth.

The base distribution of NetBSD is a 212 MB iso for i386. For Sparc it's a 156MB iso. That is a complete distribution, including networking, devtools, a full BSD userland, a complete and function X11 distribution, etc. You only have to pile on another 100MB of packages to have a highly usable system.

That base distribution will run nicely on an old 386 laptop. I've run the 68K Mac version of NetBSD on an SE/30, which is a machine with a 16 MHz 68030 processor and commonly 16MB of RAM. It ran X11 fine.

There's probably (still, hopefully anyhow) a way to get a decently complete Slackware distribution on small hardware. I haven't tried in awhile, since it would only interest me if I could install it on a BUNCH of my older small hardware, i.e. machines with older Sparc, 68K, and first-generation 80386 processors.

okay, i did it. now what?

You can find a solution(s) to your problem at one or more
of the following locations:

http://www.centos.org

http://fedoraproject.org/wiki/

http://en.opensuse.org

http://www.opensolaris.org/

http://www.ecomstation.com/

http://www.redhat.com

http://www.reactos.org/en/index.html

http://www.debian.org/ports/hurd/

http://www.openbsd.org/

http://www.freebsd.org/

http://www.netbsd.org/

http://www.dragonflybsd.org/

http://www.osfree.org/doku/en:start

http://www.skyos.org/

http://www.freeos.com/

http://www.minix3.org/

Added to bypass the stupid slashdot lameness filter which apparently doesn't like a post full of links. WTF is wrong with the
stupid lameness filter? Jeez, what does it want, for us to type paragraphs of meaningless drivel just to get past the lameness filter?
Sheeesh. OK, this is really stupid. Why don't ajfajf al;djal a fa fa lkdf jaa fal ja;ljf af af ajf;lajf alfjalf a fjal;fjafl; jaflakjf af;laj
jalkfaj fjf af af fajjjajal jajfa f afjdlakej2233 2235t2352 dsfalkfjal f 222j2 afdkja f23 2 2 2t2352322 233252352 2323232.

As soon as they implement a package management

I'm not sure, but you probably can run pkgsrc on it.

I cannot see why Apple would invest so much in developing a (closed) platform whose underpinnings simply do not exist (BSD not running on ARM).

There is a port of NetBSD to ARM. Also, as pointed out a few times above -- (Free)BSD is Darwin's user land, kernel is CMU Mach-derrived, windowing system (Aqua) is Apple proprietary. Technically, Apple could port both xnu (kernel) and user land to ARM, and as pointed out it could be (if not trivial, then at least) relatively easy, with PowerPC and m68k expereince that they have.

Now, I wonder if anyone could comb through Darwin source tree and see if there might be something hinting to that...

NetBSD is probably closer to this than anyone in the BSD world...

I don't see how this can possibly be the case since new code generated by NetBSD uses a 4 clause license which includes the advertising clause.

In other words no, NetBSD is in fact farthest from eliminating the advertising clause...

Source: http://www.netbsd.org/Goals/redistribution.html#de fault

...The great thing about you wanting to learn programming is that it's unlikely that you'll be CLI averse, but Slack still allows for you to install X and GNOME/KDE.

Slackware is the only distribution still in existence that I know of where you get a clean, recognisable core toolchain which hasn't been mutilated beyond recognition by package management or other crap. Although when you download the ISOs, you get binary packages, when you've installed it you end up with a base system that's more or less completely identical to what you'd get if you downloaded the sources from gnu.org/kernel.org and assembled it yourself. No apt or rpm based system can honestly claim that. They all engage in subpackaging, weird, non-standard directory locations for things, and other assorted perversions...all of which the misguided souls responsible for them view as improvements, but which without exception end up causing more problems than they solve.

What that means is that you're able to gain Linux knowledge that is largely distribution agnostic. It will also give you an appreciation of what constitutes a genuinely sane Linux system...and tragically, there are precious few examples of that still in the world these days.

If you then want a sane form of package management, you can install pkgsrc, NetBSD's portable package management which works with Slackware and numerous other platforms.

This combined will give you a much more transparent, stable, reliable, efficient, and genuinely UNIX-like system than is usually seen with Linux distributions.

There is nearly always a tradeoff between superficial user friendliness and technical excellence; there is no free lunch. As another example of what I mean here...McDonald's might provide instant gratification in terms of food, but we've all seen the studies people have done into what said food is (or at least used to be) like from a nutritional perspective. The "user friendly" distributions follow the same principle where stability, transparency, and general technical desirability are concerned...they're fast food.

No, but NetBSD!

Na, it's the NetBSD that de Raadt's wife should avoid like a plague.