Vibrant doesn't mean much of anything to me... About as much as audio sounding "warm".
It sounds like "vibrant" to them simply means over-saturated. It wouldn't be difficult to tweak ANY of the images to be more "vibrant".
It's really impossible to tell which photo more faithfully reproduces the actual scene, without seeing it in person. The Nokia may work well on animation colors, but if people come out high-contrast, looking more like cartoons, it's not a good camera.
I guess you're right - globalism isn't lowering the cost of goods for the lowest sectors of society at all.
It's lowering the cost of goods... But it's reducing salaries at a MUCH FASTER pace. That's quite well established.
Those who don't get immediately screwed will see a small immediate benefit, but they too will get their salaries reduced, and soon. It's saving money on the float. The prisoners dilemma of big-box retail shopping.
Somebody should tell Wal-Mart that they can't afford to keep undercutting every other retailer out there, thus delivering huge savings to the poorest sectors of the economy.
Wal-mart is the standard case of false economy. You can buy a no-name TV from Wal-mart for a few dollars less than you can elsewhere, but you're getting junk that's going to fail in much less time, and is likely to use-up more power than the slightly more expensive equivalent at non-Wal-mart stores.
No, it didn't. It had the Explorer shell, unlike NT 3.51, but NT4 was NOT Plug-and-play, it did not have a device manager, driver installation, system management, and the like, were nothing like 9x. Tasks which should be simple, like installing a sound-card driver were 10-step processes. The interface for setting an IP address was alien enough that I know many people kept setting a static IP address for their dial-up modem, and couldn't figure out how to show or change the setting for their actual ethernet NIC.
As an added bonus, if even one of the system drivers you have installed could not be initialized on boot-up, you got a blue-screen, and you really had to know NT4 to figure out how to work-around it... No "safe mode" for you. With 2000/XP, the only such fatal BSOD is if you changed your HDD controller, such as when swapping motherboards from an Intel to a VIA.
It just had crappy graphical and end-user application support.
Actually, the overwhelming majority of Win32 apps ran on NT4 just fine. Most DOS apps as well, with the exception of things like games and BIOS tools, which wanted direct hardware access.
Windows 2000 remedied a lot of that, with better OpenGL and so on, and actually having DirectX.
NT4 had DirectX (2?) from the very beginning. It was updated about every other service pack, to 3, then 4, and finally a stand-alone DirectX installer was released to update NT 4.0 to DirectX 6, which was the last version.
No, it wasn't. It was incredibly flaky. I go back and try using old OSes from time to time, and it was just a month ago I tried 98 once again...
The slightest thing would cause it to crash... un-plug a USB device at the wrong time, and BSOD. Hell, even pull out a floppy disk or CD before the light goes completely off, and you're better-off rebooting than trying to get out of it.
If a single process was using a lot of resources, the system would be so incredibly unresponsive that you'd probably wait 30 minutes for the end-task dialog to finally come up, and then it would be mis-drawn, so you couldn't see what you were doing... and it wouldn't actually work, killing the task, anyhow.
Unlike NT, 9x didn't even attempt to recover freed RAM... When you first start-up everything was fairly snappy. Once you've used a few programs, you can't even play a video smoothly.
I can't even imagine how much power was wasted by Windows 9x, as they didn't idle the CPU, even when nothing was happening. This issue, like the hundreds of others, needed to be handled by buying hundreds of dollars worth of 3rd party software to fix such stupid limitations.
The Windows registry would regularly corrupt itself, for absolutely no reason. Install some software, and hope scanreg doesn't show-up when you reboot...
Drivers were always flaky, and every single new one you installed required rebooting. Then, changing settings, like your IP address required rebooting again. Then, for some reason, after a week of use, it suddenly decides it doesn't like your display driver, and silently disables it, and you start up in VGA mode for no reason...
And that's all just the tip of the iceberg. Most everyone was accustomed to just having Windows developing errors for no reason, and simply putting up with that crap for a couple months, until it becomes unbearable, and they reinstall the whole thing.
I remember hearing plenty of home users telling me about their great computer set-ups (workaround for Windows)... They usually bought copies of Ghost or similar, and simply made a clean image of their Windows 98 installs with all their software, so that they could just restore the HDD image on a regular basis, and not be concerned with Windows problems.
When I got a computer with Windows 98, I used it for about 6 months, and 4 reinstalls. After that, I spent a lot of money to buy a copy of Windows NT4, and despite having to figure out NT4's quirks, I had a Windows system that just worked, and continued using it for years. Though, it was about that time that I started dual-booting Linux, and you can probably guess the story from there.
Windows NT4 was a bit too quirky to recommend to average home users. When 2000 came out, however, it gave NT a friendlier, 9x-like interface. To this day, I continue to recommend 2000 to anyone who needs Windows. It has much lower resource requirements than XP, and far less than Vista, yet it can run all the same software, and can usually even use the same (XP) drivers. With software like nLite, you can strip 2000 down smaller and faster than 98 could hope to be, including removing IE, if you don't mind being cut-off from using a lot of software which requires it, including the default Add/Remove control panel (Hint: Appwiz.cpl runs just fine on 2000, and doesn't require IE).
Every time I have to upgrade my machine I have to spend an hour on the web working out the 700 different kinds of processor I can buy and what type of socket I need to support them.
Those days have long since passed. Socket 939 CPUs work in 939 motherboards. AM2 chips work in AM2 motherboards, etc. The socket A days had the occasional unpleasant compatibility surprises, but with decent quality motherboards, any chip would work, though perhaps at a slightly lower speed on an older board. That was still worlds better than the Socket 7 days.
It sounds like, however, you were in the Intel camp, where they had 4+ different sockets at any one time. That isn't exactly over, but at least they have less variety now...
I had an AMD Duron 800MHz that I tried to replace with an Athlon 1300MHz which should have been supported, but created a nifty column of smoke when I plugged it in.
Any jumpers (or dip switches) on the motherboard? If so, you should really have checked if they needed to be changed. If not, your board might not have been able to supply a low enough voltage that your new chip needed. Unfortunately, with mobile chips like Turions, you still have to find a list of boards that support low enough voltages.
AM2 was probably a misstep, given the performance drops, giving intel the upper hand,
That's just wrong. AM2 was simply AMD switching to DDR2 RAM. It didn't cause a performance drop, just no immediate performance improvement over socket 939 with DDR, and there's nothing they could have done to change that, except trying to force manufacturers around the world to produce faster DDR RAM.
Even with the higher latency of DDR2, AMD still has a much faster bus, and lower latency, than Intel. And even if the opposite were the case, there's no benefit to AMD of switching... Their on-board memory controller is a big benefit of AMD64, and switching to the standard FSB model would be a serious step backwards for them in performance.
it helps AMD more than it hurts them.
Except for the fact that you haven't the slightest idea what you're talking about...
Back in the late 80's or early 90's couldn't you swap out processor's? I admit I didn't know much back then but I thought that was how AMD and Cyrix got started, on boards meant for Intel CPU's.
Yup, that's how they got started... Right before Intel sued them.
Because of Intel's second-supplier contract with IBM, AMD earned the right to continue using Intel's existing (Socket 7) board, but not future boards, which was the birth of the Athlon and Slot A (later Socket A) boards.
Cyrix did a little patent-trading with Intel, and earned a few years' reprieve. In the interim, they invented their own (FSB) protocol, and included it in all their Intel-board chipsets... So while VIA CPUs aren't using Intel's patented communications protocols, they will still plug-in to any Intel motherboard with a VIA chipset, and work normally.
Linux generally isn't the technical winner at any particular task, IMO. But anyone is free to make it arbitrarily good or arbitrarily suit their purpose, and the mainstream, non-tinkering linux user gets something pretty good as a result.
Why not the same for hardware?
Because hardware isn't, and can't be made, at zero cost. Making changes is expensive. Making copies is expensive. Modifying existing designs may be more expensive than starting from scratch, anyhow.
If Linux required a $1,000 license, how popular do you think it would be?
there is a lot of really, really badly made hardware out there. the software people are clever enough to reverse engineer the hardware and write drivers. Why not put a few of them to work forward engineering the hardware?
I don't believe I can reasonably even count all the reasons why not, let alone explain them all here...
First, I'd say economies of scale... The fewer people buy it, the more you'll have to charge, and the more you charge, the fewer people will buy one...
Another is the pace of technology... Every time hardware changes, you have to update the design, and start building new hardware... eg. DDR to DDR2 RAM, Socket 939 to AM2, etc., etc.
To be a real option, you're going to have to have different form factors for hardware. With motherboards that means ATX, microATX, nanoATX, and whatever else. For graphics that means PCI, AGP 2/4/8X, etc., as well as PCIe, and integrated chipsets for the purpose as well.
Additionally, while creating drivers for undocumented hardware is quite difficult, it's still at least an order of magnitude easier to send bytes to a device and see what they do, than it is designing an efficient chip, even for something simple like sound.
But the point that I think cuts directly to the heart of the issue is: If people were willing to standardize on a single reference platform, as dictated by an open source guru, you could just start doing that tomorrow... Name the CPU, name the motherboard, name the sound card, graphics, etc., etc. Then everyone's efforts are focused on a single set of hardware, with working drivers for that small set of hardware, etc.
That would be using normal economic forces to your advantage, instead of trying to fight market forces, and enter the market yourself. It could make open source a valuable bloc of customers for any company who can offer reliable and documented products. The problem is, of course, that nobody is going to accept those terms. People want to use the hardware they have, and don't want to be restricted to the lowest common denominator hardware, lacking the features, specs, or the form factor they want.
As has already been said by others, a hardware review site, which extensively tested equipment for 100% correctness, all-around quality, and open source compatibility, would be extremely valuable, and much more helpful than an over-priced reference platform.
As far as the end user is concerned, what's the practical difference between a BSOD and a resource hog which causes the GUI (but not any other services which aren't immediately visible to the user, eg. printing, networking) to lock up?
First of all, nothing should lock-up the GUI. As a user, even if you are running a resource hog of a program, the GUI might be slower to respond, but you don't have a high enough priority to make it completely unresponsive.
So, the later case can be solved by a CTRL+ALT+DEL, while a BSOD is a real, unrecoverable, crash.
So what exactly does 'sysctl -d hw.acpi.reset_video' return on your system?.
hw.acpi.reset_video has nothing to do with switching VTs.
Or 'sysclt -d hw.syscons.sc_no_suspend_vtswitch'?
You're right that I was not aware of that one, because it isn't under hw.acpi. From your description, I assumed you were talking about the default behavior... ie. even with that set to 0, it switches to tty0 before powering down, except that X11 often freezes-up instead.
I don't understand the emotional aspect of your comments,
And I don't understand what makes you think there was anything emotional about my comments.
and blanking isn't enough;
I don't follow. Off is off. My notebook's screen shuts off just as well as my desktop monitor. Perhaps you're talking about something Radeon-specific?
Spinning down disks, albeit potentially problematic (disk life, for one), isn't exactly impossible. If it were, all those Mac or XP notebook users would be bitching along with you.
Spinning down notebook drives is vastly different than desktop drives, due to speed and weight. Notebook drives typically save power even if they have to be spun-up for a second, every minute or two. That's simply not the case with desktop drives, where that would be a serious power drain, as well as disk life issue.
That's not to say conserving energy isn't important. Only that what you think is ideal can be inappropriate in other circumstances.
Yes, well you haven't even outlined any circumstances where that might be the case. "Yes it is" "No it isn't" isn't much of a subject for debate.
You do know that zzz is a script that invokes acpiconf?
Yes. I also know xautolock does practically the same thing as xscreensaver, but I didn't feel any need to explain that. What was your point?
you should never end up with a corrupted filesystem.
Hate to tell you, but that's exactly what happens. You can't guaranty file system consistency when doing out-of-order writes. That's among the main reasons Ext3 does a full "fsync" every 6 seconds. It's a serious limitation of Ext2 in it's default mode. You're simply playing Russian Roulette with your data, and eventually you'll lose.
You certainly don't have to take my word for it. It's a well known issue, and there are several write-ups of it.
or the problem could in fact be Apple's for something in the QuickTime code that's at fault.
No, it couldn't... If you're running as an unprivileged user, the software you run shouldn't possibly be able to crash your OS.
Drivers can, and bugs in the OS can. User-run programs can only (accidentally) trigger one of those... in which case, that's a DoS exploit in the system.
noatime prevents reads from making journal transactions which spin up the disk.
No, it doesn't affect the journal activity at all. atime is absolutely not the main problem with modern file systems spinning down.
They need to constantly update the journal, or other file system info, atime or no, every few seconds to assure whatever fsck program, that the fs info contained in the journal or elsewhere is up-to-date. Of course that COULD be worked around, but that's how modern file systems work, and it's certainly not worth changing, at least for home users, who will get a trivially small power saving from it.
Easy workaround: Don't use a journaling filesystem.
On Linux, that's not easy at all, and noflushd appears to be Linux-only.
The only reasonably capable, non-journaled file system is Ext2. Using Ext2, you have the choice of either mounting it read-only, and getting horrible performance, OR leaving it async (default) and running an extremely high risk of corrupting your entire file system in the event of power outage, or other system crash... Note: that means corrupting your ENTIRE file system, not just losing the file you're downloading.
I ran afoul of that multiple times in my early Linux days, and the issue has been much written about, since.
We can go with your theory that you can't do this, or we can go with my experience that I have done it, and it works....
Mine isn't a theory, it's simple knowledge.
I don't know about you, but I'm going to assume that I didn't imagine the last nine years.
What you're probably imagining, is that it's a reliable or well-performing option, in the slightest.
chvt isn't installed on FreeBSD, it isn't available in ports, Freshmeat.net doesn't know about it, a web search turned up man pages for it but no source code, etc., etc.
If your present car doesn't work for you, and the new cars you can buy do no better, it's obvious that you shouldn't buy one, no?
Just because cars have certain limitations, doesn't mean newer cars won't be better in numerous other ways. If you go out of your way to list the issues that have not, and perhaps cannot be improved, that's just bullshit logic... Unless those issues are total and utter show-stopping issues (as opposed to your list of annoyances).
On second though, I just looked-up noflushd, and it seems it also absolutely won't help at all:
Journaling filesystems like ext3, reiserfs or xfs bypass the kernel's delayed write mechanisms. This amounts to lousy spindown times when working off such a partition. There's no workaround for this. http://noflushd.sf.net/
No you don't, and in fact if you mount your filesystem read-only, or noatime, and run noflushd your hard drives can spin down indefinitely as long as your dataset fits in memory.
Perhaps noflushd will work, however, I don't know any details about how it works, and you may well risk corrupting your filesystem. Just mounting a fs noatime certainly won't work, and yes, read-only filesystems can spin-down, but that's not the situation we're talking about here.
Perhaps, but the issue is a lot more complicated than that. We're talking about the BIOS, the OS, and then how the two relate to each other.
It's certainly complicated, but FreeBSD seems to have the most people putting in effort to get it working, working-around bugs in the hardware, etc.
I'm going by memory here, but IIRC, that's handled with a sysctl. You shouldn't need to manually do anything.
First, there's no sysctl. Second, yes, it is supposed to handle it automatically, but it's buggy, so manually doing it is the only way to be sure. Though, I could have sworn I said that the first time...
I'm not sure you want an S3 state every few minutes.
You're wrong.
It would make more sense to blank the screen (and kill the backlight on a notebook) by setting the DPMS option in xorg.conf, and set your screensaver options in.Xdefaults. The CPU can be trottled using any number of methods either on a dynamic basis, or at set time. Throw ataidle into the mix and you've got most everything you need for those "every few minutes' intervals.
You've clearly never done ANY of this.
Setting X to blank the screen after 10 minutes is something I've been doing on every install for the past decade now.
You can't spin-down any hard disks that is mounted. File systems are too advanced these days. Whether journaling or not, they all write fs metadata every few seconds.
Idling your CPU is good, and should be done by default everywhere by now.
For comparison, my system, with CPU idled, uses 60W. In S3 Suspend, it uses 3W... That's a huge difference, and WHY everyone should suspend their systems after a few minutes of idle time, if possible.
For a full suspend after x minutes, why not script your own approach? One option would be to use xscreensaver-command to invoke a count-down timer to invoke zzz(8)?
I did, except with xautolock and acpiconf -s3. As I've repeatedly said, there has to be somebody there to hit CTRL+ALT+F1 or else there's a high chance the system will crash when it resumes.
All available options can be listed by running "sysctl -a hw.acpi" and included in/etc/sysctl.conf to be automatically set upon boot-up. Basically you'll only need "hw.acpi.reset_video=" set to 0 or 1 depending on your system.
If you need to unload modules or any other action before suspending, see/etc/rc.suspend. Put the opposite commands in/etc/rc.resume.
That should be everything you need. Either your hardware will work, or it won't. In the latter case, strip your system down to nothing but video, and try different video cards. Then add a piece at a time to see what's causing problems.
Slashdot Mirror
Vibrant doesn't mean much of anything to me... About as much as audio sounding "warm".
It sounds like "vibrant" to them simply means over-saturated. It wouldn't be difficult to tweak ANY of the images to be more "vibrant".
It's really impossible to tell which photo more faithfully reproduces the actual scene, without seeing it in person. The Nokia may work well on animation colors, but if people come out high-contrast, looking more like cartoons, it's not a good camera.
In other words, this article is utterly useless.
It's lowering the cost of goods... But it's reducing salaries at a MUCH FASTER pace. That's quite well established.
Those who don't get immediately screwed will see a small immediate benefit, but they too will get their salaries reduced, and soon. It's saving money on the float. The prisoners dilemma of big-box retail shopping.
Wal-mart is the standard case of false economy. You can buy a no-name TV from Wal-mart for a few dollars less than you can elsewhere, but you're getting junk that's going to fail in much less time, and is likely to use-up more power than the slightly more expensive equivalent at non-Wal-mart stores.
No, it didn't. It had the Explorer shell, unlike NT 3.51, but NT4 was NOT Plug-and-play, it did not have a device manager, driver installation, system management, and the like, were nothing like 9x. Tasks which should be simple, like installing a sound-card driver were 10-step processes. The interface for setting an IP address was alien enough that I know many people kept setting a static IP address for their dial-up modem, and couldn't figure out how to show or change the setting for their actual ethernet NIC.
As an added bonus, if even one of the system drivers you have installed could not be initialized on boot-up, you got a blue-screen, and you really had to know NT4 to figure out how to work-around it... No "safe mode" for you. With 2000/XP, the only such fatal BSOD is if you changed your HDD controller, such as when swapping motherboards from an Intel to a VIA.
Actually, the overwhelming majority of Win32 apps ran on NT4 just fine. Most DOS apps as well, with the exception of things like games and BIOS tools, which wanted direct hardware access.
NT4 had DirectX (2?) from the very beginning. It was updated about every other service pack, to 3, then 4, and finally a stand-alone DirectX installer was released to update NT 4.0 to DirectX 6, which was the last version.
No, it wasn't. It was incredibly flaky. I go back and try using old OSes from time to time, and it was just a month ago I tried 98 once again...
The slightest thing would cause it to crash... un-plug a USB device at the wrong time, and BSOD. Hell, even pull out a floppy disk or CD before the light goes completely off, and you're better-off rebooting than trying to get out of it.
If a single process was using a lot of resources, the system would be so incredibly unresponsive that you'd probably wait 30 minutes for the end-task dialog to finally come up, and then it would be mis-drawn, so you couldn't see what you were doing... and it wouldn't actually work, killing the task, anyhow.
Unlike NT, 9x didn't even attempt to recover freed RAM... When you first start-up everything was fairly snappy. Once you've used a few programs, you can't even play a video smoothly.
I can't even imagine how much power was wasted by Windows 9x, as they didn't idle the CPU, even when nothing was happening. This issue, like the hundreds of others, needed to be handled by buying hundreds of dollars worth of 3rd party software to fix such stupid limitations.
The Windows registry would regularly corrupt itself, for absolutely no reason. Install some software, and hope scanreg doesn't show-up when you reboot...
Drivers were always flaky, and every single new one you installed required rebooting. Then, changing settings, like your IP address required rebooting again. Then, for some reason, after a week of use, it suddenly decides it doesn't like your display driver, and silently disables it, and you start up in VGA mode for no reason...
And that's all just the tip of the iceberg. Most everyone was accustomed to just having Windows developing errors for no reason, and simply putting up with that crap for a couple months, until it becomes unbearable, and they reinstall the whole thing.
I remember hearing plenty of home users telling me about their great computer set-ups (workaround for Windows)... They usually bought copies of Ghost or similar, and simply made a clean image of their Windows 98 installs with all their software, so that they could just restore the HDD image on a regular basis, and not be concerned with Windows problems.
When I got a computer with Windows 98, I used it for about 6 months, and 4 reinstalls. After that, I spent a lot of money to buy a copy of Windows NT4, and despite having to figure out NT4's quirks, I had a Windows system that just worked, and continued using it for years. Though, it was about that time that I started dual-booting Linux, and you can probably guess the story from there.
Windows NT4 was a bit too quirky to recommend to average home users. When 2000 came out, however, it gave NT a friendlier, 9x-like interface. To this day, I continue to recommend 2000 to anyone who needs Windows. It has much lower resource requirements than XP, and far less than Vista, yet it can run all the same software, and can usually even use the same (XP) drivers. With software like nLite, you can strip 2000 down smaller and faster than 98 could hope to be, including removing IE, if you don't mind being cut-off from using a lot of software which requires it, including the default Add/Remove control panel (Hint: Appwiz.cpl runs just fine on 2000, and doesn't require IE).
No it won't.
Those days have long since passed. Socket 939 CPUs work in 939 motherboards. AM2 chips work in AM2 motherboards, etc. The socket A days had the occasional unpleasant compatibility surprises, but with decent quality motherboards, any chip would work, though perhaps at a slightly lower speed on an older board. That was still worlds better than the Socket 7 days.
It sounds like, however, you were in the Intel camp, where they had 4+ different sockets at any one time. That isn't exactly over, but at least they have less variety now...
Any jumpers (or dip switches) on the motherboard? If so, you should really have checked if they needed to be changed. If not, your board might not have been able to supply a low enough voltage that your new chip needed. Unfortunately, with mobile chips like Turions, you still have to find a list of boards that support low enough voltages.
That's just wrong. AM2 was simply AMD switching to DDR2 RAM. It didn't cause a performance drop, just no immediate performance improvement over socket 939 with DDR, and there's nothing they could have done to change that, except trying to force manufacturers around the world to produce faster DDR RAM.
Even with the higher latency of DDR2, AMD still has a much faster bus, and lower latency, than Intel. And even if the opposite were the case, there's no benefit to AMD of switching... Their on-board memory controller is a big benefit of AMD64, and switching to the standard FSB model would be a serious step backwards for them in performance.
Except for the fact that you haven't the slightest idea what you're talking about...
Yup, that's how they got started... Right before Intel sued them.
Because of Intel's second-supplier contract with IBM, AMD earned the right to continue using Intel's existing (Socket 7) board, but not future boards, which was the birth of the Athlon and Slot A (later Socket A) boards.
Cyrix did a little patent-trading with Intel, and earned a few years' reprieve. In the interim, they invented their own (FSB) protocol, and included it in all their Intel-board chipsets... So while VIA CPUs aren't using Intel's patented communications protocols, they will still plug-in to any Intel motherboard with a VIA chipset, and work normally.
Because hardware isn't, and can't be made, at zero cost. Making changes is expensive. Making copies is expensive. Modifying existing designs may be more expensive than starting from scratch, anyhow.
If Linux required a $1,000 license, how popular do you think it would be?
Don't worry. He's just new there. He'll become utterly detached from reality soon enough.
I don't believe I can reasonably even count all the reasons why not, let alone explain them all here...
First, I'd say economies of scale... The fewer people buy it, the more you'll have to charge, and the more you charge, the fewer people will buy one...
Another is the pace of technology... Every time hardware changes, you have to update the design, and start building new hardware... eg. DDR to DDR2 RAM, Socket 939 to AM2, etc., etc.
To be a real option, you're going to have to have different form factors for hardware. With motherboards that means ATX, microATX, nanoATX, and whatever else. For graphics that means PCI, AGP 2/4/8X, etc., as well as PCIe, and integrated chipsets for the purpose as well.
Additionally, while creating drivers for undocumented hardware is quite difficult, it's still at least an order of magnitude easier to send bytes to a device and see what they do, than it is designing an efficient chip, even for something simple like sound.
But the point that I think cuts directly to the heart of the issue is: If people were willing to standardize on a single reference platform, as dictated by an open source guru, you could just start doing that tomorrow... Name the CPU, name the motherboard, name the sound card, graphics, etc., etc. Then everyone's efforts are focused on a single set of hardware, with working drivers for that small set of hardware, etc.
That would be using normal economic forces to your advantage, instead of trying to fight market forces, and enter the market yourself. It could make open source a valuable bloc of customers for any company who can offer reliable and documented products. The problem is, of course, that nobody is going to accept those terms. People want to use the hardware they have, and don't want to be restricted to the lowest common denominator hardware, lacking the features, specs, or the form factor they want.
As has already been said by others, a hardware review site, which extensively tested equipment for 100% correctness, all-around quality, and open source compatibility, would be extremely valuable, and much more helpful than an over-priced reference platform.
First of all, nothing should lock-up the GUI. As a user, even if you are running a resource hog of a program, the GUI might be slower to respond, but you don't have a high enough priority to make it completely unresponsive.
So, the later case can be solved by a CTRL+ALT+DEL, while a BSOD is a real, unrecoverable, crash.
hw.acpi.reset_video has nothing to do with switching VTs.
You're right that I was not aware of that one, because it isn't under hw.acpi. From your description, I assumed you were talking about the default behavior... ie. even with that set to 0, it switches to tty0 before powering down, except that X11 often freezes-up instead.
And I don't understand what makes you think there was anything emotional about my comments.
I don't follow. Off is off. My notebook's screen shuts off just as well as my desktop monitor. Perhaps you're talking about something Radeon-specific?
Spinning down notebook drives is vastly different than desktop drives, due to speed and weight. Notebook drives typically save power even if they have to be spun-up for a second, every minute or two. That's simply not the case with desktop drives, where that would be a serious power drain, as well as disk life issue.
Yes, well you haven't even outlined any circumstances where that might be the case. "Yes it is" "No it isn't" isn't much of a subject for debate.
Yes. I also know xautolock does practically the same thing as xscreensaver, but I didn't feel any need to explain that. What was your point?
Ignorance won't make the problem go away.
No, I mean CORRUPT. As in data loss. Seemed a pretty simple term.
Hate to tell you, but that's exactly what happens. You can't guaranty file system consistency when doing out-of-order writes. That's among the main reasons Ext3 does a full "fsync" every 6 seconds. It's a serious limitation of Ext2 in it's default mode. You're simply playing Russian Roulette with your data, and eventually you'll lose.
You certainly don't have to take my word for it. It's a well known issue, and there are several write-ups of it.
No, it couldn't... If you're running as an unprivileged user, the software you run shouldn't possibly be able to crash your OS.
Drivers can, and bugs in the OS can. User-run programs can only (accidentally) trigger one of those... in which case, that's a DoS exploit in the system.
Pretty unlikely it will even work on FreeBSD, then.
No, it doesn't affect the journal activity at all. atime is absolutely not the main problem with modern file systems spinning down.
They need to constantly update the journal, or other file system info, atime or no, every few seconds to assure whatever fsck program, that the fs info contained in the journal or elsewhere is up-to-date. Of course that COULD be worked around, but that's how modern file systems work, and it's certainly not worth changing, at least for home users, who will get a trivially small power saving from it.
On Linux, that's not easy at all, and noflushd appears to be Linux-only.
The only reasonably capable, non-journaled file system is Ext2. Using Ext2, you have the choice of either mounting it read-only, and getting horrible performance, OR leaving it async (default) and running an extremely high risk of corrupting your entire file system in the event of power outage, or other system crash... Note: that means corrupting your ENTIRE file system, not just losing the file you're downloading.
I ran afoul of that multiple times in my early Linux days, and the issue has been much written about, since.
Mine isn't a theory, it's simple knowledge.
What you're probably imagining, is that it's a reliable or well-performing option, in the slightest.
I looked, and found nothing.
chvt isn't installed on FreeBSD, it isn't available in ports, Freshmeat.net doesn't know about it, a web search turned up man pages for it but no source code, etc., etc.
Just because cars have certain limitations, doesn't mean newer cars won't be better in numerous other ways. If you go out of your way to list the issues that have not, and perhaps cannot be improved, that's just bullshit logic... Unless those issues are total and utter show-stopping issues (as opposed to your list of annoyances).
Perhaps noflushd will work, however, I don't know any details about how it works, and you may well risk corrupting your filesystem. Just mounting a fs noatime certainly won't work, and yes, read-only filesystems can spin-down, but that's not the situation we're talking about here.
It's certainly complicated, but FreeBSD seems to have the most people putting in effort to get it working, working-around bugs in the hardware, etc.
First, there's no sysctl. Second, yes, it is supposed to handle it automatically, but it's buggy, so manually doing it is the only way to be sure. Though, I could have sworn I said that the first time...
You're wrong.
You've clearly never done ANY of this.
Setting X to blank the screen after 10 minutes is something I've been doing on every install for the past decade now.
You can't spin-down any hard disks that is mounted. File systems are too advanced these days. Whether journaling or not, they all write fs metadata every few seconds.
Idling your CPU is good, and should be done by default everywhere by now.
For comparison, my system, with CPU idled, uses 60W. In S3 Suspend, it uses 3W... That's a huge difference, and WHY everyone should suspend their systems after a few minutes of idle time, if possible.
I did, except with xautolock and acpiconf -s3. As I've repeatedly said, there has to be somebody there to hit CTRL+ALT+F1 or else there's a high chance the system will crash when it resumes.
S3 mode is entered by running "acpiconf -s 3"
/etc/sysctl.conf to be automatically set upon boot-up. Basically you'll only need "hw.acpi.reset_video=" set to 0 or 1 depending on your system.
/etc/rc.suspend. Put the opposite commands in /etc/rc.resume.
All available options can be listed by running "sysctl -a hw.acpi" and included in
If you need to unload modules or any other action before suspending, see
That should be everything you need. Either your hardware will work, or it won't. In the latter case, strip your system down to nothing but video, and try different video cards. Then add a piece at a time to see what's causing problems.