PS. If anyone knows how to speed up postgres SELECT * FROM tv WHERE title ILIKE '%searchterm%' queries, please let me know. Indexes don't seem to help with %something% queries.:(
Did you try tsearch2 from pgsql-contrib? It's going to be in 8.3 mainline AFAIK.
What kind of PC crack did the gentoo people invent? it took me all night to build a kernel on my debian box.
You may have compiled a whole family of kernels (e.g. i386, i686, i686-smp, athlon, athlon-mp, wtf, etc.) -- you'd have to check the debian/rules file or google around, but it seems like it. Sub-5-minute kernel build times aren't really possible with cold cache (untarring the tree right before compiling makes the kernel source already available in page cache, so the sibling poster's machine had it easy). Anyway, a night to build a *single* kernel image, even with `make allmodconfig` is way overboard. What would the machine be? A Pentium-75?
Also I run a photos website on a Linux box. Occasionally the Google spider would be indexing the site and cause lots of photos to be resized. This uses some CPU but the major problem is disc I/O.
If you're generating thumbnails on the fly without caching, you get what you ask for.
Solution: Don't give your chroot jail access to the binfmt filesystem. I'm not sure how this can be done, though, as root is allowed to mount pretty much whatever it wants.
root can escape a chroot jail easily anyway, this is no protection. Using --rbind mounts in per-process namespaces (a'la linux-vserver) is a better idea.
...it assumes volatile RAM. Duh. Further, unmapping RAM doesn't wipe it - it just deletes the pointer. If you remove the assumption of volatile memory, you remove the need to transfer anything. All that would be required would be to suspend the thread when you hit the point in memory that has been hot-swapped out.
I know unmapping RAM doesn't wipe it, but unplugging it certainly does. Given the recent years of computer architectures (I'm a bit too young to have played with IBM mainframes of ye olde days - and I wish I weren't), volatile RAM assumption is IMHO sensible to make.
If you were inclined to do so, you could design a system (with non-volatile main RAM) doing what you described, but I currently fail to see the point. Would you be able to reliably restart a thread on another machine? It would have "everything" underneath changed, including the processes around it, filesystem, networking and maybe the pid, also migrating processes with file-backed mmapped memory would be a bitch (copy the file? what about writes etc.? use some clustering technique to pass the file data?). I think you would eventually end up with some cluster software with support for migrating via RAM sticks. If I'm wrong, please point out where and how.
As for the lack of imagination, well, IMHO currently the idea is unfeasible due to hardware (plain RAM stick are _very_ volatile memory), so (for me, being 99% a software guy) it is (well, almost) like calling not envisioning innovative uses for a space elevator lack of imagination.
My response was a bit trollish but hey, your post didn't exactly state you know what you're talking about (it just as well might have come from a i-have-a-petabyte-disk type troll). Sorry if you felt offended, if you have 30 years of mainframe experience, my respect.
Linux now supports hot-swapping of actual RAM, which introduces the possibility of physically transferring live, active threads between machines without the need for a physical network. Not sure how useful this would be in practice, but the pure geek value in such a demonstration would surely turn a LOT of heads in the IT profession.
I'll assume you're just uninformed. How the fsck do you expect to be able to migrate _anything_ via RAM sticks between machines? You'd end up with data gone before you even unplugged the stick.
Linux memory hotplug, sure, but if you cared to actually look at the patches and stuff, you'd see that all to-be-unplugged memory must be first unmapped and processes using it migrated elsewhere.
How about supporting not one read() but one session? I.e. lock after unplugging, not reading the data? Top it off with encryption (not neccessarily hardware assisted but it'd be nice for OS compatibility). Off to the patent office you go!:)
Still, it'd be a solution looking for a problem. You want to steal data, you will.
MS may have earned a reputation for being insecure, no problem there. I evaluate it at the moment, and at the moment it's getting better.
Linux may have earned a reputation for being awkward to use on a desktop. I evaluate it at the moment, and at the moment it's still a set of apps with no common standards held together by sticky tape and pipes.
Let me rephrase,
MS may have earned a reputation for being insecure, no problem there. I evaluate it at the moment, and at the moment it's still a steaming pile of security nightmares.
Linux may have earned a reputation for being awkward to use on a desktop. I evaluate it at the moment, and at the moment it's getting better.
Slashdot Mirror
Twice.
You are thinking in Perl? :)
Enjoy.
octopi is 25.1327412
If *nobody* reproduces, evolution still stops, but for a tad different reason :)
Consider a multithreaded program, where one thread walks though the list while the other is reversing it. Your O(n) solution:
thread 1 (reversing list):
thread 2 (walking though the list):
So who the fuck cares about your temporary variable? Sure, you don't leak list elements but you're solving a different problem.
If I had mod points, I'd mod you up even though I'm Polish (and yes, my last name has vowels but my given name is fun for foreigners :) )
Well, what do you suggest? getc() or scanf()?
Actually, the Wikipedia entry for "Missing Link" does a pretty good job...
;)
I went there and I got a 404...
Re: your sig:
:)
For units with bitlength a multiple of 4, (0x2B | ~0x2B) == 0xFFFFF.... So there. (Revision 4 and counting...)
What about: (0x2B | ~0x2B) == ~0
...it assumes volatile RAM. Duh. Further, unmapping RAM doesn't wipe it - it just deletes the pointer. If you remove the assumption of volatile memory, you remove the need to transfer anything. All that would be required would be to suspend the thread when you hit the point in memory that has been hot-swapped out.
I know unmapping RAM doesn't wipe it, but unplugging it certainly does. Given the recent years of computer architectures (I'm a bit too young to have played with IBM mainframes of ye olde days - and I wish I weren't), volatile RAM assumption is IMHO sensible to make.
If you were inclined to do so, you could design a system (with non-volatile main RAM) doing what you described, but I currently fail to see the point. Would you be able to reliably restart a thread on another machine? It would have "everything" underneath changed, including the processes around it, filesystem, networking and maybe the pid, also migrating processes with file-backed mmapped memory would be a bitch (copy the file? what about writes etc.? use some clustering technique to pass the file data?). I think you would eventually end up with some cluster software with support for migrating via RAM sticks. If I'm wrong, please point out where and how.
As for the lack of imagination, well, IMHO currently the idea is unfeasible due to hardware (plain RAM stick are _very_ volatile memory), so (for me, being 99% a software guy) it is (well, almost) like calling not envisioning innovative uses for a space elevator lack of imagination.
My response was a bit trollish but hey, your post didn't exactly state you know what you're talking about (it just as well might have come from a i-have-a-petabyte-disk type troll). Sorry if you felt offended, if you have 30 years of mainframe experience, my respect.
Linux now supports hot-swapping of actual RAM, which introduces the possibility of physically transferring live, active threads between machines without the need for a physical network. Not sure how useful this would be in practice, but the pure geek value in such a demonstration would surely turn a LOT of heads in the IT profession.
I'll assume you're just uninformed. How the fsck do you expect to be able to migrate _anything_ via RAM sticks between machines? You'd end up with data gone before you even unplugged the stick.
Linux memory hotplug, sure, but if you cared to actually look at the patches and stuff, you'd see that all to-be-unplugged memory must be first unmapped and processes using it migrated elsewhere.
Or maybe IHBT.
some of us are cannibals, too (no, not me :P)
How about supporting not one read() but one session? I.e. lock after unplugging, not reading the data? Top it off with encryption (not neccessarily hardware assisted but it'd be nice for OS compatibility). Off to the patent office you go! :)
Still, it'd be a solution looking for a problem. You want to steal data, you will.
Consider yourself +1, Informative :)
MS may have earned a reputation for being insecure, no problem there. I evaluate it at the moment, and at the moment it's getting better.
Linux may have earned a reputation for being awkward to use on a desktop. I evaluate it at the moment, and at the moment it's still a set of apps with no common standards held together by sticky tape and pipes.
Let me rephrase,
MS may have earned a reputation for being insecure, no problem there. I evaluate it at the moment, and at the moment it's still a steaming pile of security nightmares.
Linux may have earned a reputation for being awkward to use on a desktop. I evaluate it at the moment, and at the moment it's getting better.
There ya go, much better now.
1.44nd?