Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment still an income, not a wealth tax (Score 5, Insightful) 2115

Note that this is still an income tax -- not a wealth tax. Those who are already wealthy can and will always game this such that they report little income, thereby preserving their wealth. If necessary, they'll just keep their money offshore.

If he had any sense, he'd offer an amnesty to the wealthy. Allow them to repatriate their funds from overseas at a reduced tax rate so that money comes back to the US. The money the treasury makes on that smaller percentage would still be more than the zero they get from it today.

Comment Re:It's actually very simple (Score 1) 368

Sure, but will that fact come out in the patent examination? Or will the person with the unpatented prior art be subject to lawsuits from Mr. First-to-file? I'm not a patent attorney, so I think this is a legitimate question...

For instance, suppose I "invent" an algorithm in some software I write. I use that algorithm but consider it obvious or just don't bother to patent it. Then, a year later someone else independently "invents" the same algorithm and decides to patent it. That person then discovers my use of it and sues. Am I likely to have to pay patent royalties since I neglected to file a patent when I originally invented it?

Comment Re:It's actually very simple (Score 1) 368

On the flip side...

What often happens is that someone "invents" something and doesn't bother to patent it because it's obvious. Then someone comes along later and does file a patent for the invention, turns around and sues the person who originally invented it. First-to-file now means that if you don't recognize something as an "invention" and patent it when you come up with the idea, you can get screwed later.

Comment Re:Question: (Score 4, Interesting) 101

There are also other concerns than the context switch overhead...particularly when dealing with filesystems or data storage devices.

For instance, suppose part of your userspace daemon gets swapped out, and you now need to upcall to userspace. That part that got paged out then has to be paged back in. If memory is tight, then the kernel may have to free some memory, and it may decide to flush out dirty data to the filesystem or device that is dependent on the userspace daemon. At that point, you're effectively deadlocked.

Most of those sorts of problems can be overcome with careful coding and making sure the important parts of the daemon are mlocked, but you do have to be careful and it's not always straightforward to do that.

Comment Re:Fixes? (Score 1) 228

I assume you're talking about client-side performance? If so, then yes it should be much better in RHEL6.

FWIW, The NFS tools don't really do much once you've got the filesystem mounted. (Ok, that's not 100% true with NFSv4 or Kerberized NFS but it is for the most part). Performance problems like this are generally in the kernel. I've got a patchset queued up to try and improve NFS write performance in RHEL5, but it probably won't go in until 5.7.

See this page if you want to test out what I have queued up so far. It's still pretty rough, but the results so far are quite promising:

        http://people.redhat.com/jlayton/

If you have a support contract, you should open a support case on this. Typically, performance problems are all about numbers so if you can quantify the problems you're seeing then we should be able to help.

Slashdot Top Deals

Real Users are afraid they'll break the machine -- but they're never afraid to break your face.

Working...