Slashdot Mirror

Just a guess: If you currently do a search at the University of Indiana, the results are Powered by Google Search Appliance. Sounds like they'll switch to ChaCha for intranet searching.

Hi, if I follow the link you provided down to
ftp://ftp.ussg.iu.edu/linux/opensuse/distribution/10.3/iso/dvd/
I can only find an ISO file that is about 115 MB in size. Am I missing something here? I have tried to download it all day from the main SuSE site without any success. Do you have any other links? Thanks

ftp://ftp.ussg.iu.edu/linux/opensuse/distribution/10.3/

In 2000, Daniel Phillips started developing a new Linux filesystem that
would have many of the features netapps WAFL has, and ZFS has now.

This filesystem was called Tux2.

He was quite sure that the patents NetApp had on this weren't valid,
because of prior art, and because his algorithm was quite
different and quite a bit smarter:

http://uwsg.iu.edu/hypermail/linux/kernel/0010.0/0 343.html

Yet somewhere in 2002, he gave up on Tux2, presumably due to pressure
from netapp: http://lkml.org/lkml/2002/8/26/138 .

I wonder what will happen to BTRFS in light of this new NetApp
legal action: http://oss.oracle.com/projects/btrfs/

Mike.

Oh my gosh, the Linux scheduler is on Slashdot. Again! :-)

Frankly, this amount of interest in the Linux scheduler is certainly flattering to all of us Linux scheduler hackers, but there are certainly more important areas that need improvement: 3D support, the MM / IO schedulers, stability, compatibility, etc. (There's also the FreeBSD scheduler that went through a total rewrite recently - and it got not a single Slashdot article that i remember.)

But i digress. A couple of quick high-level points (most of the details can be found in the discussions on lkml):

I find the RFS submission interesting and useful, and i have asked the author to split the patch up a bit better, to separate the core idea from optimizations and unrelated changes - to ease review and merging of the changes, and to make the changes bisectable during QA after they have been applied to the mainstream kernel. (That is how patches are typically submitted to the Linux-kernel mailing list - it's a basic requirement before anything can be merged. CFS for example was applied to the 2.6.23 development tree in form of a series of 50 (!) separate patches. (And the scheduler works at every patching/bisection point.))

I also pointed him to the latest "bleeding edge" scheduler tree, which already implements the same non-normalized form of math and makes some of the rounding and performance arguments moot i believe. (lkml mail).

There are some issues where i disagree with Roman at the moment: even when comparing to unmodified current upstream CFS, i think Roman makes too much out of rounding behavior and i have asked him to substantiate his claims with numbers (lkml mail).

The current precision/rounding of CFS is better than one part in a million. (in fact it's currently even better than that, but i'm saying 1:1000000 here because we could in the future consciously decrease precision, if performance or simplicity arguments justify it.)

I can understand his desire towards creating interest in his patch, but IMO it should not be done by unfairly (pun unintended ;) trash-talking other people's code. The math code in CFS that achieves precision has gone through more than 5 complete rewrites already in the 20-plus CFS versions, and the current variant was not written by me but was largely authored by Thomas Gleixner and Peter Zijlstra.

New, better approaches are possible of course and the math is relatively easy to replace, due to the internal modularity of CFS. So we are keeping an open mind towards further improvements. (which includes the possibility of total replacements as well. Dozens of times has my own kernel code been replaced with new, better implementations in the past - and that includes large parts of the scheduler too. In fact only ~30% of current kernel/sched.c was authored by me, the rest has been written by the other 90+ scheduler contributors, according to the git-annotate output that covers the past ~2.5 years of kernel history. Beyond that numerous other people have contributed to the scheduler in the past.)

About the submitted code: it was a bit hard to review it because the new code did not contain any comments - it only included raw code - which is very uncommon for patches of such type. The email gave the theoretical background but there was little implementational detail in the patch itself connecting the theory to practice.

So to drive this issue forward i have today posted a question to Roman in form of a tiny patch that extracts only his suggested new math from his patch and applies it to CFS. If it is indeed what Roman intended then we can analyze that in isolation and in more detail. The patch is as small as it gets:

include/linux/sched.h | 1 +

Oh my gosh, the Linux scheduler is on Slashdot. Again! :-)

Frankly, this amount of interest in the Linux scheduler is certainly flattering to all of us Linux scheduler hackers, but there are certainly more important areas that need improvement: 3D support, the MM / IO schedulers, stability, compatibility, etc. (There's also the FreeBSD scheduler that went through a total rewrite recently - and it got not a single Slashdot article that i remember.)

But i digress. A couple of quick high-level points (most of the details can be found in the discussions on lkml):

I find the RFS submission interesting and useful, and i have asked the author to split the patch up a bit better, to separate the core idea from optimizations and unrelated changes - to ease review and merging of the changes, and to make the changes bisectable during QA after they have been applied to the mainstream kernel. (That is how patches are typically submitted to the Linux-kernel mailing list - it's a basic requirement before anything can be merged. CFS for example was applied to the 2.6.23 development tree in form of a series of 50 (!) separate patches. (And the scheduler works at every patching/bisection point.))

I also pointed him to the latest "bleeding edge" scheduler tree, which already implements the same non-normalized form of math and makes some of the rounding and performance arguments moot i believe. (lkml mail).

There are some issues where i disagree with Roman at the moment: even when comparing to unmodified current upstream CFS, i think Roman makes too much out of rounding behavior and i have asked him to substantiate his claims with numbers (lkml mail).

The current precision/rounding of CFS is better than one part in a million. (in fact it's currently even better than that, but i'm saying 1:1000000 here because we could in the future consciously decrease precision, if performance or simplicity arguments justify it.)

I can understand his desire towards creating interest in his patch, but IMO it should not be done by unfairly (pun unintended ;) trash-talking other people's code. The math code in CFS that achieves precision has gone through more than 5 complete rewrites already in the 20-plus CFS versions, and the current variant was not written by me but was largely authored by Thomas Gleixner and Peter Zijlstra.

New, better approaches are possible of course and the math is relatively easy to replace, due to the internal modularity of CFS. So we are keeping an open mind towards further improvements. (which includes the possibility of total replacements as well. Dozens of times has my own kernel code been replaced with new, better implementations in the past - and that includes large parts of the scheduler too. In fact only ~30% of current kernel/sched.c was authored by me, the rest has been written by the other 90+ scheduler contributors, according to the git-annotate output that covers the past ~2.5 years of kernel history. Beyond that numerous other people have contributed to the scheduler in the past.)

About the submitted code: it was a bit hard to review it because the new code did not contain any comments - it only included raw code - which is very uncommon for patches of such type. The email gave the theoretical background but there was little implementational detail in the patch itself connecting the theory to practice.

So to drive this issue forward i have today posted a question to Roman in form of a tiny patch that extracts only his suggested new math from his patch and applies it to CFS. If it is indeed what Roman intended then we can analyze that in isolation and in more detail. The patch is as small as it gets:

include/linux/sched.h | 1 +

Oh my gosh, the Linux scheduler is on Slashdot. Again! :-)

Frankly, this amount of interest in the Linux scheduler is certainly flattering to all of us Linux scheduler hackers, but there are certainly more important areas that need improvement: 3D support, the MM / IO schedulers, stability, compatibility, etc. (There's also the FreeBSD scheduler that went through a total rewrite recently - and it got not a single Slashdot article that i remember.)

But i digress. A couple of quick high-level points (most of the details can be found in the discussions on lkml):

I find the RFS submission interesting and useful, and i have asked the author to split the patch up a bit better, to separate the core idea from optimizations and unrelated changes - to ease review and merging of the changes, and to make the changes bisectable during QA after they have been applied to the mainstream kernel. (That is how patches are typically submitted to the Linux-kernel mailing list - it's a basic requirement before anything can be merged. CFS for example was applied to the 2.6.23 development tree in form of a series of 50 (!) separate patches. (And the scheduler works at every patching/bisection point.))

I also pointed him to the latest "bleeding edge" scheduler tree, which already implements the same non-normalized form of math and makes some of the rounding and performance arguments moot i believe. (lkml mail).

There are some issues where i disagree with Roman at the moment: even when comparing to unmodified current upstream CFS, i think Roman makes too much out of rounding behavior and i have asked him to substantiate his claims with numbers (lkml mail).

The current precision/rounding of CFS is better than one part in a million. (in fact it's currently even better than that, but i'm saying 1:1000000 here because we could in the future consciously decrease precision, if performance or simplicity arguments justify it.)

I can understand his desire towards creating interest in his patch, but IMO it should not be done by unfairly (pun unintended ;) trash-talking other people's code. The math code in CFS that achieves precision has gone through more than 5 complete rewrites already in the 20-plus CFS versions, and the current variant was not written by me but was largely authored by Thomas Gleixner and Peter Zijlstra.

New, better approaches are possible of course and the math is relatively easy to replace, due to the internal modularity of CFS. So we are keeping an open mind towards further improvements. (which includes the possibility of total replacements as well. Dozens of times has my own kernel code been replaced with new, better implementations in the past - and that includes large parts of the scheduler too. In fact only ~30% of current kernel/sched.c was authored by me, the rest has been written by the other 90+ scheduler contributors, according to the git-annotate output that covers the past ~2.5 years of kernel history. Beyond that numerous other people have contributed to the scheduler in the past.)

About the submitted code: it was a bit hard to review it because the new code did not contain any comments - it only included raw code - which is very uncommon for patches of such type. The email gave the theoretical background but there was little implementational detail in the patch itself connecting the theory to practice.

So to drive this issue forward i have today posted a question to Roman in form of a tiny patch that extracts only his suggested new math from his patch and applies it to CFS. If it is indeed what Roman intended then we can analyze that in isolation and in more detail. The patch is as small as it gets:

include/linux/sched.h | 1 +

Here's a podcast (vodcast) of the press conference that explains the partnership in more detail. It's a little dry up until about 10:00 minutes (or 16:00 if you don't care about the genesis of ChaCha). https://oncourse.iu.edu/access/content/group/63494 4c1-c20e-4181-00bb-4a74f07be469/podcasts/IU%20and% 20Cha%20Cha%20Partnership%20Press%20Conference.m4v Enjoy!

IU's guides could be asked to locate a building on campus", (use a campus map)

"find a book in one of the university's libraries" (use a library web page)or

"solve a question about Windows Vista (use Microsoft s knowledge base)".

IU's guides could be asked to locate a building on campus", (use a campus map)

"find a book in one of the university's libraries" (use a library web page)or

"solve a question about Windows Vista (use Microsoft s knowledge base)".

We aren't "forced" to use it but we can download Office for "free" and Vista Business costs $15 and Ultimate cost something like $20 or $25 at the bookstore.

I'm certain that Microsoft doesn't give IU faculty and students such a discount purely out of love. I would be willing to bet that we pay for it in one way or another.

By the time most people graduate they have been getting MS products legally for free or very cheap for so long they haven't tried anything else and just automatically keep using MS products.

Last November, SFLC already said basically the same thing. Does anyone know what is really new here?

Look at this: http://www.uwsg.iu.edu/hypermail/linux/kernel/0612 .1/1219.html

This gives Mach-O file system support for linux and the xnu syscall support. Once this is finished it will enable you to execute mac os x programs on linux (but you need to provide a lot of stuff, like the complete libraries, dynamic linker and so on. But in theory it should work).

But be warned: AFAIK some of the nice mac os x apps are encrypted.

From: Ingo Molnar
Date: Sun Apr 15 2007 - 11:06:49 EST

i partially replied to that point to Will already, and i'd like to make
it clear again: yes, i rejected plugsched 2-3 years ago (which already
drifted away from wli's original codebase) and i would still reject it
today. ...

that's the extra complication i didnt like 3 years ago and which i still
dont like today. What the current plugsched code does is that it
simplifies the adding of new experimental schedulers, but it doesnt
really do what i wanted: to simplify the _scheduler itself_. Personally
i'm still not primarily interested in having a large selection of
schedulers, i'm mainly interested in a good and maintainable scheduler
that works for people.

so the rejection was on these grounds, and i still very much stand by
that position here and today: i didnt want to see the Linux scheduler
landscape balkanized and i saw no technological reasons for the
complication that external modularization brings.

The only serious objection Linus has is over TiVo-ization. He thinks it should be OK.
He says he is angry that FSF is claiming to protect freedom while taking away a certain freedom from companies like TiVo.

But the freedom that FSF is taking away is the freedom to take away freedom from users of the software. Thanks you Linus, great protector of ... wha??

But keep in mind the politics that Linus has to deal with. There are many developers who would have to sign off on GPLv3. One of the biggies is Greg Kroah Hartmann of Novel, who owns the USB subsystem. Novel no doubt takes GPLv3 personally. Greg has actively tried to discourage even the "or any later version" clause from being included in kernel patches.

On top of that, even if everyone wanted to go GPLv3, they would have to track down hundreds of developers. So it's just easier for Linus to say no to GPLv3 in any case.

Crap. It's late, I didn't preview. This mirror: Jun 8-15 / 07

Both are sincere in their beliefs. RMS is accused of being idealogical and hard to get along with, however it was perspective and tenacious that created free software and the GPL in the first place.

RMS is the original author of GPL, gcc, bash, glib, emacs and many other important tools. No "normal" person would have had the vision or determination to do what RMS has done. He originally intended to create the compiler, the runtime library, the editor (emacs) and to OS. Only a person that was a little bit "crazy" would have even attempted to do this. The Free software world and the "open source" world are greatly indebted to RMS, no matter how hard to get along with he is, or what people may think of him. The vary characteristics that some people dislike, are exactly the characteristics that made it possible for RMS to achieve what he achieved. Without RMS free software would be nowhere. The GPL was introduced from the start, as being with a certain idealogical intent, the intent of the GPLv3 is in the same spirit as this intent.

It may be this idealogical attitude, together with acceptance of a faulty academic idea called the microkernel, that caused RMS to fail in creating a workable kernel to work with his other software. The HURD is nowhere.

What is called GNU/Linux and sometimes just Linux, is a merger between Linus' kernel and RMS' free software, and much other software.

Linus attitude is pragmatic. He uses the GPL as a tool just has he uses gcc. He is a great programmer and kernel hacker. He had the wit to reject the academic idea of the Microkernel which if adopted could have killed Linux just has it did the Hurd. There is no better person to lead the Linux kernel project.

If the BSDI USL lawsuit had not delayed the BSD project there would have been no Linux. Linus would have joined one of the BSD projects as just another BSD hacker. One of the BSDs would have become the dominant free software OS.

I believe that if this had happened, Microsoft would have destroyed BSD's commercial chances using "embrace and extend". They would have created a BSD/Windows hybrid that would have duplicated BSD's API. This would have happened because BSD lacks the GPL's so called "viral clause" that prevents embrace and extend. The existence of this hybrid would have been used by Microsoft to prevent the suits from even considering a move to free software.

Linus lacks the vision that RMS has. This has caused him to make several blunders such as the Bitkeeper Debacle. However the discipline implicit in the GPLv2 will prevent him from making any fatal mistakes. Were Linus to attempt to go in any totally insane direction, his project will fork. He knows this vary well.

I have given several presentations to Austin Linux Group from this perspective.

Free software history

Lessons of Free Software History

Tanenbaum-Torvalds microkernel vs monolithic kernel Debate

That second paragraph should read:

The FSFtards continue to hammer the LKML with their propaganda, to little effect. (I wonder if their strategy is to distract the kernel developers so that Hurd (excuse me, GNU/Hurd) can catch up.)

I dropped a greater than. =) Why didn't anyone warn me not to eat cous cous directly over the keyboard?

That second paragraph should read:

The FSFtards continue to hammer the LKML with their propaganda, to little effect. (I wonder if their strategy is to distract the kernel developers so that Hurd (excuse me, GNU/Hurd) can catch up.)

I dropped a greater than. =) Why didn't anyone warn me not to eat cous cous directly over the keyboard?

You're doing a good job of voicing objections to the GPL v3, and I have nothing to really add. I just wanted you to know that, despite the piling on you're getting from the 'tards, most people that understand the issues agree with you. Don't let a very vocal minority shut you up by repeating the same stupidities over and over. They've got such an emotional stake in the FSF ideology that they cannot listen to reason. If you're not attacked outright, then you'll be given the condescending "you misunderstand".

The FSFtards with their propaganda, to little effect. (I wonder if their strategy is to distract the kernel developers so that Hurd (excuse me, GNU/Hurd) can catch up.)

Anyway, if you ever get stumped by a pro-GPL v3 argument, you can be sure it's already been addressed and destroyed on the LKML. Especially arguments that use an appeal to "the spirit of the GPL", the "spirit" being whatever RMS says it is at the moment.

You're doing a good job of voicing objections to the GPL v3, and I have nothing to really add. I just wanted you to know that, despite the piling on you're getting from the 'tards, most people that understand the issues agree with you. Don't let a very vocal minority shut you up by repeating the same stupidities over and over. They've got such an emotional stake in the FSF ideology that they cannot listen to reason. If you're not attacked outright, then you'll be given the condescending "you misunderstand".

The FSFtards with their propaganda, to little effect. (I wonder if their strategy is to distract the kernel developers so that Hurd (excuse me, GNU/Hurd) can catch up.)

Anyway, if you ever get stumped by a pro-GPL v3 argument, you can be sure it's already been addressed and destroyed on the LKML. Especially arguments that use an appeal to "the spirit of the GPL", the "spirit" being whatever RMS says it is at the moment.

Also, here's the cited paper.

This isn't that novel. It's very much like Randall Beer's insect work from a decade ago. It's hierarchical control using controllers built from control blocks the authors call "neurons". It's a pure reflex system, with no explicit prediction.

Also notice that it's a planar biped, constrained so that it can't fall sideways.

There's better locomotion and balance work going on in Japanese hobbyist robotics.

It's good that people are working on this stuff again. There was some impressive work in the 1980s and early 1990s, then a big lull.

I don't believe that taking this course is going to make any person a greater danger to themselves or anyone else. Going by various news reports and research, there are plenty ways of injuring yourself without resorting to industrial explosives:

There was a kid who blinded himself after messing about with a frog and a potato gun with his friends

And there are 9000 injuries due to fireworks each year.

OK, I'm not totally right, but I'm not completely wrong. http://kb.iu.edu/data/ahwe.html

Mirror here http://www.ussg.iu.edu/hypermail/linux/kernel/0706 .1/1722.html

Mirror here http://www.ussg.iu.edu/hypermail/linux/kernel/0706 .1/1722.html

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =6402758

http://www.uwsg.iu.edu/hypermail/linux/net/0205.3/ 0002.html

http://lists.ntp.isc.org/pipermail/questions/2007- April/013854.html

etc...

The problem often is in the OS itself, but sometimes the applications and drivers are the problem. So why is this news? Well, judge by yourself.

That's 4Gbps AVERAGE, meaning it's much below the peak rate. That's also the raw data stream, not accounting for site X in the US wanting to read reconstructed data from site Y in Europe.

LHC-related experiments will eventually have 70 Gbps of private fibers across the atlantic (Most NY -> Geneva, but at least 10Gbps NY -> Amsterdam), and at least 10 Gbps across the Pacific.

For what it's worth, here's the current transfer rates for one LHC experiment You'll notice that there's one site, Nebraska (my site), which averages 3.2 Gbps over the last day. That's a Tier 2 site - meaning it won't even recieve the raw data, just reconstructed data.

Our peak is designed to be 200TB / week (2.6Gbps averaged over a whole week). That's one site out of 30 Tier 2 sites and 7 Tier 1 sites (each Tier 1 should be about 4-times as big as a Tier 2).

Of course, the network backbone work has been progressing for years. It's to the point where Abilene, the current I2 network, rarely is at 50% capacity.

The network part is easy; it's a function of buying the right equipment and hiring smart people. The extremely hard part is putting disk servers in place that can handle the load. When we went from OC-12 (622 Mbps) to OC-192 (~10Gbps), we had RAIDs crash because we wrote at 2Gbps on some servers for days at a time. Try building up such a system without the budget to buy high-end Fiber Channel equipment too!

And yes, I am on a development team that works to provide data transfer services for the CMS experiment.

http://kb.iu.edu/data/aibq.html

We're a Cisco shop but are seriously looking into Juniper due to some negative service impacting experiences. Juniper, especially M series, look like it was designed very intelligently from the ground up with superior hardware architecture with separation of routing engine/packet forwarding/control plane, much more powerful CLI/config error checking/timed roll-back, wire rate granular filtering, one train of code to follow and so on. Unlike Cisco 6500/7600 Sup720-3B/3BXL with hardware limitation of 256K and 512K IPv4 routes respectively, even Juniper's older M20 platform has been tested with upwards of 1 million routes. As for stability, Juniper is found in the core of most service providers, government, academia and research (Internet2 high speed network http://www.abilene.iu.edu./ I see Juniper as the Unix of routers and Cisco the Windows of routers. If you desire stability, security, performance and flexibility go Juniper. Cisco still has a place such as in enterprises that still run legacy IPX.

Thanks for the interesting link! Unfortunately, their work was entirely done on a now obsolete version of the kernel (2.4.18) and a request for comment on porting it to the 2.6 series was ignored by the hackers on LKML. A little more digging found the probable reason: the system has a number of problems. In particular, this paper by Peter Chubb from the University of New South Wales (pdf) outlined some of the issues (pp 2-3, emphasis added):

The Nooks work [Swift et al., 2002] showed that by isolating drivers from the kernel address space, the most common programming errors could be made recoverable. In Nooks, drivers are insulated from the rest of the kernel by running each in a separate address space, and replacing the driver/kernel interface with a new one that uses cross-domain procedure calls to replace any procedure calls in the ABI, and that creates shadow copies of any shared variables in the protected address space.

This approach provides isolation, but also has problems: as the driver model changes, there is quite a lot of wrapper code that has to be changed to accommodate the changed APIs. Also, the value of any shared variable is frozen for the duration of a driver ABI call. The Nooks work is uniprocessor only; locking issues therefore have not yet been addressed.

That obviously is a bit of a show-stopper, as SMP and hyperthreaded systems are becoming more and more common in practice; it's not clear how complex extending the Nooks system would be. But the paper I linked actually suggests that for most drivers, there's no need to have them in kernel space at all: with a little bit of work, it seems that "almost any PCI bus-mastering device could have a user mode device driver." (ibid)

It's an interesting read, if you have a moment I recommend you take a look.

I still think using a microkernel would be best, and the L4 people have shown that a properly implemented microkernel can be nearly as fast as a macrokernel -- turns out (surprise surprise) that it's Mach that's given the microkernel a bad name. But the complexity issue remains daunting, and that (along with an unreasonable political attachment to Mach) has kept the L4-Hurd project from really getting off the ground. It's a shame.

There's a couple reasons for it not being in the kernel. First, it misleads users who expect some degree of data security. The good news is that sort of person likely follows kernel patches to the FS and would likely be aware of the problem, possibly even writing a script that replaces rm with a real-rm.

The second argument is that it's better handled in user space, so the OS doesn't have to make that sort of policy. There's no reason you can't just alias rm to some .Trash, or configure your Desktop Environment to do so (GNOME does, for example). There's all sorts of things you have to decide that might not suit everyone. For example, if I delete a file on a USB drive, does it go in a .Trash storage in the USB drive, or do we copy it over to a main .Trash folder? Many people don't realize they have to empty the trash to reclaim space on their thumbdrive in GNOME.

The final argument I can come up with is security problems. We can't have one global .Trash bin in a multiuser system. And quotas. And permissions.

Reading historic archives of the LKML suggests it's at least come up once. I guess Torvald's opinion is that anything that CAN go in the userspace SHOULD. Can't explain the webserver in kernel though. Perhaps that opinion has changed some time in the last 10 years?

Here is a quick mirror: (ftp also works) http://ftp.ussg.indiana.edu/linux/ubuntu-releases/ 7.04/ maintained by http://www.ussg.iu.edu

Go ahead, take our bandwidth :)

A few years back I registered apfbiolectronics.com (APril fools bioelectronics. Made up a name and had a friend design a website about affordable medical devices for the masses

I took an arm crash dump at random from google and then posted a complaint to linux-kernel and linux-arm about how linux crashed and killed my test monkey and could they hurry up and fix it so we could move on with human trials.

• 2 offers for help
• 1 plea to scrap the project immediately in the name of all things good in this world (man I wish I still had that email).
• A thread debating the validity of my post
• Someone telling me that he hopes I used a scratch monkey
• Someone used my post to back up his bug report
• 12 days later someone posted a report on their lug's mailing list.
• Two YEARS later someone referenced it on the linux advocacy newsgroup

The sad thing is I'm never ever going to top that prank

In scientific code FORTRAN tends to be 20% faster than the best possible C++ implementation because the grammar is so simple that compilers tend to understand better the code and can vectorize or optimize it much farther than C ;

Apparently, this is not true anymore. Most scientists are writing their codes in C++ nowadays because expression templates remove the performance penalty associated with the abstraction of manipulating N dimensional matrices. (And I'm guessing that expression templates are making up for the optimization deficitances of modern compilers...) See http://osl.iu.edu/~tveldhui/papers/techniques/ for a good explaination. See http://www.oonumerics.org/blitz/benchmarks/ for some benchmarks for blitz++ vs. F77. Blitz is actually not so cutting edge anymore. There maybe better packages out there now too. Also, with the new autovectorization technologies, these comparsions might be wrong too.

Cheers
Ben

http://www.ussg.iu.edu/hypermail/linux/kernel/0312 .2/1241.html

From: Linus Torvalds
Date: Mon Dec 22 2003 - 16:36:47 EST
[snip]
"errno.h/signal.h/ioctl.h (and they are apparently the 2.4.x versions, before we moved some common constants into "asm-generic/errno.h"), and while I haven't analyzed them, I know for a fact that
- the original errno.h used different error numbers than "original UNIX"
I know this because I cursed it later when it meant that doing things like binary emulation wasn't as trivial - you had to translate the error numbers.
- same goes for "signal.h": while a lot of the standard signals are well documented (ie "SIGKILL is 9"), historically we had lots of confusion (ie I think "real UNIX" has SIGBUS at 10, while Linux didn't originally have any SIGBUS at all, and later put it at 7 which was originally SIGUNUSED.

So to me it looks like
- yes, Linux obviously has the same signal names and error number names that UNIX has (so the files certainly have a lot of the same identifiers)
- but equally clearly they weren't copied from any "real UNIX"."
[snip]

http://www.ussg.iu.edu/hypermail/linux/kernel/0305 .0/0855.html

Not that I've actually done it.

It appears potatoes are also bad for kernel developers.

I happen to agree that there are valid scenarios for Trusted Computing but disempowering the user is not among them. This is an imposition of Vista and not a consequence of buying a DVD.

You know, this really needs to be addressed. It's been bothering me just how many people on /. are so misinformed about optical drive speeds. Comparing a "12x" DVD drive to a "2x" Blu-Ray drive is misleading as the uninformed will assume that the former is much faster than the latter. Let's put this into perspective:

A single speed (1x) DVD drive is rated at approximately 1.35 MB/second. That means that a 12x drive will theoretically reach approximately 16.2 MB/second maximum transfer rates.

A single speed Blu-Ray drive is rated at approximately 4.5 MB/second. That means a 2x drive will theoretically reach approximately 9 MB/second sustained transfer rates.

This means that a 2x Blu-Ray drive is equivalent in speed to an 8x DVD-ROM drive. Hardly a performance slouch, and if you also factor in the difference between maximum and sustained transfer rates, the performance is really on par with a 12x DVD drive.

For reference:
http://en.wikipedia.org/wiki/Blu-ray_Disc
http://kb.iu.edu/data/adme.html
http://www.answers.com/topic/dvd-drives (keep in mind, they list drives faster than 12x for DVD, which currently is not possible)

This is not isolated to porn (duh). When a prosecutor has it out for you, there isn't much that can be done. Often there is a willingness to make an example for others, or to appear tough on a specific kind of crime for political benefit.

Chris Soghoian knows what I mean. It has nothing to do with evidence - all that matters is the nature of the charges. The Duke lacrosse team knows too.

IU http://iuware.iu.edu/
I'm sure that in some way our fees pay for it. We can also buy XP Pro for $15 (Or is it $10? I can't remember).

While it is nice, it is also a nice way for Microsoft to get lots of undergrads brainwashed into using their products without thinking about alternatives.

The FBI raided Soghoian's Bloomington apartment and seized computers, equipment and papers Oct. 28, a day after Rep. Edward Markey, D-Mass., called for him to be arrested for creating a Web site that let people create fake airline boarding passes. Markey later withdrew the request.