Slashdot Mirror

Clerk: do you want any frees with that?

Gee, get your quotes right. I know this quote (because I use it in my .signature when I post on usenet). The exact words are: Would you like fries with that? and they are from a network driver in Linux: sunhme.c

OK you got 1 of 6 correct. You fail.

Linux and FreeBSD kernels, which
1. is the most SMP scalable (parallel)

Linux. (Linux and FreeBSD both started with a BKL about 5 years ago. Linux is now being used on 512 processor machines, FreeBSD doesn't scale past 4 CPUs for all their research).

2. is the most algorithmically scalable
Linux

3. has fastest single threaded performance
Linux (from the horse's proverbial mouth).

4. runs on more architectures
Linux. See here and here (The Linux Kernel supports more architectures than the NetBSD kernel, idiot).

5. supports the most hardware
Linux. See here and here (NetBSD is actually the one that prides themselves as running on toasters. And nobody cares about your shitty DEC Alphas. IA64, POWER are where its at now).

6. has the fastest TCP/IP stack
Linux

See you again next year.

here is the actual session:

vegard@gyversalen:~$ ping -i 450 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes

64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

--- 10.0.3.1 ping statistics ---

9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms

We're talking about Linux vs FreeBSD here, clown, not to mention that you provided zero evidence. You got failed.

Linux and FreeBSD kernels, which
1. is the most SMP scalable (parallel)
Linux

2. is the most algorithmically scalable
Linux

3. has fastest single threaded performance
Linux

4. runs on more architectures
Linux. See here and here

5. supports the most hardware
Linux. See here and here

6. has the fastest TCP/IP stack
Linux

Hope this has been helpful. See you again next year.

Linux Weekly News has a copy of the letter. The 65 files don't sound quite as threatening when you discover the first 17 of them are errno.h. Quick, someone go warn the IEEE!

http://lxr.linux.no/source/include/asm-i386/posix_ types.h?v=2.0.39, line 21:
typedef long __kernel_time_t;

It's defined as a long for the other architectures as well. AFAIK a long is 32 bits on all platforms Linux 2.0.39 runs on.

http://lxr.linux.no/source/include/asm-i386/posix_ types.h?v=2.0.39, line 21:
typedef long __kernel_time_t;

It's defined as a long for the other architectures as well. AFAIK a long is 32 bits on all platforms Linux 2.0.39 runs on.

The LUG in my area, Bergen Linux User Group, implemented RFC1149 when Alan Cox visited (of course he was a key part of the project). Pigeons were used in a real-life experiment that had IP implemented over avian carriers. See the details with pictures here.

Although lacking "quality of service information", the closely related RFC 1149 has been implemented by the Bergen LUG.

That'll be a GPL3: we've been on GPL2 since 1991.

A whole lot of GPL software specifies that it's distributed under "version X or any later version", or doesn't specify a version (which means you can use any version, according to section 9). So your solution would work fine for those things. It wouldn't work for Linux, though, since Linux is explicitly distributed under version 2 only.

Anyone remember Happy Meal Ethernet and Big Mac Ethernet?

I remember the driver sauce, hme is surely worth reading. sunhme.c sunbmac.c

Anyone remember Happy Meal Ethernet and Big Mac Ethernet?

I remember the driver sauce, hme is surely worth reading. sunhme.c sunbmac.c

Linux is good because you can investigate what actually happens.

default_idle() is called when there's no special power management idle function (which presumably does better).

if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
if (!current->need_resched)
safe_halt();

safe_halt() enables interrupts and halts the CPU; I'm not going to bother hunting down data sheets to demonstrate the effect this has on power consumption.

#define safe_halt() __asm__ __volatile__("sti; hlt": : :"memory")

APM and ACPI on x86 do fancier things; there are similar tools on other architectures. Trust me, the battery life of my Casio E-15 running Linux improved dramatically when I put in the "go to sleep code" in the analogous part of the MIPS kernel.

Linux is good because you can investigate what actually happens.

default_idle() is called when there's no special power management idle function (which presumably does better).

if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
if (!current->need_resched)
safe_halt();

safe_halt() enables interrupts and halts the CPU; I'm not going to bother hunting down data sheets to demonstrate the effect this has on power consumption.

#define safe_halt() __asm__ __volatile__("sti; hlt": : :"memory")

APM and ACPI on x86 do fancier things; there are similar tools on other architectures. Trust me, the battery life of my Casio E-15 running Linux improved dramatically when I put in the "go to sleep code" in the analogous part of the MIPS kernel.

This is source.

Of course if you really want to browse the source you'd be using a different source navigator.

See the project page for pictures and documentation.

By the way, the code on those pages haven't worked for a while, since the TUN-interface in the Linux kernel changed a while ago. This just as a warning if anyone else decides to test it out...it makes for a fun social even for a LUG, for example!

Or, better yet, make your own implementation, and if you live within pigeon flying distance of us (basically southern Norway, if we don't want the experiment to last *too* long), we'll do interoperability tests, so we can advance the standard! We need two independent but interoperable implementations.

- Vegard, one of those that implemented TCP/IP over pigeons.

The Bergen Linux User Group actually implemented RFC 1149 during 2001. See http://www.blug.linux.no/rfc1149/ .

RFC 1149 - Standard for the transmission of IP datagrams on avian cariers was actually implemented...

which was originally written as a joke but actually implemented a few years ago. The RFC is officially titled "A Standard for the Transmission of IP Datagrams on Avian Carriers" (note the date of publication : April 1). In short it's a method of IP transmission using carrier pigeon. The Bergen Linux Users Group in Norway actually performed the first documented transmission of CPIP (Carrier Pigeon Internet Protocol) back in 2001 and has a pretty detailed writeup of the event, including quite a number of pictures.

which was originally written as a joke but actually implemented a few years ago. The RFC is officially titled "A Standard for the Transmission of IP Datagrams on Avian Carriers" (note the date of publication : April 1). In short it's a method of IP transmission using carrier pigeon. The Bergen Linux Users Group in Norway actually performed the first documented transmission of CPIP (Carrier Pigeon Internet Protocol) back in 2001 and has a pretty detailed writeup of the event, including quite a number of pictures.

...and Linux is the only OS to have actually implemented it.

For those of use that are running the 2.5/2.6beta kernel, what should we do when we do find bugs?

Some resources:

• Dave Jones's "Post-Halloween" document is a good quick overview of what's new in 2.5/2.6, with some useful information on common pitfalls.
• REPORTING-BUGS in your friendly local kernel source tree.
• Documentation/BUG-HUNTING, same place.
• 2.5/2.6 bugzilla

For those of use that are running the 2.5/2.6beta kernel, what should we do when we do find bugs?

Some resources:

• Dave Jones's "Post-Halloween" document is a good quick overview of what's new in 2.5/2.6, with some useful information on common pitfalls.
• REPORTING-BUGS in your friendly local kernel source tree.
• Documentation/BUG-HUNTING, same place.
• 2.5/2.6 bugzilla

28 Apr '01 - 64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms

Aegilops

is the BSD copyright notice intact, as the BSD license requires?

Yes.

Dr. Stefan Hildemann claims to have had a chance to see SCO's code show without having to sign the NDA; he has posted his impressions (in German).
http://forum.golem.de/phorum/read.php?f=44&i=1774& t=1716
Thanks to Robert Taylor this English translation of the posting

... The crunch, however, is a function of the scheduler, which is, over a length of about 60 lines, indeed identical except for slight differences. In this section, there is also a whole lot of corresponding comments...

This raises more interesting questions. Since the SMP scheduler in question was specifically written directly for Linux kernel, and both Caldera/SCO employees only added patches, does it not seem more likely that if there is common source and comment then it is likely that the source in question was copied from GPL'ed Linux source to The SCO Groups own Unix?

OK - avian carriers sounds good in theory, and has been implimented. But consider the implications of being spammed using this protocol! Sure its difficult, but if someone does it {shudder}

This is why I always suggest alternatives to Cisco such as IP over Avian and actual implementaion on Linux

Rus

Here is the (as far as I know) worlds first RFC 1149 implementation, in english, with pictures and Alan Cox. (Yes. He is real.)

Of course it's even more amusing when you consider that someone actually implemented it.

Has anyone, besides SCO, looked at the Linux code and tried to determine what might have come from SCO, and what might have come from a common predecessor?

So far four components of the Linux source have been implicated: SMP, RCU, NUMA, and JFS.

I have done a little digging into the NUMA code. IBM has contributed several people who have participlated in developing NUMA under linux. Some names I've run across: Martin Bligh, Matthew Dobson, Patricia Gaughen, John Stultz, Michael Hohnbaum. IBM even has a Linux NUMA news archive. It appears that IBM jumpstarted it's NUMA efforts when it purchased Sequent which was intitally intended to boost its participation in Project Monterey, which is no doubt the origin of SCO's objections.

The most obvious source file for NUMA is /usr/src/linux/mm/numa.c in the 2.4 series kernels. This file contains a comment header stating it was "Written by Kanoj Sarcar, SGI, Aug 1999". This file has been removed from later 2.5 kernels (its gone by at least 2.5.46), appearently because Linux accepted an IBM NUMA patch as reported here. This patch was announced by Martin Bligh and is likely the code in question in this lawsuit.

fork.c, line 272

module.c, line 54

module.c lines 153-155

and most potentially damning, signal.c, line 430

fork.c, line 272

module.c, line 54

module.c lines 153-155

and most potentially damning, signal.c, line 430

fork.c, line 272

module.c, line 54

module.c lines 153-155

and most potentially damning, signal.c, line 430

fork.c, line 272

module.c, line 54

module.c lines 153-155

and most potentially damning, signal.c, line 430

Since RFC 1149 clearly works, then a few minutes of interplanetary delay shouldn't be too much of a problem.

Hamster

if only there was an effective reference implementation

Ah, but there is. http://www.blug.linux.no/rfc1149/

From RFC 2549
The highly unofficial CPIP WG
Pigeon-powered Internet takes flight

Lesse, I'm having some memory problems...
Oh, I've got the manual! Right here! /* $Id: dma.c,v 1.7 1994/12/28 03:35:33 root Exp root $
2 * linux/kernel/dma.c: A DMA channel allocator. Inspired by linux/kernel/irq.c.
3 *
4 * Written by Hennus Bergman, 1992.
5 *
6 * 1994/12/26: Changes by Alex Nash to fix a minor bug in /proc/dma.
7 * In the previous version the reported device could end up being wrong,
8 * if a device requested a DMA channel that was already in use.
9 * [It also happened to remove the sizeof(char *) == sizeof(int)
10 * assumption introduced because of those /proc/dma patches. -- Hennus]
11 */

21
22 /* A note on resource allocation:
23 *
24 * All drivers needing DMA channels, should allocate and release them
25 * through the public routines `request_dma()' and `free_dma()'.
26 *
27 * In order to avoid problems, all processes should allocate resources in
28 * the same sequence and release them in the reverse order.
29 *
30 * So, when allocating DMAs and IRQs, first allocate the IRQ, then the DMA.
31 * When releasing them, first release the DMA, then release the IRQ.
32 * If you don't, you may cause allocation requests to fail unnecessarily.
33 * This doesn't really matter now, but it will once we get real semaphores
34 * in the kernel.
35 */
36
37
38 spinlock_t dma_spin_lock = SPIN_LOCK_UNLOCKED;
39
40 /*

As for RFC 1149, it's also worth noting there was an implementation too...

If you, like me, are tired of having to manually deliver documents or other items within your office building, and if your building has high ceilings, good lighting, and minimal air currents, then you will inevitably reach the same conclusion I have: An automatic helium blimp delivery service.

nope. rfc 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers"

same dependability as the blimp though: not very dependable.

so has this guy written the rfc for the intraoffice blimp protocol yet? no!? what kind of nerd does he think he is! ;-P

Actually, what about interference from RFC 1149 network (a physical layer network run over trained pidgeons)?

...I prefer CPIP rather than cumbersome TCP/IP applications like HTTP or FTP. If it was good enough for Noah, then it's good enough for me.

Internet access on Mars? Hmmm...

buzzbomb@mars:~$ ping yahoo.com
PING yahoo.com (64.58.79.230): 56 octets data
64 octets from 64.58.79.230: icmp_seq=0 ttl=242 time=757610.6 ms
64 octets from 64.58.79.230: icmp_seq=1 ttl=242 time=757638.2 ms
64 octets from 64.58.79.230: icmp_seq=2 ttl=242 time=757620.5 ms

--- yahoo.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 757610.6/757623.1/757638.2 ms


Well, it's faster than the actual implementation of RFC 1149.

You said: "Well, I suppose when Bush wins in 2004 and we all move to Australia, we'll have to run our file-sharing apps via carrier pidgeon."

Fortunately they'll be prepared. There is a protocol: RFC 1149 and a sucessful test by a LUG in Norway.

This kind of crap is exactly what it would take to make me cancel my account with my ISP and do everything by paper again.

Here's an RFC to help you with the transition to paper-based Internet access.

...and here's a group of people who've implemented it, and here's the article /. ran on it.

Offtopic I know but for the ultimate in bad latancy try this link. An implementation of RFC-1149

http://www.ietf.org/rfc/rfc1149.txt

Don't forget that it has actually been implemented.

One of the pidgeons left an Audit Trail