That's why a GNU Make-based boot process is such a good idea. The dependencies are already sorted out, and only independent processes will boot in parallel.
That is not the issue. I don't have the time or energy to go into it now, so I'll repost what I wrote in 2005:
This is 99% true for image VIEWING programs. However for image MANIPULATION programs (like the GIMP) it's a very different story.
Say for example you have a photograph that is underexposed such that the brightest pixel is 25% gray. For the sake of argument let's deal with a grayscale image (or just one channel of an RGB image).
On a histogram all the 'bars' for this underexposed picture will be bunched up the left side, occupying the first 25% of the graph. If you want to fix it, you would normally spread out the histogram so that the bars span the whole graph (ie whites appear white instead of 25% gray). Since our shades were originally bunched up we only have a quarter of the possible number of shades available to us. Now if you only have 8 bits per channel there will only be 255/4=64 possible shades of gray in your picture, and banding effects will be very apparent. This will be apparent in the histogram since there will be distinct gaps between each bar.
Try it again with 16 bits per channel, hey let's do even 12 bits per channel. Our total number of gray shades is now 2^12=4096. Divide that by 4=1024 shades to spread out. You can downsample that to 256 shades and still get a full 24-bpp image with no banding. The histogram will now be a continuous solid shape with no gaps (unless any were present in the original image).
(This all applies to colour-correction too as much as simple lightness adjustment)
Combine these efforts with IBM's recommended use of Make for startup dependencies, and Fedora's One Second X project and we should have some marked improvements in boot time.
It's been a long road Getting from there to here It's been a long time But my time is finally near
And I can feel the change in the wind right now Nothing's in my way And they're not gonna hold me down no more No they're not gonna hold me down
'Cause I've got faith of the heart I'm going where my heart will take me I've got faith to believe I can do anything I've got strength of the soul And no one's gonna bend or break me I can reach any star I've got faith, I've got faith, faith of the heart
Access to memory >4GB isn't the only benefit of going 64-bit on Intel/AMD architecture: Compiling for 'amd64' rather than 'i386' gives your code access to a lot more CPU registers among other things. That alone makes most operations significantly faster. So far the only application I've seen that doesn't significantly benefit from a 64-bit compilation is POV-Ray, and I've tried a lot.
"even though it's standard OpenGL, we didn't care - we still wanted to do it because we felt like it would bring a better experience to the end user... we believe that you should get a better experience and we're going to devote engineering resources to make that happen, even if it helps the competition."
If this isn't just BS, then kudos to nVidia. Not that I actually use PS. I use the GIMP, and am eagerly awaiting 2.6 with GEGL. I'm told 2.5 builds now have multithreaded support which will be great for those heavy filters. I'd like to see an OpenGL frontend like this one for the GIMP some day.
I still wonder if this is exactly what Microsoft wanted all along.
So many IT companies purporting to adhere to ISO standard this and that, against which MS, the king of proprietary, cannot compete. Much better to pull the rug out from under them by discrediting the standards body they are accredited against.
Slashdot Mirror
That's why a GNU Make-based boot process is such a good idea. The dependencies are already sorted out, and only independent processes will boot in parallel.
Literally? Was my monthly bandwidth even alive in the first place?
I believe it's because the 'X' in LaTeX is meant to be the greek letter 'chi', and pronounced as such.
Those crazy typesetters (toc toc)
Perhaps he lives in Arkansas?
Suspend to swap strikes me as a really really bad idea. What if your memory was near full and you had data in swap?
Swap files (a la the TuxOnIce project and Windows XP's hiberfil.sys) seem a much better idea, so long as you're not short on immediate disk space.
That is not the issue. I don't have the time or energy to go into it now, so I'll repost what I wrote in 2005:
This is 99% true for image VIEWING programs.
However for image MANIPULATION programs (like the GIMP) it's a very different story.
Say for example you have a photograph that is underexposed such that the brightest pixel is 25% gray. For the sake of argument let's deal with a grayscale image (or just one channel of an RGB image).
On a histogram all the 'bars' for this underexposed picture will be bunched up the left side, occupying the first 25% of the graph. If you want to fix it, you would normally spread out the histogram so that the bars span the whole graph (ie whites appear white instead of 25% gray). Since our shades were originally bunched up we only have a quarter of the possible number of shades available to us. Now if you only have 8 bits per channel there will only be 255/4=64 possible shades of gray in your picture, and banding effects will be very apparent. This will be apparent in the histogram since there will be distinct gaps between each bar.
Try it again with 16 bits per channel, hey let's do even 12 bits per channel. Our total number of gray shades is now 2^12=4096. Divide that by 4=1024 shades to spread out. You can downsample that to 256 shades and still get a full 24-bpp image with no banding. The histogram will now be a continuous solid shape with no gaps (unless any were present in the original image).
(This all applies to colour-correction too as much as simple lightness adjustment)
That's right, in 2008 the EXT3 filesystem still needs to be offline for a read-only consistency check.
Unfortunately even with journals one still needs regular fs checks so we can't just tune2fs -i our volumes to make the problem go away.
Combine these efforts with IBM's recommended use of Make for startup dependencies, and Fedora's One Second X project and we should have some marked improvements in boot time.
/dev/sda1 has not been checked in 60 days. Check forced ... ... /dev/sda1 clean
That's right, in 2008 the EXT3 filesystem still needs to be offline for a read-only consistency check.
Unfortunately even with journals one still needs regular fs checks so we can't just tune2fs -i our volumes to make the problem go away.
The bootcharts I have here tell me that the boot process is I/O bound, not CPU bound.
It's been a long road
Getting from there to here
It's been a long time
But my time is finally near
And I can feel the change in the wind right now
Nothing's in my way
And they're not gonna hold me down no more
No they're not gonna hold me down
'Cause I've got faith of the heart
I'm going where my heart will take me
I've got faith to believe
I can do anything
I've got strength of the soul
And no one's gonna bend or break me
I can reach any star
I've got faith, I've got faith, faith of the heart
That sounds like a nice idea, but I'll still keep the locks on my house, thanks.
He's human and therefore obviously at least slightly delusional and prone to ignoring logic.
Fixed that for you.
Access to memory >4GB isn't the only benefit of going 64-bit on Intel/AMD architecture: Compiling for 'amd64' rather than 'i386' gives your code access to a lot more CPU registers among other things. That alone makes most operations significantly faster. So far the only application I've seen that doesn't significantly benefit from a 64-bit compilation is POV-Ray, and I've tried a lot.
From the article:
"even though it's standard OpenGL, we didn't care - we still wanted to do it because we felt like it would bring a better experience to the end user... we believe that you should get a better experience and we're going to devote engineering resources to make that happen, even if it helps the competition."
If this isn't just BS, then kudos to nVidia. Not that I actually use PS. I use the GIMP, and am eagerly awaiting 2.6 with GEGL. I'm told 2.5 builds now have multithreaded support which will be great for those heavy filters. I'd like to see an OpenGL frontend like this one for the GIMP some day.
apt sig.
Well gee, that information might have been a little more useful to me YESTERDAY!!!
My DVDs work fine, thanks. As do my VHS tapes.
What was your point?
Heh. I see that even with a new facelift, DSE still haven't fixed their website to use URLs that don't depend on the current session.
well I don't know. Will I get to keep my AwesomeBar?
Since when? I'm pretty sure both Google and Apple are foreign too, based somewhere over in the Americas.
I still wonder if this is exactly what Microsoft wanted all along.
So many IT companies purporting to adhere to ISO standard this and that, against which MS, the king of proprietary, cannot compete. Much better to pull the rug out from under them by discrediting the standards body they are accredited against.
As pointed out further down this thread, I made a mistake in the above comment:
The two movies are Shark Tale and Madagascar.
Over The Hedge wasn't one of the forced trailers.
Oh. I'd just thought it was lolspeak for "HELLO".
Aargh, I meant Shark Tale! Sorry, not Over The Hedge. Please don't add that to your list of never-see movies on account of my prior post.