Slashdot Mirror

• A fileserver running Debian GNU/Linux stable and NFS, Samba, and Netatalk. Also does internal DNS.
• A gateway/firewall running Debian GNU/Linux and the IPMasq package.
• An AMD desktop machine running Debian GNU/Linux, FreeBSD, and Windows 2000. All three OS's mount /home off the file server.
• An iBook running Mac OS X, Mac OS 9, and Debian GNU/Linux. All three OS's mount /home off the file server.

As for something that might help you keep things synchronized, I know of something related that will at least help if you ever have to do a reinstall. It's called Gutinteg and was very widely used for reinstalling a machine from scratch with both Windows 95 and Linux dual boot at the NMT Computer Center.

And if that doesn't work, This Just Might.

Pics of the $170/node cluster threaded together.

FSB is 133, if I'm not mistaken. Cache is ... whatever is on the Durons. Sorry I don't know off the top of my head.

I'm rather disappointed that nobody remembers some of the original lightning/rocket work done at New Mexico Tech's Langmuir Research Center. They've been "drawing down lightning" there for fifty years.

Besides, Tech has some of the best green chile con carne around. Especially for a University cafeteria!

For more information, check out the Langmuir Lab web site.

--NMT, Class of '93

Probably most of everyone's recollections of seeing this a few years ago has to do with a show on it on TLC or Discovery. That show was documenting some of the research that is done at New Mexico Tech in Socorro, New Mexico.

Every Summer, a bunch of teachers and students make the trip up South Baldy mountain to the Langmuir Lab in the hopes of triggering lightning.

It's not as easy as it might sound to trigger lightning. In fact, the Summer my roommate was up there (1992, I think), they weren't able to trigger any lightning.

Basically, someone would keep watch for promising storm clouds to come over the lab. Once the clouds got closer, they would start checking an electric field mill, a device used to measure the strength of the storm-induced fields. When the field was sufficiently high, a person sitting in what was essentially a steel pup tent would fire the rocket into the cloud, hoping to generate a strike along the metal cord that it carried with it.

Even though they didn't get any lightning that year, National Geographic sent up a photojournalist, who snapped some photo's of them. In late '92 or early '93, National GeoGraphic did have a small one or two page article on it at the back of the magazine, so they did get some recognition.

By the way, New Mexico Tech is also the same place where the NRAO is located (what is essentially the command post for the VLA radio telescope. It's the one seen in Contact.

They also do explosives research there, too. I've seen a show or two on TLC/Discovery that featured them. It's a neat school. Very underrated...and cheap, too!

--NMT, Class of '93

• http://sprite.gi.alaska.edu/html/sprites.htm
  
• http://thunder.msfc.nasa.gov/primer/primer3.html
  
• http://geology.about.com/library/weekly/aa020198.h tm?rnk=r7&terms=lightning
  
• http://ibis.nmt.edu/sprites/sprites.html

The physics department at NMT has a couple of really cool toys for being so small... They're also about 60 miles from the Very Large Array, a collection of radio telescopes. (Oh yeah, some of the movie "Contact" was filmed there)

Yes, Victor stole his student's work. RTLinux was also developped at NMT, which begs for the question, why doesn't NMT have a stake in this? Aren't such projects suppose to belong to the research facility where the work was done? Also, why is it that NMT points to FSMLabs? Does NMT endorse FSMLabs' commercial tactics?

But of course, the lawyers will pick on the little guy to send a message to all the other little guys. Like with Felton, the RIAA didn't expect Felton to fight back. When he did, their response was, oh, we didn't mean it.

But of course, the lawyers will pick on the little guy to send a message to all the other little guys. Like with Felton, the RIAA didn't expect Felton to fight back. When he did, their response was, oh, we didn't mean it.

--

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

SEE ALSO:
baby(1), celibacy(1), choad(1), condom(1), dream(1), echo(1), lsd(1), sex(6).

We used Linux back in '96 at New Mexico Tech (holy crap batman, their site is looking awful these days). We were broken into three person teams. Our final project was to implement threads in Linux.

• Tom of Perl Fame
• comp.lang.python

More Information on Perl and Python.

• I take time to get medical treatment for an RSI.
• I am fired for taking the time to get treatment that is successful.
• They pay a judgment, but continue with a countersuit of libel.
• They dismiss this countersuit, when a judge asks what is libelous.

A personal attack is a personal attack. Just because you are too much of a coward to identify yourself does not make it less personal. If I mug you does it make it any less personal, if I wear a mask?

The kind of material is not very suited to an OS course, just because it isn't about interacting with the OS. However, it is useful for students that haven't had a hands-on course in OS-specific programming. Anyway, besides other linux-based projects for other classes (writing an ADA-CS compiler for LinuxPPC among the more interesting,) we also have an OS class that is very interactive with the Linux Kernel. It's a third-year course, but I'm taking it now. Here are some of the projects I have encountered so far:
1) (starting easy) Become familiar with Linux by installing it on a machine, and then download some kernel source from www.kernel.org, and reconfigure and recompile the kernel.
2) make your own system call. What's involved here is learning how to pass user information to the kernel, and how to set up your system call in the linux kernel (with include/asm/unistd.h and (for us) arch/i386/kernel/entry.S).
3) Implement your own scheduling algorithm. Incorporate it into the Linux kernel by writing a system call to allow the superuser to switch between the default scheduler and the one you wrote. Then, using lmbench, compare the performance benchmarks of your scheduler with that of the builtin Linux scheduler. The more complicated the algorithm, the more points it may be worth (so implementing a lottery-based scheduling algorithm is worth more than a simple least-first algorithm)
4) Something involving cooperative user-space threads (we haven't gotten that far in class yet; the assignment has only been hinted at.)

In all of these projects a major emphasis was that the kernel must not crash under any circumstances (otherwise we might as well do windows programming.) So we had to check all kinds of possible dangerous situations (somebody passes a null buffer for the kernel to store information in, etc.) Also, for these projects, we are allowed to work in groups of up to 4 people. While the coding itself does not lend itself directly to group work, the brainstorming is definitely helped along (four heads are usually better than one.)

For more information about our operating systems course, check out www.cs.nmt.edu/~cs325.

kudos on trying to include linux in the standard CS curriculum.

(rathstar)

Mattel must be spending a fortune in lawyers for going after me and Barbie Benson's Sin Circus and going after a college kid for posting a Barbie Joke

Mattel must be spending a fortune in lawyers for going after me and Barbie Benson's Sin Circus and going after a college kid for posting a Barbie Joke

For those who don't know, I posted the information about my lawsuit against them. They filed a countersuit for libel, saying the information on the site is not true. They still continue with this countersuit after they paid over $140k to me in a judgment. If the information on the site was not true, why would they pay so much money for a lawsuit which is detailed on the site?

Mattel Threatened one kid who put some Barbie jokes up at school. I was informed that Mattel also is going after Barbie Benson and her site Barbie's Sin Circus for using the name Barbie. It has nothing to do with the doll (except, when you see her pic, you'll see she's a doll ;).

This is not an anti-Linux remark; there's a similar hack for NT that puts a mini-OS under NT, and it has the same problems. I can understand why Linus isn't that thrilled with RTLinux. The right way to do this is to start with a message-passing microkernel and build upward from there, not start with a UNIX-type kernel and build down. I'd like to see an open-source microkernel catch on. The GNU Hurd people were on the right track, but that project seems to be moribund.

The key to doing this right is to have a very, very limited microkernel with fast message-passing. If you do it right, drivers, file systems, and almost everything but message passing and scheduling is outside the kernel and can't crash it. This is how you build systems that work when it matters.

A limitation of such systems is supporting hardware boards that do complicated DMA. Devices that look like channels (SCSI, FireWire, USB, etc.) are fine, but graphics accelerators create problems, as do random ISA and PCI boards that do DMA. Safely managing a device that can store anywhere in physical memory from outside the kernel is tough. QNX generally supports display devices in plain VGA mode for this reason.

Mattel is the one who filed a libel countersuit against me! Mattel is the one who are trying to shut me up by claiming that I am lying. I am not the only one that they used legal action or the threat of legal action (an example) to squelch people.

When I say Mattel, I mean Mattel/TLC/MSI, since they are all parts of Mattel.

Mattel retaliates against injured geek!

• Services that require RT service levels, and thus run at a higher level than any Linux code.
• Services that do not require RT guarantees that may thus run as Linux processes.

It's probably fair to say that things like eCos, RTEMS, VX-Works, and QNX should not worry too much about Linux; if the application involves life-and-death control issues, I'd rather prefer to use one of those. In critical cases, the maker of an embedded system will have source code access, whatever the cost.

But there is certainly room for Linux to crowd out lower grade things like WinCE in less critical "Soft RT" applications where the cost of the solution is a critical factor.

Well, how does TurboLinux differ from the situation above? Well...

• TurboLinux figured out from the *beginning* that it was to their advantage to release their module under GPL. Caldera's distribution went through several revisions before they decided to make the source code available.
• The size modification to the kernel is smaller! NKFS was 2940 lines of code, IP_CS is 2781 lines of code
• IP_CS is better broken up into approx 60 functions whereas NKFS is only broken into approx 50 functions.
• The header files for NKFS has only two lines of comment explaining the purpose of the data structures. The IP_CS header file has comments next to every variable and function defined.
• The NDS browser uses RSA code which is under patent and US export control which means that Caldera probably will never release the entire source code (if any) of the program which uses the NKFS module. TurboLinux has indicated that as newer versions of the cluster server daemon comes out that they will release the source code to the older versions.
• NKFS has never been a part of the offical kernel source distribution and Caldera has never indicated that they will try to submit it for being included. IP_CS is also presently not part of the offical kernel source distribution but TurboLinux appears to be interested in submitting it for being included in future major versions of the kernel.
• The November 1999 Linux Journal lists Caldera's website as having had approx 10,000 visits whereas TurboLinux was listed as having less than 2,000. It seems clear that Caldera has five times the influce in pushing a prioritary fork.

So why are we getting so upset over the fact that George Weiss of Gartner Group Inc. has "fork fears"?! Isn't this the same G. Weiss that in January had fears about the "chaotic nature of the [Linux] market." He goes on to state "... best practices would entail putting in place practices to discourage, if not ban, code hacking when using Linux." Does this guy really understand Linux? The fact is that being able to code hack linux is one of it's biggest advantages. Another advantage is the growing number of non-standard modules. For example: you get better performce with INN v2 if you have rawfs, your not going to get far on the network with a Madge token ring card unless you have loaded the non-standard Madge kernel module driver and if you want to really fork from standard kernel method just put a distribution together based around the results of the GGI Project or RTLinux. Non-standard kernel patches and modules have been around for a long time and IP_CS is no different. History has shown that the main Linux kernel can survive this "problem." So, hand a spoon to Mr Weiss' "fork fears" and enjoy what TurboLinux is providing under GPL.

Mattel, and originally TLC, are trying to silence my complaints of their violating employment laws and common decency.

It is one thing to protect one's trademark. It is entirely another to squelch any commentary, analysis, critism, or satire.

Injured software engineer wins against Mattel!

A few years ago, when I worked at Discovery World we ported the armlib software from UNC to work on RT-Linux with the PHANToM. Our work is available here . It was pretty fun work while it lasted. Unfortunately, when I left, the project died. We did develop an extension of the UNC client/server protocol for remote manipulation - we called it TouchU-TouchME, but we never had a chance to present a paper on it. Oh well... I note on the UNC web site that someone has created a scanning-tunneling probe using Lego Mindstorms. This would be an ideal mate to the work that WillWare describes above.

Troy Baer wrote
Something to keep in mind about the the Origin 2000 (SGI's 128-256 CPU boxes) is that they're not SMP systems. They're ccNUMA machines, and a lot of the "ccNUMAness" (including cache coherence, I think) is handled largely by the hardware.

The point of ccNUMA is to minimise the cost of porting software from uni-processors. The crux of the matter is that it is non-trivial to adapt programs to run on multiple processors efficiently. The ideal is to have a single source tree, add extensions such as OpenMP, then recompile. Kernels are a different matter as they have to be closer to the hardware. It is still a royal pain to code to the wire and manually manipulate the cache and bus protocols but that is what is needed for maximum performance. Apart from special cases such as national defence codes, the commercial imperative is time-to-market which means a ccNUMA machine can address 95% of the issues at reasonable cost would be preferred.

I wouldn't be surprised if you could boot the MIPS version of Linux on (for instance) an Origin with little or no modification. I don't know how well it would scale, though.

As far as I'm aware (correct me if I'm wrong), the SGI port of Linux has so far concentrated on older systems such as Indys and patches for their VisualWorkstation. I suspect it will take a while (2-5 years?) for them to get to the stage of having Linux+IRIX SMP extensions running on their highly scalable systems. Cellular IRIX is a single system image which is different from the way Linux is designed. Perhaps one conceptual integration approach is to follow how RTLinux works in having a separate real-time kernel embedded within the full Linux system. Also there are other multiprocessor optimisations like processor affinity which might take a while to enter into the kernel. SGI staff may be very enthusiastic and dedicated but there is a lot of work involved which will take time.

In other words, nice PR for SGI but don't hold your breath.

LL

I highly recommend going to New Mexico Tech for CS grad school. Sure, we're a little school in a little town stuck in the middle of nowhere, but it's an excellent school. And if you don't believe me, just look up Cort Dougan on the Net. For his thesis, he ported the Linux kernel to the PowerPC processor. And now he's working on his Ph.D. Plus there's only around 1500 people here. And it's way cheap. Here's the Web site. Oh, and another page I found on graduate schools in the CS and Math areas.

Would these be considered different Linux OS's then:

Real Time Linux
Linux Router Project

They are patched versions of Linux, but I would still consider them different at the kernel level.

The problem is tahta some part of the linux kernel are x86 oriented (like the MMU design see : http://www.cs.nmt.edu/~cort/papers/ linuxppc-mm/)
and so are the drivers - that is because the hardware on those card contains x86 code :( so if you don't have a x86 machine the card won't initialise itself ....

Ken Kutaragi, CEO of Sony Computer Entertainment Inc. and former manager of Sony's Playstation research and development, is known to be interested in Linux and the possibility of encouraging other parts of Sony to adopt their new CPU e.g. for embedded systems products. However, a recent interview with Kutaragi by NikkeiBP showed his initial goal is limited to using Linux only as a development environment to create software for the Playstation. Look up Sony!

Real-Time Linux + PSX CPU would be a great environment for embedded systems. Sony should realise the opportunities and start marketing in the next year or two before the price/performance advantage is lost. Sony could get Linux ported to the PSX with absolutely minimal investment assuming they gave adequate technical documentation to the open source community. Perhaps somebody in Sony (Japan) will read this and take up the suggestion.

Signed, 9cd1ecb08da5d9f864a14310d4607185

zaha wrote:

until linsux is real-time, its applications in the embedded, mission-critical markets will be limited.

I wouldn't use a standard Linux kernel for a real-time application, that would be silly. The same goes for a Solaris kernel or an NT kernel. None of them are designed for real-time operation. If I was doing a simple real-time system, I would use a simple real-time kernel like QNX RTOS or Caldera's DR-DOS.

For a more complicated system, I would use a hybrid RT system like Real-Time Linux. Check it out, I think you'll be pleasantly surprised.