The problem is that a lot of his uncertainty comes from systematics, not statistical error. If it was pure statistical error, then you could definitely do that based on 3 elections, but he was either going to get essentially every state right (if the systematics were small) or every state wrong by about the same amount (if they weren't).
I have an Asus EEE PC (900A) with NetBSD 5 that runs the stock X.org and uses the kernel Intel DRI driver (i915drm) for accelerated 3D performance -- pretty good given the hardware. There are DRI drivers for Radeon that I've also used, haven't looked into Nouveau. So the 3D support foundation is there, but the hardware pickings are still kinda slim.
Besides basic 3D acceleration, the continual 'catchup game' with desktop BSD is the explicit coding for Linux on the part of the big open source desktop environments, example: https://live.gnome.org/PortabilityMatrix
If you like to 'hack'...well, do foods from scratch. I like to grind and stuff sausages.
...
but it amazes me what passes for flavor from many people I've meat from up North,
Nice slip-up, Hannibal.
Thanks for a very thoughtful and informative post!
Where I started in this thread was posting a 1.2 MB kernel RAM footprint in vanilla NetBSD/ARM. This is with UFS/ext2/msdos filesystems, tcp/ip networking, NIC, USB standard devices (bulk storage, audio, etc.) loaded. It doesn't sound terribly far off at all. Outside of the XIP and nommu advantages, which are very significant, I'm actually curious whether it would boot in 2 MB with a minimal userland. The SoC hardware has 32 MB, so I've never bothered editing the memory map. I'll trim it further as your reference did and see what it'll do...
On the Linux side, I'm really impressed at how nommu and many other patches have integrated into mainline. I always expected the bulk of uClinux to be forever a separate patchset. It's great to see.
SMS's aren't particularly cheap. Also note that the message will travel over wireless 802.11 when available. It's cost effective, since I can sign up for a fairly minimal SMS plan and know that most of my messages are being carried by my devices' Internet access. It also means that I can receive messages even when I don't have cellular service but do have wireless Internet access.
Thanks, appreciate the link. But it sorta makes my point:
- An allusion to a vapor product with a 3 MB RAM goal is far from showing a dmesg.
- The linked "TLK" project reads nicely but has more aspirations than code, AFAICT
- The included 'web browser' was a misstatement, clarified in a subsequent post.
I'm aware of (uc)Linux's lovely support for MMU-less systems. It was a considerable kernel fork; what I'm impressed with is how much of it has been integrated back into mainline. It's a pity that someone long ago didn't do for NetBSD what the ucLinux project did for Linux 2.6.x.
But the context here is Minix3 on vanilla x86, not microcontrollers. So as I said before, I'm looking for configurations of x86 or ARM running a modern Linux kernel (2.6.x or 3.x) w/ 2 MB RAM or 4 MB with busybox. I sound dubious but am genuinely interested if this is possible (and how far you have to go down the rabbit hole to get there).
Linux can be configured to run in 2MB of RAM and 2MB of flash or less. It can run in 4MB RAM with a full network stack, busybox, and several hundred K remaining for apps.
There is no other full featured free unix like kernel which can do that. Certainly none of the free BSDs.
I'll take the bait. Care to show a reference to running a modern Linux kernel w/ 2 MB RAM, or 4 MB RAM with busybox, on i386 or ARM? Busybox can do wonders for storage requirements (e.g. for NAND FLASH), but it doesn't help with RAM at all! I found 8 MB to be difficult enough (!), last I tried ulibc and busybox on i386.
Just as a point of discussion, generic NetBSD is smaller than generic Linux (e.g. Debian) on the ARM platforms I've been using. A line from top shows the latest (NetBSD 5.1.2) kernel RAM footprint on ARM9: about 1.2 MB, with numerous filesystems, NFS, networking, USB support, etc. built in. This includes all kernel modules.
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 125 0 0K 1240K schedule 0:00 0.00% 0.00% [system]
Running 1 instance of httpd, sshd, and two user processes, minus 1.5 MB of buffers/cache, it's using 5.5 MB of RAM right now. Tightened up, it might boot in 4 MB but I haven't tried. Do note that this is with the standard (Net)BSD libc, all completely generic, 'out-of-the-box'.
Amazing work has been done to cram Linux into small places, but I think it's somewhat disingenuous to say that no BSD is close. I'd say NetBSD provides a rather interesting starting point.
Sure, you can. But UUIDs are the default behavior in many distributions (fortunately, 'blkid' will tell you the mapping between
Coming from a user of both Linux and both FreeBSD and NetBSD, I can't agree with the absolutes of your post.
BSDs are never easier than Linux. Linux is more modern, while BSDs stick to "tradition" and take pride in keeping things complicated. Just read their manuals/handbooks and you will have a pretty good idea.
An alternate wording: "Linux engages in constant superfluous redesign, while BSDs stick to conventional but consistent, stable interfaces that are well documented". The fact that up-to-date man pages and well-written manuals/guides exist says a lot by itself. Linux's myriad of ever-obsolete HOW-TOs is a poor substitute.
One good example of a painful process in Linux that is easy in (Net)BSD is developing for embedded architectures. I can be typing away on, say, a (PPC) Mac or a (Intel) Linux or a (Sparc) BSD box, and can cross-compile a NetBSD distribution for an ARM single-board-computer with one line:
While I do agree -- "Desktop BSD" is still not where it should be for the traditional BSDs, Linux has a long way to go here too. However, PC-BSD has done a pretty good job of doing the basic grunt work that is otherwise sorely lacking. "PC-BSD is to FreeBSD, what Ubuntu is to Debian".
Your third partition on Linux will be
This is a red herring. (1) On my NetBSD system, the first disk is
These issues have been solved in Linux with unique UUID's, but now your entry for
FreeBSD advocates spent a good portion of their time claiming that FreeBSD is faster than Linux. Maybe on servers under very heavy load. In all the tests I have made on a simple desktop, FreeBSD always felt a little bit slow, jerky, worse than Linux with a lightweight window manager such as LXDE (but not worse than Linux with KDE 4, for example).
You're confusing "faster" for "feels faster for interactive use". With all of the scheduler work in Linux over the past year or two, Linux desktop interactivity is really excellent. However, there is always a compromise between interactivity and overall throughput. BSDs schedulers tend to favor the latter, for better or worse.
NetBSD feels very light and fast, but then it doesn't do much out of the box. If you ever try Tiny Core Linux, check what it can do out of the box, that's about 18 times as much as what NetBSD can do.
This comparison makes no sense (to me) whatsoever. Stock NetBSD provides the loose equivalent of "Debian base+Xorg+gcc", and you can install whatever packages (binary or source) you want after that. Full versions of everything. Like Debian, that's not really comparable at all to Tiny Core Linux -- while it's a VERY cool project, it provides no compiler, very minimal command line packages, only a fraction of Xorg, a minimal GUI, and is i386/amd64 only. Under (Net)BSD, I'm just a 'pkg_add' away from having, say, Firefox, XFCE, etc. installed -- and with few exceptions, the process is *exactly* the same on Alpha, Sparc(64), Intel/AMD64, or ARM. Different targets.
Oh my, that brings back memories... thank you. Or maybe damn you. I'm not sure.
I suspect that Apple is not legally allowed to own record companies, as part of the settlement with Apple Records.
Scientists should always, always use metric.
Real scientist here... astronomer, actually. And while we often use metric, and we never ever use Imperial units, we do often use units that are the natural scale. Mass is usually in solar masses; length can be in Astronomical Units (=the radius of the Earth's orbit around the sun), parsecs, or solar radii; power is in solar luminosities. And there's a good reason - knowing that a mass-to-light ratio is 2 M_sun / L_sun tells you a lot more than knowing that it is 10000 kg / Watt.
[TMB]
I get direct transmission into the aural receptors of my brain, you insensitive clod!
With your bare hands?!?