Re:This is a huge amount of work
on
Linux 2.6.27 Out
·
· Score: 1
The Linux kernel developers deliberately refuse to have a "stable" API for virtually anything except system calls, so that they can continually improve the kernel architecture. VMware has to keep up with the kernel APIs to fit modules in, since they have not submitted their modules for inclusion in Linux itself. And even then, modules for an SMP build will not work on a UP build, and so on... so they must be tailored to your kernel. The easiest way is to compile on the spot.
Enterprise-class server hardware tends to be built to last longer, and is maintained and monitored constantly to ensure it's still working within acceptable bounds. And if it's not, it can be field serviced for much less than the cost of upgrading a distro version.
I hate it when that happens. A helpful popup told me I ran out of CPU cycles just a few days ago, and I had to order a whole bunch online. Cost thousands! Still waiting for them to arrive.
I have an old Dell Latitude C800 with its docking unit (2 PCI gigabit network cards:D) as my central server for similar purposes, plus a VPN concentrator and J2EE application server. It runs between 6 and 10 watts and has about 6 hours of battery life. Runs Debian Etch, will run Debian Lenny when that's done. Best core network device ever.
I may not be an Ivory Tower 158er, but I recognize that anything that's bad for the global economy is bad for me. No man is an island. With globalisation, no island is an island.
The whole point of a EULA is to be something a user has to accept before they use the software, so that it has a chance of being enforceable if they then violate that EULA.
From my experience programming properly threaded daemons on Linux and Windows, a head start in development on Windows can't even begin to make up for the extremely broken APIs available there. Even condition variables have to be hacked together, since Windows doesn't support the POSIX threading standards.
Funny enough, GCC has become orders of magnitude slower at compiling because it now supports much more sophisticated optimisations. Hardware has moved forward faster than GCC though, so they're well in the green.
Thread-local storage has been in almost every modern Unix for a long time, including Linux. That is not the problem. Page protection is a hard problem but Xen virtualisation has shown it can be done on many layers, so perhaps it can be done between threads as well. Just don't hold your breath.
Wow, you're several years behind. Psyco was just a JIT module for Python and it's dead as a doorknob, doesn't even run on x86_64. Psyco's developer is working on similar optimizations as part of work on PyPy, which *is* a modern and vibrant project.
Maybe I'm giving Microsoft developers too much credit, but having developed almost all of the Windows APIs themselves, as a whole they should generally know how to use them as well. Windows doesn't have anything nearly as elegant as kqueue, but even IOCP works well enough that you wouldn't be throwing in more threads instead.
That said, I can't find a sane reason that you'd need so many threads just for a browser. For pure CPU-bound throughput you're best off having the same number of threads as cores, which gives you minimal overhead with as much parallelism as you'll get out of the hardware. You can add IO-bound threads on top specifically to get that bottleneck out of the way of CPU bound threads. I highly doubt IE8 has 113 IO-bound threads on top of its 4 (or whatever) CPU-bound threads.
If it was that simple, you'd just use + as your hash function. No.
The minutes are well-known so that is already a lot of entropy you're giving the attacker for free. They don't know the string, but if they intercept the hash, they can work it out almost trivially because of how broken MD5 is. At least using HMAC and SHA256 (or better) will insulate the key from hash reversal.
Slashdot Mirror
The Linux kernel developers deliberately refuse to have a "stable" API for virtually anything except system calls, so that they can continually improve the kernel architecture. VMware has to keep up with the kernel APIs to fit modules in, since they have not submitted their modules for inclusion in Linux itself. And even then, modules for an SMP build will not work on a UP build, and so on... so they must be tailored to your kernel. The easiest way is to compile on the spot.
Enterprise-class server hardware tends to be built to last longer, and is maintained and monitored constantly to ensure it's still working within acceptable bounds. And if it's not, it can be field serviced for much less than the cost of upgrading a distro version.
If you can't map functional concepts on to a procedural language, what good are you as a programmer?
Argh. Markov Chain text garbage got modded Insightful.
It's simply called 'sleep' ... rather than ... sleep
Did you mean Suspend?
It's the same in Russian. I know it from Russian so I posted about the Russian.
Transliterated back into Russian, Rybka means Fish. Maybe I don't know the joke, but I've never known fish to be particularly strong chess players.
Let's see it survive a Linux LiveCD.
I hate it when that happens. A helpful popup told me I ran out of CPU cycles just a few days ago, and I had to order a whole bunch online. Cost thousands! Still waiting for them to arrive.
I have an old Dell Latitude C800 with its docking unit (2 PCI gigabit network cards :D) as my central server for similar purposes, plus a VPN concentrator and J2EE application server. It runs between 6 and 10 watts and has about 6 hours of battery life. Runs Debian Etch, will run Debian Lenny when that's done. Best core network device ever.
Yes! We will call it... Upstart! Oh wait.
What's even funnier is the reality that Windows can't even boot on that many CPUs, let alone scale to utilise them.
I may not be an Ivory Tower 158er, but I recognize that anything that's bad for the global economy is bad for me. No man is an island. With globalisation, no island is an island.
Yes, because a few million Mac desktops vastly outnumbers hundreds of millions of Linux embedded devices, servers, desktops and virtual appliances.
The whole point of a EULA is to be something a user has to accept before they use the software, so that it has a chance of being enforceable if they then violate that EULA.
Who needs WinRAR when you have 7-Zip?
From my experience programming properly threaded daemons on Linux and Windows, a head start in development on Windows can't even begin to make up for the extremely broken APIs available there. Even condition variables have to be hacked together, since Windows doesn't support the POSIX threading standards.
Funny enough, GCC has become orders of magnitude slower at compiling because it now supports much more sophisticated optimisations. Hardware has moved forward faster than GCC though, so they're well in the green.
Don't forget to make Debian packages as well, since a lot of people who would use Ubuntu for distributed storage may prefer the stability of Debian.
Thread-local storage has been in almost every modern Unix for a long time, including Linux. That is not the problem. Page protection is a hard problem but Xen virtualisation has shown it can be done on many layers, so perhaps it can be done between threads as well. Just don't hold your breath.
http://en.wikipedia.org/wiki/Circadian_rhythm#The_myth_of_the_25-hour_day
Wow, you're several years behind. Psyco was just a JIT module for Python and it's dead as a doorknob, doesn't even run on x86_64. Psyco's developer is working on similar optimizations as part of work on PyPy, which *is* a modern and vibrant project.
Maybe I'm giving Microsoft developers too much credit, but having developed almost all of the Windows APIs themselves, as a whole they should generally know how to use them as well. Windows doesn't have anything nearly as elegant as kqueue, but even IOCP works well enough that you wouldn't be throwing in more threads instead.
That said, I can't find a sane reason that you'd need so many threads just for a browser. For pure CPU-bound throughput you're best off having the same number of threads as cores, which gives you minimal overhead with as much parallelism as you'll get out of the hardware. You can add IO-bound threads on top specifically to get that bottleneck out of the way of CPU bound threads. I highly doubt IE8 has 113 IO-bound threads on top of its 4 (or whatever) CPU-bound threads.
"Since invention of flash video we are free from unnecessary plugins"
*headexplodes*
If it was that simple, you'd just use + as your hash function. No.
The minutes are well-known so that is already a lot of entropy you're giving the attacker for free. They don't know the string, but if they intercept the hash, they can work it out almost trivially because of how broken MD5 is. At least using HMAC and SHA256 (or better) will insulate the key from hash reversal.