If you have lots of data you need to do the maths about how much it costs to back the data up. And how much it costs to reconstruct the data again and decide whether it is worth backing the data up or not.
Of course. We develop/run apps & databases for state and multi-state gov't agencies, which those agencies derive much income from. They'd be highly pissed we couldn't restore the system to the minute of the crash.
Which we've had to do a couple of times after "unfortunate incidents".
You also need to consider how long it will take you to do the restore from the backup.
Again, of course. PCI compliance auditors make us, quarterly, restore a full database to a test rig, and yearly do a complete DR test at our Sungard cold site.
Stove-piped systems have the benefit that data can accumulate on one machine while we restore the "next phase" system. Only the customer-facing system needs to be clustered/hot-failover, etc.
But disks are much more fragile. A dropped "box" (that's how Iron Mountain keeps track of them) of tapes is much less likely to result in damage than dropping that same box of disks. Same with throwing the box into the back of a truck and hauling them back and forth to the off-site warehouse.
Both are bulky
IDE drives are ~30% larger (by volume) than DLT & LTO tapes, and that doesn't include the padding needed to protect hard drives.
NAS devices are cheaper and faster now. Lower end removable drives are not much more expensive than tapes, and they are a lot faster and easier to manage.
Having 21 days of off-site backups stored on NAS is kinda difficult.
Yeah, nice theory - except what actually happens is you have two different drivers both talking to the same hardware, and not talking to each other. The usual failure mode when it really does fail is to confuse things so much that the console driver doesn't work either.
But a reboot into the text-only console would fix that, which wouldn't happen if Plymouth loaded kms during boot.
I think the difference in that BSODs (used to?) happen quite frequently in Windows, and that, not the blue panic screen, was/is the real issue. The BSOD was just a visible, and therefore easy to criticize, manifestation of Windows' suckiness.
OTOH, bug-related (as opposed to those caused by failing hardware) kernel panics are pretty infrequent in Linux.
Just add "nokms" parameter to the kernel command line and it'll start kernel without kernel mode-setting support, in a plain old console.
What about all the gooey goop (Plymouth & Wayland) that RH and Ubuntu are layering on top of the boot process to make it dumber (I mean more user friendly) which specifically depend on kms?
people like you are why linux won't ever dominate the computer industry. try growing up and learning from your mistakes.
It is well documented that people who don't know WTF they are doing regularly screw up their computers and allow them to become rampantly infected by malware.
Thus, it is only rational to think that people who don't know how to administer a computer should not perform administrative tasks and have administrative privileges.
If that means that 95% of households that currently have computers shouldn't have them, so be it.
You don't really understand the consequences of doing kernel mode setting then.
Why am I not surprised???
None of your use cases will be impacted by the addition of kernel mode setting,
Interesting. Will the GEMified drivers require DRI/DRM? (Everything I've read about it seems to imply that.)
except that you'll be able to more easily get different resolutions out of your virtual consoles (you can already do that with framebuffer consoles, sometimes, depending on the hardware, and what driver you're using with X (if any)).
By using startx, I have no need for VCs. (I tried booting in different vga= modes, but it was too weird for eyes that are so used to 24x80...)
when you then have to get someone in to do the job properly
Hah hah hah hah hah hah.
Incompetent managers are usually expert at CYA, muddling thru, first denying that there's a problem, then blaming the database, then the DBA, then the hardware and then the specs. All while regularly releasing minor update after minor update, patching this open wound or that.
A memory manager for the graphics memory is very useful because it allows direct rendering and direct redirected rendering and such.
A definite step in the wrong direction.
One of the things I've always liked about *nix is the separation between kernel and graphics.
No matter how horked X is, I the system always boots in text mode console and work to repair X or a driver, install new software, etc, and even accomplish things with Mutt and links2.
Then, when I'm ready to "go graphical", simply run startx.
Computers SHOULD be designed for people who have no knowledge of the intricacies of operating systems.
Depends on what they are going to do with them. See below.
Computers SHOULD be designed to be safe for beginners to use.
Yes, to use. But they will always need knowledgeable people to manage them, and any attempt to overcome this fundamental law of nature is doomed to cause lots of people to be infected by lots of malware.
Slashdot Mirror
If you have lots of data you need to do the maths about how much it costs to back the data up. And how much it costs to reconstruct the data again and decide whether it is worth backing the data up or not.
Of course. We develop/run apps & databases for state and multi-state gov't agencies, which those agencies derive much income from. They'd be highly pissed we couldn't restore the system to the minute of the crash.
Which we've had to do a couple of times after "unfortunate incidents".
You also need to consider how long it will take you to do the restore from the backup.
Again, of course. PCI compliance auditors make us, quarterly, restore a full database to a test rig, and yearly do a complete DR test at our Sungard cold site.
Stove-piped systems have the benefit that data can accumulate on one machine while we restore the "next phase" system. Only the customer-facing system needs to be clustered/hot-failover, etc.
dump all of our interesting data onto it overnight
How much? We back up 10+ TB every night, across a range of mid- and mainframe systems.
We're going to looking to ... real time backup from the databases using transaction logs.
We've been doing this for decades. (Since at least 1984 on OpenVMS, and most probably earlier. It's the Durability in ACID.)
not any more difficult than tapes.
But disks are much more fragile. A dropped "box" (that's how Iron Mountain keeps track of them) of tapes is much less likely to result in damage than dropping that same box of disks. Same with throwing the box into the back of a truck and hauling them back and forth to the off-site warehouse.
Both are bulky
IDE drives are ~30% larger (by volume) than DLT & LTO tapes, and that doesn't include the padding needed to protect hard drives.
NAS devices are cheaper and faster now. Lower end removable drives are not much more expensive than tapes, and they are a lot faster and easier to manage.
Having 21 days of off-site backups stored on NAS is kinda difficult.
If you have lots of data, I don't see how tapes are really going to do the daily backup jobs.
More tape drives, idiot, and parallel backups. Mainframes and OpenVMS have been doing it that way for decades.
As a game developer, I'm kind of annoyed how trivializing this is to the development process. A great game can take a team of ...
I think it would be adequate if you "just" ensured that games worked well under Wine, or, more practically, it's game-specific derivatives.
http://www.codeweavers.com/products/cxgames/
http://www.cedega.com/
Sitting here in my recliner typing this,
The heat from under the machine is cooking your testicles, making you sterile.
my old 8 lb luggable
That's not luggable. This is luggable!
I understand the benefits of kms, but I also see the downside consequences of the combination of
if Keith Packard thinks it's a good idea, I'm inclined to trust him
argumentum ad verecundiam, a logical fallacy.
You will still be able to boot headless with a serial line and a dumb terminal, if that's what you want.
That's just a silly argument.
You will still be able to boot into text and run startx.
Unless the distro boot process kms and dri really early in the boot process.
They also can be disabled. Nobody's forcing you to use them.
How, if it's initiated early in the boot process?
Also, I _like_ the smoothness of console switching which KMS gives.
Smooth console switching is totally useless to me, probably because I don't use a dm.
Yeah, nice theory - except what actually happens is you have two different drivers both talking to the same hardware, and not talking to each other. The usual failure mode when it really does fail is to confuse things so much that the console driver doesn't work either.
But a reboot into the text-only console would fix that, which wouldn't happen if Plymouth loaded kms during boot.
Sorry, don't get it.
Threw me for a loop, too, at first.
I think the difference in that BSODs (used to?) happen quite frequently in Windows, and that, not the blue panic screen, was/is the real issue. The BSOD was just a visible, and therefore easy to criticize, manifestation of Windows' suckiness.
OTOH, bug-related (as opposed to those caused by failing hardware) kernel panics are pretty infrequent in Linux.
The converse, actually.
That's what I meant. Really!
Anyway, is DRM/DRI essentially what the nvidia binary driver and OSS layer currently do?
(I use it, but it doesn't get loaded until needed by X.)
Just add "nokms" parameter to the kernel command line and it'll start kernel without kernel mode-setting
support, in a plain old console.
What about all the gooey goop (Plymouth & Wayland) that RH and Ubuntu are layering on top of the boot process to make it dumber (I mean more user friendly) which specifically depend on kms?
people like you are why linux won't ever dominate the computer industry. try growing up and learning from your mistakes.
It is well documented that people who don't know WTF they are doing regularly screw up their computers and allow them to become rampantly infected by malware.
Thus, it is only rational to think that people who don't know how to administer a computer should not perform administrative tasks and have administrative privileges.
If that means that 95% of households that currently have computers shouldn't have them, so be it.
Elitist? Hell yes!
If you have the command line as a failsafe for when X fails
Thank you for elucidating my intent. Foolishly, I assumed that people understood what I meant.
Let me put it to you in a way that should impress you: Kernel modesetting allows things like the Windows BSOD and the Mac Kernel Panic,
My Linux system hasn't panicked in many, many years (probably because I stick with relatively standard h/w), so no, it doesn't impress me much.
which means that when your kernel dies you can get a direct, immediate error message with details.
Wouldn't you also need DRI/DRM for that?
You don't really understand the consequences of doing kernel mode setting then.
Why am I not surprised???
None of your use cases will be impacted by the addition of kernel mode setting,
Interesting. Will the GEMified drivers require DRI/DRM? (Everything I've read about it seems to imply that.)
except that you'll be able to more easily get different resolutions out of your virtual consoles (you can already do that with framebuffer consoles, sometimes, depending on the hardware, and what driver you're using with X (if any)).
By using startx, I have no need for VCs. (I tried booting in different vga= modes, but it was too weird for eyes that are so used to 24x80...)
when you then have to get someone in to do the job properly
Hah hah hah hah hah hah.
Incompetent managers are usually expert at CYA, muddling thru, first denying that there's a problem, then blaming the database, then the DBA, then the hardware and then the specs. All while regularly releasing minor update after minor update, patching this open wound or that.
It has a fully functioning GUI right away
That does not impress me.
at 640x480
That really does not impress me.
This allows people who are not so technically proficient to fix their computer without having to resort to using a command line.
Cry me a river.
A memory manager for the graphics memory is very useful because it allows direct rendering and direct redirected rendering and such.
A definite step in the wrong direction.
One of the things I've always liked about *nix is the separation between kernel and graphics.
No matter how horked X is, I the system always boots in text mode console and work to repair X or a driver, install new software, etc, and even accomplish things with Mutt and links2.
Then, when I'm ready to "go graphical", simply run startx.
I never get jokes
Maybe you're demented.
http://www.cosmosmagazine.com/news/2428/sarcasm-useful-detecting-dementia
You underestimate the American capacity for enforcing their will on developing countries.
I don't see us being very successful in Columbia, Zaire, Afghanistan or Pakistan, and only slightly successful in Iraq.
Computers SHOULD be designed for people who have no knowledge of the intricacies of operating systems.
Depends on what they are going to do with them. See below.
Computers SHOULD be designed to be safe for beginners to use.
Yes, to use. But they will always need knowledgeable people to manage them, and any attempt to overcome this fundamental law of nature is doomed to cause lots of people to be infected by lots of malware.
never need anything other than a working pair of hands to charge it
I only have 1 functioning hand...