> The only reason to go with anything else would be licensing costs, not functionality-wise.
that's far from being true. i suggest that you read up (sorry, no links, as i got it from a presentation by OLPC security guy) about *purely technological* challenges the OLPC project had and, first of all, admire their work, and then appreciate the fact that there's *no way in HELL* they could pull that off with off-the-shelf OS, even embedded. in some places, such as power management, they literally had to pull the guts out of linux and put their stuff back in (of course, many patches are flowing upstream, but some work is simply too specific to the hardware). for example, this machine actually goes to deep sleep every several SECONDS, if there's no activity, and display refresh goes down to 0 hz. the wakeup time has to be on the order of a hundred milliseconds max, or the user experience will be degraded. now, if you ever had your traditional laptop go to sleep and wake up, you know that the time it takes to do so is measured in seconds at best, if not minutes. OLPC developers had to toss out the existing ACPI sleep system and write their own, complete, with kernel support. result? huge power savings and they almost made to under 100 ms of wakeup time. now, you go to microsoft and say "hey, we're this charity organization, developing laptops for children, and we have this problem with acpi. could you please rewrite your OS power management for us? kthx." then there's mesh computing - the mesh is running even when the cpu is asleep and uses unique protocols to self-organize. the lust goes on, and on, and on. having Linux to start with has been a huge win for these guys.
Quoting Deb Goodkin of FreeBSD Foundation (from here):
We spent close to $35,000 for this release. It is hard to estimate the future costs of maintaining the Java releases since we expect to build updated distributions in response to all security advisories released by Sun.
So, while the license itself might have been given gratis, this clearly shows that the process of obtaining it was cumbersome and costly, and the result is still a limited, version-dependent, binary-only distribution.
Yes, Java is still evil. Changing license for something more liberal would certainly help much with adoption here.
there is a connection between pirates and global warming.
Re:5.4 amd64 is seriously broken thread-wise
on
FreeBSD 5.4 Review
·
· Score: 3, Interesting
yes, technically EM64T is the equivalent of x86-64. it might not be as microarchitecturally efficient, but it is 100% compatible (as far as i know).
hm... what you mean by referencing sources? i had the behavior i described (syscalls burst then panic) repeatedly, which was corrected by rebuilding-reinstalling the i386 world and kernel. no problems since then.
Apache (2.0.54) wasn't even doing any heavy-duty php/perl, just static content, SSI and some proxying. alongside apache there's a lightweight httpd serving exclusively static content ( called nginx. it's not threaded, but rather based on kqueue and is extremely efficient). the box was underloaded most of the time, cpu usage not exceeding 25%. those massive amounts of syscalls must originate from somewhere in the libpthread, though i haven't had time to investigate - it tended to happen in peak daytime hours and i needed to put the server back up asap.
Re:5.4 amd64 is seriously broken thread-wise
on
FreeBSD 5.4 Review
·
· Score: 1
that same Apapche 2.0 is running happily on that same box withe the same configuration, only recompiled for i386. i had 2 or 3 occasional panics since then, but i suspect these were due to previous filesystem corruption.
5.4 amd64 is seriously broken thread-wise
on
FreeBSD 5.4 Review
·
· Score: 4, Informative
the box couldn't run Apache 2.0 (worker MPM) compiled with libpthread for a single day without a panic! at some point apache child starts boimbarding kernel with syscalls (500k syscalls/second), soon, if left unattended, the box panics. had to get back to i386 for stability.
this is all on common hardware - Intel (EM64T) Xeons, Pro/1000 (em) network. and mind you, we still use SCHED_4BSD.
conclusion? 5.x is by NO means -STABLE on amd64 yet.
basically, with current signaling levels frequencies, etc. it has becoime increasingly hard to get many memory slots wired to the same controller. i think it maxes out at 8 slots/controller for current DDR designs (i see this in intel E75XX 2 socket design, though i'm not sure they all share the same wire so it might be less actually). so basically, 4-6 slots for 1-socket mobo is the most you can expect. for more you will have to get mb with more sockets/memory controllers. and yes, for amd you will have actually to put CPUs in to utilize those slots.
my recommendation would be one of current intel E75xx-serias mobos, where you get many (8) dimms and don't have to put in the 2nd cpu to use them. to reach 64 gbytes you'll definitely have yto use some specialized hardware, most likely not x86.
Slashdot Mirror
> They are worried that Linus warming will contribute to global average temperature rise.
:)
oh noes! think of the penguins!
> The only reason to go with anything else would be licensing costs, not functionality-wise.
that's far from being true. i suggest that you read up (sorry, no links, as i got it from a presentation by OLPC security guy) about *purely technological* challenges the OLPC project had and, first of all, admire their work, and then appreciate the fact that there's *no way in HELL* they could pull that off with off-the-shelf OS, even embedded.
in some places, such as power management, they literally had to pull the guts out of linux and put their stuff back in (of course, many patches are flowing upstream, but some work is simply too specific to the hardware).
for example, this machine actually goes to deep sleep every several SECONDS, if there's no activity, and display refresh goes down to 0 hz. the wakeup time has to be on the order of a hundred milliseconds max, or the user experience will be degraded. now, if you ever had your traditional laptop go to sleep and wake up, you know that the time it takes to do so is measured in seconds at best, if not minutes. OLPC developers had to toss out the existing ACPI sleep system and write their own, complete, with kernel support. result? huge power savings and they almost made to under 100 ms of wakeup time. now, you go to microsoft and say "hey, we're this charity organization, developing laptops for children, and we have this problem with acpi. could you please rewrite your OS power management for us? kthx."
then there's mesh computing - the mesh is running even when the cpu is asleep and uses unique protocols to self-organize. the lust goes on, and on, and on. having Linux to start with has been a huge win for these guys.
Quoting Deb Goodkin of FreeBSD Foundation (from here):
We spent close to $35,000 for this release. It is hard to estimate the future costs of maintaining the Java releases since we expect to build updated distributions in response to all security advisories released by Sun.
So, while the license itself might have been given gratis, this clearly shows that the process of obtaining it was cumbersome and costly, and the result is still a limited, version-dependent, binary-only distribution.
Yes, Java is still evil. Changing license for something more liberal would certainly help much with adoption here.
there is a connection between pirates and global warming.
yes, technically EM64T is the equivalent of x86-64.
it might not be as microarchitecturally efficient, but it is 100% compatible (as far as i know).
hm... what you mean by referencing sources?
i had the behavior i described (syscalls burst then panic) repeatedly, which was corrected by rebuilding-reinstalling the i386 world and kernel.
no problems since then.
Apache (2.0.54) wasn't even doing any heavy-duty php/perl, just static content, SSI and some proxying.
alongside apache there's a lightweight httpd serving exclusively static content ( called nginx. it's not threaded, but rather based on kqueue and is extremely efficient).
the box was underloaded most of the time, cpu usage not exceeding 25%.
those massive amounts of syscalls must originate from somewhere in the libpthread, though i haven't had time to investigate - it tended to happen in peak daytime hours and i needed to put the server back up asap.
that same Apapche 2.0 is running happily on that same box withe the same configuration, only recompiled for i386.
i had 2 or 3 occasional panics since then, but i suspect these were due to previous filesystem corruption.
the box couldn't run Apache 2.0 (worker MPM) compiled with libpthread for a single day without a panic!
at some point apache child starts boimbarding kernel with syscalls (500k syscalls/second), soon, if left unattended, the box panics.
had to get back to i386 for stability.
this is all on common hardware - Intel (EM64T) Xeons, Pro/1000 (em) network. and mind you, we still use SCHED_4BSD.
conclusion? 5.x is by NO means -STABLE on amd64 yet.
basically, with current signaling levels frequencies, etc. it has becoime increasingly hard to get many memory slots wired to the same controller.
i think it maxes out at 8 slots/controller for current DDR designs (i see this in intel E75XX 2 socket design, though i'm not sure they all share the same wire so it might be less actually).
so basically, 4-6 slots for 1-socket mobo is the most you can expect. for more you will have to get mb with more sockets/memory controllers. and yes, for amd you will have actually to put CPUs in to utilize those slots.
my recommendation would be one of current intel E75xx-serias mobos, where you get many (8) dimms and don't have to put in the 2nd cpu to use them.
to reach 64 gbytes you'll definitely have yto use some specialized hardware, most likely not x86.
the question is...why does it have to be secret in the first place?