Excuse my nitpicking, your post sparked some new questions for me:
The problem stems when legitimate applications attempt to use that memory. How long does it take to page (read/wirte) 16GB, 4KB at a time?
Are you sure that's it's only reading/writing 4KB at a time? It seems pretty braindead to me.
The old 1:1+x and 2:1 memory to disk ratios are based on notions of swapping rather than paging (yes, those are two different virtual memory techniques), plus allowing room for kernel dumps, etc. Paging is far more efficient than swapping ever was.
Could you elaborate on the difference between swapping and paging? I have always thought of it (adopting the term "paging") as an effort to disconnect modern Virtual Memory implementations from the awful VM performance of Windows 3.1/9x. Wikipedia mentions them as interchangeable terms and other sources on the web seem to agree.
You might come back and say, one day I might need it. Well, one day you can create a file (dd if=/dev/zero of=/pagefile bs=1024 count=xxxx), initialize it as page (mkswap/pagefile), and add it as a low priority paging device (swapon -p0/pagefile). Problem solved.
Just mentioning here that Swapspace (Debian package) takes care of that, with configurable thresholds.
You may say the performance will be horrible with paging on top of a file system - but if you're overflowing several GB to a page file on top of a file system, the performance impact won't be noticeable as you already have far, far greater performance problems. And if the page activity isn't noticeable, the fact its on a file system won't matter.
Quoting Andrew Morton: "[On 2.6 kernels the difference is] None at all. The kernel generates a map of swap offset -> disk blocks at
swapon time and from then on uses that map to perform swap I/O directly
against the underlying disk queue, bypassing all caching, metadata and
filesystem code."
Your way is the proper one to go about it, provided you stay on top of security updates by yourself.
In the aforementioned developers' case, they just followed some shitty "How to install LAMP" "howto" and never bothered to check if their distro provided the relevant packages. On top of that, they had absolutely no clue on how to provide a secure or even performance-optimised configuration for the custom compiled packages. If all that wasn't enough, they also never applied security updates after the initial installation.
I've met smartpants web developers that felt they were getting a more tailored-to-their-system installation by downloading tarballs and compiling the stack all the way down.
One of the welcome options involving the hex grid is the support of a "strategic view" which flips the graphics into what looks almost like a board game full of flat simplified icons that represent terrain, units and resources in simple shapes. It turns the busy Civ V visuals into a very-easy-to-scan map when you are searching for the hex that has the whales the people of Damascus are demanding.
Seems the writer only played Civ IV or something.
On a side note, is there a FLOSS clone of the newer Civ games?
Freeciv is supposedly a clone of Civ II, not any less addictive though.
Funny you should mention that - a lot of the newer apps are definitely influenced by it.
Apart from that, I think KDE should keep aiming for flexibility in the UI just as GNOME aims for extreme minimalism - both have their place for different types of users.
...one innovation I'd like to see come up (in X-windows or wherever) would be to allow users to "tint" the whole desktop with a particular color scheme and pattern... something that can hit the windows and wallpaper evenly not unlike the sun is currently hitting my monitor, only not so bright, blurry and distracting.
Think looking at a monitor with the faint reflection of light hitting rippling water... ahh, soothing!
Regarding the American Civil War, IIRC there were two groups of states (North & South) battling it out with the original reason being slavery abolishment. Couldn't they have divided into two federations?
In Russia's case I'm not sure what you're referring to; the Czars had already "unified" it long before.
As for Cyprus, Greek-Cypriots and Turkish-Cypriots had very friendly relations after the country was formed. There had been some cases of hostility between individuals in some cases (which I think were to be expected in a newly formed country) and Turkey used that as an excuse to invade and "protect" the Turkish-Cypriots.
When the country polarises in such an extent, perhaps it's time two new countries are formed consisting of the polarised groups.
Oh wait, I forgot your constitution precludes that...
to get a list of available framebuffer drivers. Possible candidates are: uvesafb,vesafb,vga16fb or possibly a specialised driver for your VGA card, if you can see one.
The syntax (in Linux 2.6?) in most cases is video:DRIVER:XRESxYRES-BPP.
Here's what I'm using: video=uvesafb:1024x768-32,mtrr:3,ywrap
5. Attach the disk back to the POS.
6. Use links2 as your browser in VC1 (Alt+F1). It supports images, some JS and some CSS(?). You'll be able to read Slashdot in its familiar format with it (which I assume is the point of this exercise). It can use either a framebuffer or SVGAlib.
7. Use fbterm as your terminal emulator in VC2 (Alt+F2). It supports multiple buffers. This one requires a framebuffer to work or else you'll have to make do with the standard linux console (VC2-VC64).
Note: I'm not sure if the above will work with 28MB RAM. In that case, you can try the latest 2.4 kernel from kernel.org and links2 using SVGAlib.
Also: Don't try running aptitude on the POS, you're in for a world of misery.:-P
Slashdot Mirror
Excuse my nitpicking, your post sparked some new questions for me:
The problem stems when legitimate applications attempt to use that memory. How long does it take to page (read/wirte) 16GB, 4KB at a time?
Are you sure that's it's only reading/writing 4KB at a time? It seems pretty braindead to me.
The old 1:1+x and 2:1 memory to disk ratios are based on notions of swapping rather than paging (yes, those are two different virtual memory techniques), plus allowing room for kernel dumps, etc. Paging is far more efficient than swapping ever was.
Could you elaborate on the difference between swapping and paging? I have always thought of it (adopting the term "paging") as an effort to disconnect modern Virtual Memory implementations from the awful VM performance of Windows 3.1/9x. Wikipedia mentions them as interchangeable terms and other sources on the web seem to agree.
You might come back and say, one day I might need it. Well, one day you can create a file (dd if=/dev/zero of=/pagefile bs=1024 count=xxxx), initialize it as page (mkswap /pagefile), and add it as a low priority paging device (swapon -p0 /pagefile). Problem solved.
Just mentioning here that Swapspace (Debian package) takes care of that, with configurable thresholds.
You may say the performance will be horrible with paging on top of a file system - but if you're overflowing several GB to a page file on top of a file system, the performance impact won't be noticeable as you already have far, far greater performance problems. And if the page activity isn't noticeable, the fact its on a file system won't matter.
Quoting Andrew Morton:
"[On 2.6 kernels the difference is] None at all. The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code."
I apologise, I didn't pay enough attention to the context while replying.
Indeed, using swapping for the sole purpose of mitigating memory leaks is wrong.
1. Programs can't use the swapped memory directly. The kernel only swaps parts of memory that haven't been accessed in a while.
2. By swapping out unused (even because of leaks) memory, the kernel has more memory to use for disk caching.
All this has nothing to do with whether your system will grind to a halt today instead of one month later.
And to answer your question, the mod(s) apparently thought this was common knowledge and not worth responding to.
Where's "+1, Depressing" when you need it...
Original source
Fucking rumour starters at it once more.
Your way is the proper one to go about it, provided you stay on top of security updates by yourself.
In the aforementioned developers' case, they just followed some shitty "How to install LAMP" "howto" and never bothered to check if their distro provided the relevant packages. On top of that, they had absolutely no clue on how to provide a secure or even performance-optimised configuration for the custom compiled packages. If all that wasn't enough, they also never applied security updates after the initial installation.
I've met smartpants web developers that felt they were getting a more tailored-to-their-system installation by downloading tarballs and compiling the stack all the way down.
Nevermind updates or security though...
One of the welcome options involving the hex grid is the support of a "strategic view" which flips the graphics into what looks almost like a board game full of flat simplified icons that represent terrain, units and resources in simple shapes. It turns the busy Civ V visuals into a very-easy-to-scan map when you are searching for the hex that has the whales the people of Damascus are demanding.
Seems the writer only played Civ IV or something.
On a side note, is there a FLOSS clone of the newer Civ games?
Freeciv is supposedly a clone of Civ II, not any less addictive though.
...when you're a stranger...
+5 Hilarious :D
Funny you should mention that - a lot of the newer apps are definitely influenced by it.
Apart from that, I think KDE should keep aiming for flexibility in the UI just as GNOME aims for extreme minimalism - both have their place for different types of users.
Sorry, I should've qualified that with "here and now".
The poor chap(s) working on telepathy-qt can only do so much - it's been coming a long time now. :(
Qt 4 came out in freaking 2005. Also, it still has the Qt3Support helper classes for porting.
If 5 years aren't enough for you to migrate your app, by all means feel free to mantain it by & for yourself while the rest of the world has moved on.
...one innovation I'd like to see come up (in X-windows or wherever) would be to allow users to "tint" the whole desktop with a particular color scheme and pattern... something that can hit the windows and wallpaper evenly not unlike the sun is currently hitting my monitor, only not so bright, blurry and distracting.
Think looking at a monitor with the faint reflection of light hitting rippling water... ahh, soothing!
xrandr --gamma <r>:<g>:<b>
Tint to your heart's desire ;)
Devil's advocate here - two things they have over KDE are:
Apart from these two, I'd prefer they took the HIG and the other design principles and built a new GNOME over KDElibs.
Regarding the American Civil War, IIRC there were two groups of states (North & South) battling it out with the original reason being slavery abolishment. Couldn't they have divided into two federations?
In Russia's case I'm not sure what you're referring to; the Czars had already "unified" it long before.
As for Cyprus, Greek-Cypriots and Turkish-Cypriots had very friendly relations after the country was formed. There had been some cases of hostility between individuals in some cases (which I think were to be expected in a newly formed country) and Turkey used that as an excuse to invade and "protect" the Turkish-Cypriots.
When the country polarises in such an extent, perhaps it's time two new countries are formed consisting of the polarised groups.
Oh wait, I forgot your constitution precludes that...
Anytime. :)
Last day's ranking (Fastest to Slowest)
x86 Sunspider:
x86 v8bench:
and so on...
You can also mouseover the dots on the graphs to get detailed information in tooltips ;-)
PS: That was supposed to be an ordered list, at least before Slashdot's CSS fucked it up.
Most of the times when I tried F-Spot, it just keeps crashing on me.
Do we need such silly commentary?
I'm using Kubuntu btw, so I couldn't care less about F-Spot.
Use:
/lib/modules/`uname -r` -iname '*fb.ko' -print0 | xargs -0n1 basename | sed 's/\.ko$//g'
find
to get a list of available framebuffer drivers. Possible candidates are: uvesafb,vesafb,vga16fb or possibly a specialised driver for your VGA card, if you can see one.
The syntax (in Linux 2.6?) in most cases is video:DRIVER:XRESxYRES-BPP.
Here's what I'm using: video=uvesafb:1024x768-32,mtrr:3,ywrap
Note: I'm not sure if the above will work with 28MB RAM. In that case, you can try the latest 2.4 kernel from kernel.org and links2 using SVGAlib. :-P
Also: Don't try running aptitude on the POS, you're in for a world of misery.
Good luck!
$375,000? That's petty change compared to how much they made out of it.
Or even better:
find my_lawn -name kids\* -delete -print
And kiss the fork-fest goodbye...
$ ls -1d */*
There, fixed that for you.