Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:Derp. (Score 1) 669

I could have wasted my time and started by quoting article 42, of the 1907 Hague conversion (comments mine):
"Territory [Who's territory?] is considered occupied [from?] when it is actually placed under the authority of the hostile army [hostile to whom?]", pointing out that:
1. Israel has a peace agreement with Egypt which does not claim sovereignty over Gaza.
2. Israel has a peace agreement Jordan which does not claim sovereignty over the West-Bank.
3. There was never a Palestinian state in said territories. (Hence the "whom" part)
4. Hence, by all account Israel is legally free to continue holding these lands (at least until Egypt or Jordan change their position).

I could also point out that most of the Palestinian population is already living under Palestinian rule (be that the PA in the West bank or the Hamas militia group in Gaza) and has been doing so since the 1992-1995 Oslo peace agreement(s), which more or less negate the "oppression" argument (If anything, by all accounts the Hamas militia is currently violently oppressing the Palestinian populous under its rule - but somehow I don't see you demonstrating against them [Come to think about it, go to Gaza and demonstrate against Hamas' disregard for basic human rights, I'll bring pop-corn, it should be fun to watch).

I could further point out that each time we tried to redraw completely from so called Palestinian territories, we were met by a suicide bombers and rocket attacks against restaurants, buses, hospital and urban centres. (E.g. In December alone [!!!] more than 40 rockets and mortar shells were fired from the Hamas held Gaza strip on Israeli civilian towns and villages surrounding the Gaza strip)

I could end by pointing out that the only thing keeping the PA alive, preventing the Hamas from taking over the west-bank by force (much like they did in t

Comment Re:Derp. (Score 1) 669

... At least you didn't put us as genocidal maniacs, or were you?
In the current atmosphere of "Israel is to be blamed for GW, Al-Qaeda, world hunger and, well, Opera", I could actually consider your post fairly-balanced.

So, just before I go about my business (which apparently includes slaughtering baby seals, burning their corpses in an effort to release additional CO2 to the atmosphere), care to explain in what exactly we did this time?

- Gilboa

Comment Re:Mugabe (Score 1) 669

"India's shift was very violent as well, Israel's was the same"

Care to elaborate?
AFAIR, we chose Democracy by-more-or-less default. (Almost ended up a pseudo-socialist-Democracy, but that's another story)

- Gilboa

Comment Re:Linux already runs on thousands of cores (Score 1) 462

Pressed send too early (3am here).
My example goes to show that one must not threat the Linux kernel (or any other kernel for that matter) as a single entity that "needs redesign".
The code paths that we used might have been huge-SMP safe, but it's very likely that other parts of the kernel might not be.
When talking about redesign, one should be specific: Are they talking about the memory management? network stack? driver layer? workqueues? scheduler? IRQ handling? etc, etc, etc.

- Gilboa

Comment Re:Linux already runs on thousands of cores (Score 1) 462

The linked article doesn't really explain what was simulated and how. (At least not in depth, unless I missed something).

However, I cannot disagree more.
In one of my previous projects we developed a kernel based traffic monitoring software that was originally designed when top of the lines servers (such as the HP DL-585G1) had 4-socket, single core CPUs (A total of 4 cores).
The same software scaled -linearly- (*) when 4 socket, 12 cores (AMD Opteron) and 8 core / 16 thread (Xeon EX) CPUs were released. (A total of 48 cores on AMD Opteron machines and 32 cores / 64 threads on Xeon EX machines)

Now, if the Linux kernel (at least the short code paths that we used) had severe problems with scaling above, say, 48 cores, a 64 core Xeon EX performance would have scaled poorly compared to 48 core AMD Opteron machine, let alone a 24 cores Xeon EP (dual socket), but our experience seems to suggest otherwise.

- Gilboa

* Actually, we saw better-than-linear scaling, but this can be attributed to the huge L2/L3 caches in modern CPUs.

Comment Re:But... but... (Score 1) 323

Why someone voted your post as insightful is beyond me.
Vocal idiots sit on both ends of GW debate: From the "think about the children" idiots on one end, to "The UN black helicopters will take over the old" idiots on the other.

Your assumption that people who watch Fox (most likely due to them being right-conservative as opposed to the left-liberal main media) automatically makes them idiots, puts you smack in the middle of the "think about the children" camp.

- Gilboa

Comment Re:Overheating means waste of energy (Score 1) 79

*Sigh*

Lets assume, for a second, that I have a system that scales linearly from 12 to 48 cores (2S Xeon 56xx/Opteron 2xxx to 4S Opteron 6xxx) and requires ~4GB per core. (48-192GB)
Now, lets assume that I'm willing to switch to ARM.
1. I will need a board that with at-least 24-96 soon-to-be-released ARM 2.0 Ghz Coretex A9 dual core core CPUs.
2. This board will also need unbelievably wide (and extremely complicated) crossbar, as I can no longer simply put 4 independent buses (one per CPU) and simply connect the sockets via a high-speed inter-CPU bus as AMD and Intel currently do.
3. Let alone the fact that this board will also require huge amounts of L3 cache / snoop-cache, as the built-in per-CPU cache will have a horrible cache hit/miss ratio.
4. ... And this of-course, assuming the ARM can:
    a. Address more than 64GB RAM. (As I recall, ARM was limited to 36bit)
    b. Capable of working on MP configuration.
5. Lets assume that someone actually managed to solve all of the above, this doesn't solve one issue: This machine will have abysmal single thread performance. Even if my application scales nicely into 96 threads (and most applications don't), I will still have code-paths that will be core-speed dependent; and these code-paths will be dog slow on this machine.

In short, currently ARM doesn't come even close to replacing a cheap 2S Xeon/Opteron servers, let alone a super-high-end 4S/8S server.

- Gilboa

Comment Re:Showing its age (Score 2, Interesting) 148

(I use CentOS on development machines, RHEL for production)

1. Releases: Please compare the release date of say, RHEL 4.8 (19/5/09) to CentOS 4.8 (21/8/09).
Or better yet, compare RHEL 5.5 (30/3/10) to CentOS 5.5 (will be ready when its ready).
Now, CentOS devs tend to follow RedHat security updates fairly closely, and I usually see the CentOS updates ~12-48h after their RHEL parents.
However: A. In production environment, I rather not wait 12-48h. B. Given the complexity of major updates (E.g. RHEL 5.5), CentOS tends to lag RedHat by a considerable margin.

2. Support: We once had a RHEL kernel fix, specifically tailored to our issue, within 24h. CentOS devs simply cannot compete with RedHat. Period.

Make no mistakes, I bow before the CentOS devs for maintaining a great distribution, but when my job is on the line, I rather put RHEL. Period.
Nobody gets fired for using RHEL.

- Gilboa

Comment Re:And yet,... (Score 1) 254

I can't vouch for other manufacturers, but I've got a number of Gigabyte GA-M55S-S3 and GA-M56S-S3 boards that came with single core Athlon64's or low-end Athlon64X2's.
Most of the GA-M55S-S3's have been upgraded to high-end Athlon64 X2's (AM2) or 95w Phenom X4 CPUs (AM2+, Agena core).
The somewhat younger GA-M56S-S3's are far more capable (latest BIOS added AM3 support), I plan to upgrade all of them to Phenom II X4 CPUs (AM2+ or AM3 Deneb), or better yet, if Gigabyte continues to release new BIOS' for these old boards (Some of them are close to 3 year old!), I may even upgrade one or two of them to Phenom II X6 CPUs.

- Gilboa

Comment Re:Why don't they try fixing Fedora 11 first? (Score 1) 236

"How many times have you been able to do a 'yum update' or 'preupgrade' without having to worry about whether the system will be able to boot correctly?"

Around 99.9% of the time.

"How many times has anaconda crashed mid-install"

Aside from a known bug [1] (a well documented common bug), zero (or at least as far as I remember). And I've been using Fedora since F2 on machines ranging from PII/366 laptop to 24 core monsters.

"...or failed to detect your RAID and decided instead to wipe individual drives without really telling you, or any number of other nagging problems?"

0.
Granted, I may not be as "successful" as you are- as I only manage ~20 different Fedora machines (as a side job) - but who am I to argue with your well documented arguments... (You forgot about RPM-hell. If you're taking the time to spread FUD, at least do it right!)

- Gilboa
[1] https://bugzilla.redhat.com/show_bug.cgi?id=501057

Slashdot Top Deals

Building translators is good clean fun. -- T. Cheatham

Working...