With the exception of some early BSD kernels that actually did swap (e.g. those used for certain versions of the Borderware Firewall, for instance) that swap-equals-two-times-memory rule was usually misinterpreted. A better way of putting it would be to say that if your total VM usage was greater than two times how much real memory you had, you probably ought to fit some more memory, otherwise your machine will thrash and performance will suck badly.
These days, with a current Linux kernel, the only reason for swap is to page out data pages (executable pages will be just dropped and paged-in again from the original binary on disc) in order to leave more room for disc cache.
Finally, disc is cheap these days, and re-partitioning can be a pain if one adds more memory later, so these days, I usually just make swap twice the maximum amount of RAM the system can accept.
This trick even works non-destructively: dd if=/dev/hda of=/dev/hda bs=512
Hmmm... I'd expect dd to throw a read-error when it encounters the first damaged block, and go no further. Conceivably, it may even cause the block device driver to throw a wobbly and crash the kernel, particularly if the implementation of the driver or the hardware is *cough* incomplete. I have no disc to test that theory right now, though...
Incidentally, if you can identify which file is occupying the failed blocks, and it's not the filesystem metadata, then you can just delete the file and create a dummy file that occupies all the unallocated space on the filesystem to achieve the same effect; no need to dd the entire drive or even the whole partition! Of course, if Murphy has struck, and it's the filesystem metadata occupying the bad block(s), you're boned.:-/
Re:Not sure how it works...
on
Computer Voodoo?
·
· Score: 2, Informative
Is it the drive itself that tracks and takes care of bad sectors, or does the OS do that?
Both.:-)
As far as I'm aware, all (E)IDE, SCSI and (S)ATA drives have spare blocks that are used for remapping blocks that fail whilst the drive is in service (incidentally, I suspect that SCSI drives have significantly more, which would go some way to explaining their lower capacity/platter ratio and higher MTBF ratings, beyond the pure mechanical stuff and individual rather than batch testing).
In addition to that, most filesystems include a way of marking blocks as bad so that new information will not be written there. I'm pretty sure DOS/Windows' scandisk does this if it can't read a block, and mke2fs and friends will make use of the badblocks list generated by any initial badblocks run (though I don't think there's any [easy] way of marking blocks as bad once the filesystem has been created with typical UNIX filesystems).
Re:Not sure how it works...
on
Computer Voodoo?
·
· Score: 4, Insightful
Roadmaster has the explanation bang on the money in his post.
The only thing left to add is that doing
dd if=/dev/zero of=/dev/hdb bs=10485760
should be significantly quicker.
Oh, and the other thing is that, these days, I tend to run badblocks' write-test on new drives, in an attempt to get the drive to remap any failed or marginal blocks before putting Important Information on them.
The instruction set design made sense, and my first program was 16 bytes long. I can't imagine doing that with a Z80.
On the Spectrum, it was pretty easy to write a variant tape loader using parts of the ROM. I'm pretty sure a basic headerless loader was about 17 bytes.
Certainly, I remember my GCSE project was a 27 byte printer interface driver that fit into the designated space with 4 bytes to spare (I was hacking a pre-existing commercial word processor package for which no source code was available).
I'd also venture 'Terminator 2' and 'Aliens', which drew upon details set up in the original, but were largely their own movies, and actually advanced the characters and story.
You say you have money in the bank, but you've taken out loans?
Assuming those loans are at a rate something more than inflation and that interest is accruing, the best thing to do would be to pay them off.
Of course, if you've got a sweetheart rate, or interest doesn't start accruing until you graduate or something, they're worth keeping as-is, and you should probably look into various tax-free and risk-suitable savings schemes.
It remains to be seen if this is true in this case, but in general, Microsoft have allowed their Windows and Office licenses to be used instead for a single installation of any previous version at the customer's option.
This was seen in practice a lot during the migration from WNT 4 to W2K; companies bought as many W2K licenses as they needed, but actually ran WNT 4 until they were happy enough with W2K to switch over.
I submit that these are two contradictory proposals. Urban concentrations will be the hardest hit by a severe oil shortage. No oil, for urban areas, means no heating and no food. If you live in a rural area, you'll have more easy access to farm produce and the possibility of heating your house with wood.
I've thought about this also. Now, certainly things are somewhat different in the UK, than in the US (smaller cities - London is 'only' 9m people, shorter distances between towns, cities and arable land, traditional population centres, more functional public transport and so on), but in the UK, we generally have smaller houses. Many were built in the late 1800s and were designed to be heated with wood or coal, even in the city. Further, during winter, families would live in one room more often. Finally, European cities have always had marketplaces. Food would be brought in typically on horse and cart. None of this is unachievable post-peak, we just need to have the will to do so.
If you live in the city, you're screwed. There'll be no oil to get the food from the countryside to you, and there are very, very few apartments in the US that come with a stove, much less having access to wood or coal with which to stoke it. Furthermore, without oil, factory farming will take a big hit, so the per-capita food production will drastically fall. More of the population will have to turn their attention to the manual labor of producing food.
I expect that when we run out of oil, unless we've developed a good replacement in time, you'll see a mass migration to rural areas.
I think those are fair enough predictions, but I think it will be a more gradual shift. As such, unless a city dweller already has decent farming skills, then they'll probably be more screwed by moving out to the countryside in pursuite of some idyllic fantasy. I'm realistic enough to realise that a) farming is much harder than it looks b) I've not got much in the way of transferrable skills and c) it would take me too long to learn them.
So WTF is it with the BPI suing a Russian company in the UK? (BPI Sue AllOfMp3 In British Courts)
Probably to (attempt to) establish the legal point that use of AllOfMP3 by UK residents and/or citizens is illegal, thereby paving the way for prosecutions against users and/or getting ISPs to block access (cf. Nazi memorabilia auctions in France).
I'd kind of like to buy a RAID card that is accelerated for database and/or search work. I mean, issue high-level commands to the controller hardware, and let it collect the results while the main processor is doing something else.
This was my degree supervisor's main research interest. Searching for 'Intelligent File Store' in conjunction with 'Essex' and 'Lavington' should find lots of juicy info.
I meant to say that open source should be about writing software, *not* making money or protecting freedom.
That is all Open Source is about, and that's what makes it distinct from Free Software, which is why rms gets upset when a journo accuses him of being the 'leader of the OSS movement' or other such idiocy.
Indeed. Far better would be to have an internationally-recognized standard of living that complements the UN Universal Declaration of Human Rights; my suggestions for such a standard would be a roof over your head, access to preventative and essential healthcare, access to a balanced and nutritionally adequate diet and access to as much education as you can make effective use of.
Of course, Apple didn't have a monopoly to risk losing when it took this course of action...
No, they had a small and diminishing market share they risked alienating, in the face of free competitors and a monopoly.
That seems like a convincing argument at first, but I imagine the thought process going round Apple was something like "Right, we can do MacOS X and stand a good chance of maintaining or even increasing our market share, but risk being dead this year, or we can be snuffed out by our competitors next year anyway because our platform has stagnated."
Microsoft, on the other hand, can probably get away with treading water - as long as they keep compatibility with all the third party apps out there - for years to come and still be around for decades. Yes, the platform will get crappier for its users, but that's not (really) Microsoft's concern as long as it's still making big enough margins.
Not only is he a technologist, he's a great scientician and an award-winning engineeringer. His unfailicating leaderostimation and efficientistic directionating of Microsoft's profusical resources will undoubtingly work for the betterificationating of all humanitism.
You are George W. Bush, and I claim my five pounds.
MacOS 9 [...] really was beyond repair. Apple tried a number of times, and ended up with a number of failed projects.
What worked for them with OSX was basically scrapping everything before and starting over. They saved themselves a lot of time by borrowing a lot from unix and nextOS, and reproduced some of the aspects of OS9. A layer of backwards compatibility was sort of hacked over the new OS, but it wasn't integrated into the new, it was really its own thing.
Apple succesfully did what MS needs to do. They made a clean break with the past, knowing that although it might cause some problems up front, in the long run, it'd be for the best.
Of course, Apple didn't have a monopoly to risk losing when it took this course of action...
It's also a much safer route legally speaking because you aren't directly involved in the criminal act, you're just selling the tools.
Be carefull!!! In the US, you can be charge with being an accessory to a crime.
...and shortly in the UK also if the government get their way. Or, for that matter, if you create a security testing tool that some copper takes a dislike to.
I've used FC3 for a couple years now, I guess, and yum etc. has been finicky as hell. I'm trying your tips.
Be warned that if you've already installed a bunch of random RPMs from random repositories, simply cutting down the list of configured repositories won't help. You'll have to sort out the mess of packages you have installed and decide whose packages you're going to fit everything around. Personally, I pull most of my packages from base/fedoralegacy + rpmforge + dag + freshrpms with good results. My MythTV box uses ATrpms, dag, fedora-extras and freshrpms, and requires a bit more care as ATrpms sometimes includes upgrades of base packages which may not always be desirable (for a MythTV box, it's fine).
Question: "roll your own"? That sounds hard... is it hard? Where to start?
It's not that hard. Start with something small and quite high up the system stack (so it likely won't break anything that uses it!) like elinks or gaim. Installing ccache is probably advisable, since you tend to end up having to run the compile a few times before the package builds correctly (rpm doesn't allow any manual intervention during the build process since the philosophy is that the.spec file should document everything that needs to be done to build the package. Consider it a 'bondage-and-discipline' approach if you like). Finally, there are a couple of books: the Red Hat RPM Guide and Maximum RPM (somewhat dated now, but being revised).
If there was a single "universe" repository, I don't think there would be that much difference from the end user's POV.
On the other hand, I suspect we'd end up with multi-year instead of multi-month release cycles as we attempted to stablise and integrate such a huge selection of packages with respect to each other.
In order to get any packages that you really want to use in Fedora, you need to add on repositories. If you do that, you will wind up in dependency hell... eventually.
In theory, yes, in practice no, as long as you stick to repos whose maintainers talk with each other.:-)
For packages that you really want from an incompatible repo, you can temporarily enable the repo (on the yum command line even - no config file hacking necessary) at install time, but leave that repo disabled for the purposes of 'yum update' and the like.
With gentoo if you have an ebuild version 1.0.0 of a piece of software and you want version 1.0.1, then most of the time you can get a valid ebuild for v1.0.1 with the single command "mv foobar-1.0.{0,1}.ebuild". If the dependances have changed this might not work, even then you can just open the ebuild with a text editor and fix it.
RPM works almost exactly the same way. rpm -ivh the src.rpm you have, edit the.spec file to refer to the new version of the upstream tarball, then run 'rpmbuild -ba' on the.spec file. Quite often, that's good enough.
Slashdot Mirror
These days, with a current Linux kernel, the only reason for swap is to page out data pages (executable pages will be just dropped and paged-in again from the original binary on disc) in order to leave more room for disc cache.
Finally, disc is cheap these days, and re-partitioning can be a pain if one adds more memory later, so these days, I usually just make swap twice the maximum amount of RAM the system can accept.
Race conditions and buggy hardware initialisation/reset routines, would be my guess.
Hmmm... I'd expect dd to throw a read-error when it encounters the first damaged block, and go no further. Conceivably, it may even cause the block device driver to throw a wobbly and crash the kernel, particularly if the implementation of the driver or the hardware is *cough* incomplete. I have no disc to test that theory right now, though...
Incidentally, if you can identify which file is occupying the failed blocks, and it's not the filesystem metadata, then you can just delete the file and create a dummy file that occupies all the unallocated space on the filesystem to achieve the same effect; no need to dd the entire drive or even the whole partition! Of course, if Murphy has struck, and it's the filesystem metadata occupying the bad block(s), you're boned. :-/
Both. :-)
As far as I'm aware, all (E)IDE, SCSI and (S)ATA drives have spare blocks that are used for remapping blocks that fail whilst the drive is in service (incidentally, I suspect that SCSI drives have significantly more, which would go some way to explaining their lower capacity/platter ratio and higher MTBF ratings, beyond the pure mechanical stuff and individual rather than batch testing).
In addition to that, most filesystems include a way of marking blocks as bad so that new information will not be written there. I'm pretty sure DOS/Windows' scandisk does this if it can't read a block, and mke2fs and friends will make use of the badblocks list generated by any initial badblocks run (though I don't think there's any [easy] way of marking blocks as bad once the filesystem has been created with typical UNIX filesystems).
The only thing left to add is that doing
should be significantly quicker.Oh, and the other thing is that, these days, I tend to run badblocks' write-test on new drives, in an attempt to get the drive to remap any failed or marginal blocks before putting Important Information on them.
Like a ton of invisible lead soup?
On the Spectrum, it was pretty easy to write a variant tape loader using parts of the ROM. I'm pretty sure a basic headerless loader was about 17 bytes.
Certainly, I remember my GCSE project was a 27 byte printer interface driver that fit into the designated space with 4 bytes to spare (I was hacking a pre-existing commercial word processor package for which no source code was available).
I'd also venture 'Terminator 2' and 'Aliens', which drew upon details set up in the original, but were largely their own movies, and actually advanced the characters and story.
* Over-reliance on CGI and special effects
* Cliched fight and/or chase scenes
* Rehashed stories
* Pointless remakes and/or revivals of retro TV series
* "Never mind the quality, feel the quantity!" - two+ hour movies that only have 90 minutes of story. Leave me wanting more not less!
* Poor marketing of indie flicks that may not suffer from the above faults, such that I don't hear about them until they're on DVD or on TV
Assuming those loans are at a rate something more than inflation and that interest is accruing, the best thing to do would be to pay them off.
Of course, if you've got a sweetheart rate, or interest doesn't start accruing until you graduate or something, they're worth keeping as-is, and you should probably look into various tax-free and risk-suitable savings schemes.
This was seen in practice a lot during the migration from WNT 4 to W2K; companies bought as many W2K licenses as they needed, but actually ran WNT 4 until they were happy enough with W2K to switch over.
I've thought about this also. Now, certainly things are somewhat different in the UK, than in the US (smaller cities - London is 'only' 9m people, shorter distances between towns, cities and arable land, traditional population centres, more functional public transport and so on), but in the UK, we generally have smaller houses. Many were built in the late 1800s and were designed to be heated with wood or coal, even in the city. Further, during winter, families would live in one room more often. Finally, European cities have always had marketplaces. Food would be brought in typically on horse and cart. None of this is unachievable post-peak, we just need to have the will to do so.
If you live in the city, you're screwed. There'll be no oil to get the food from the countryside to you, and there are very, very few apartments in the US that come with a stove, much less having access to wood or coal with which to stoke it. Furthermore, without oil, factory farming will take a big hit, so the per-capita food production will drastically fall. More of the population will have to turn their attention to the manual labor of producing food.
I expect that when we run out of oil, unless we've developed a good replacement in time, you'll see a mass migration to rural areas.
I think those are fair enough predictions, but I think it will be a more gradual shift. As such, unless a city dweller already has decent farming skills, then they'll probably be more screwed by moving out to the countryside in pursuite of some idyllic fantasy. I'm realistic enough to realise that a) farming is much harder than it looks b) I've not got much in the way of transferrable skills and c) it would take me too long to learn them.
You're not the only one who thought that. As a Brit, I'm feeling somewhat pwn3d.
Probably to (attempt to) establish the legal point that use of AllOfMP3 by UK residents and/or citizens is illegal, thereby paving the way for prosecutions against users and/or getting ISPs to block access (cf. Nazi memorabilia auctions in France).
This was my degree supervisor's main research interest. Searching for 'Intelligent File Store' in conjunction with 'Essex' and 'Lavington' should find lots of juicy info.
That is all Open Source is about, and that's what makes it distinct from Free Software, which is why rms gets upset when a journo accuses him of being the 'leader of the OSS movement' or other such idiocy.
Indeed. Far better would be to have an internationally-recognized standard of living that complements the UN Universal Declaration of Human Rights; my suggestions for such a standard would be a roof over your head, access to preventative and essential healthcare, access to a balanced and nutritionally adequate diet and access to as much education as you can make effective use of.
No, they had a small and diminishing market share they risked alienating, in the face of free competitors and a monopoly.
That seems like a convincing argument at first, but I imagine the thought process going round Apple was something like "Right, we can do MacOS X and stand a good chance of maintaining or even increasing our market share, but risk being dead this year, or we can be snuffed out by our competitors next year anyway because our platform has stagnated."
Microsoft, on the other hand, can probably get away with treading water - as long as they keep compatibility with all the third party apps out there - for years to come and still be around for decades. Yes, the platform will get crappier for its users, but that's not (really) Microsoft's concern as long as it's still making big enough margins.
You are George W. Bush, and I claim my five pounds.
What worked for them with OSX was basically scrapping everything before and starting over. They saved themselves a lot of time by borrowing a lot from unix and nextOS, and reproduced some of the aspects of OS9. A layer of backwards compatibility was sort of hacked over the new OS, but it wasn't integrated into the new, it was really its own thing.
Apple succesfully did what MS needs to do. They made a clean break with the past, knowing that although it might cause some problems up front, in the long run, it'd be for the best.
Of course, Apple didn't have a monopoly to risk losing when it took this course of action...
Be carefull!!! In the US, you can be charge with being an accessory to a crime.
Thanks, I try.
I've used FC3 for a couple years now, I guess, and yum etc. has been finicky as hell. I'm trying your tips.
Be warned that if you've already installed a bunch of random RPMs from random repositories, simply cutting down the list of configured repositories won't help. You'll have to sort out the mess of packages you have installed and decide whose packages you're going to fit everything around. Personally, I pull most of my packages from base/fedoralegacy + rpmforge + dag + freshrpms with good results. My MythTV box uses ATrpms, dag, fedora-extras and freshrpms, and requires a bit more care as ATrpms sometimes includes upgrades of base packages which may not always be desirable (for a MythTV box, it's fine).
Question: "roll your own"? That sounds hard... is it hard? Where to start?
It's not that hard. Start with something small and quite high up the system stack (so it likely won't break anything that uses it!) like elinks or gaim. Installing ccache is probably advisable, since you tend to end up having to run the compile a few times before the package builds correctly (rpm doesn't allow any manual intervention during the build process since the philosophy is that the .spec file should document everything that needs to be done to build the package. Consider it a 'bondage-and-discipline' approach if you like). Finally, there are a couple of books: the Red Hat RPM Guide and Maximum RPM (somewhat dated now, but being revised).
On the other hand, I suspect we'd end up with multi-year instead of multi-month release cycles as we attempted to stablise and integrate such a huge selection of packages with respect to each other.
Be careful what you wish for... :-)
In theory, yes, in practice no, as long as you stick to repos whose maintainers talk with each other. :-)
For packages that you really want from an incompatible repo, you can temporarily enable the repo (on the yum command line even - no config file hacking necessary) at install time, but leave that repo disabled for the purposes of 'yum update' and the like.
RPM works almost exactly the same way. rpm -ivh the src.rpm you have, edit the .spec file to refer to the new version of the upstream tarball, then run 'rpmbuild -ba' on the .spec file. Quite often, that's good enough.