Wow, descending into geekier territory... I don't recall Voyager that much, but I do know they called the freaky guy who came because Wesley was in some wierd way special in TNG traveler. And that guy had used his powers to make the enterprise go ludicrously fast (plaid even) into the middle of no where when he flipped out in that episode. Can't remember the details, but he was traveler, he made the enterprise go out into the middle of nowhere, and it was all to get the kid off the show... err I mean help him realize his powers.
It says he started by coining the phrase it's what's inside that counts. I coulda sworn *I* coined the prhase trying to get girls to go out with me back in high school!
How the hell can someone claim a phrase is being coined when it's such a generic phrase used everywhere?
What about logging consoles to do historical information, view kernel panics, see the last screen a server spit out before unplanned power down? Textual consoles have extreme merit in complex large datacenters. And I can open and monitor 25 consoles concurrently on my screen text wise without sweating throughput or performance if I'm doing something on a large set of nodes..
Serial remains one of the most manageable approaches to console management. Video is, obviously, not loggable, not automatically monitorable, not greppable, and not amenable to low throughput, high latency remote access.. Serial devices and consequently drivers for them are so simple and straightforward, and the behavior so deterministic, that it is far preferable to something more complex (ethernet and usb) for a console. Ethernet certainly in questionable circumstances may suggest a driver unload/reload as a step to problem resolution, which is safer if not using as a console (though many times I have used ssh and chained the commands using semicolons). For example in that case, if your path contains an nfs mount, and you forget about it as you yank the network out, your chained command will hang as the shell tries to stat the nfs mount for the path. Part of the problem with relying solely upon the ethernet for console is the ethernet has more than one job to do, so it takes a fair amount more competent engineering to get to work right. Many newer systems offer to redirect textual serial traffic over IPMI, and that is admittedly decent *if* the vendor architects it robustly, which is difficult to ensure beyond hands-on experience with a brand and trusting in their consistancy. For example, e326 servers from IBM I wouldn't trust the net console, but an IBM x3455 I would be more confident in. USB, again, has similar complexity issues (it's multiplexed for keyboard/mouse/mass/storage/printing/scanning/etc etc). If you theoretically had bi-directional text console over some usb device, it's more difficult for a low level, simple piece of software to set up the usb controller and all requisite activities, then traverse the bus, identify the console devices, and then use it. Just like with an ethernet device where you may have cause to unload and reload a driver, a usb controller out to lunch with respect to a mass storage device would cause a similar issue. Enterprise distribution kernels tend to compile in the serial console and leave the usb controller modular, specifically with serial consoles in mind.
Serial console servers, in answer to your question, provide a scalable way for systems to access via the network serial consoles. By being dedicated, moderately simple systems with 40+ serial cables, they can provide access (via telnet generally) to a rack's worth of 1U servers, automatically log the content, or at the very least provide an administrator with remote console access at will to any given system.
Serial console is not obsolete in the least bit, just because it can't run your '31337' aero interface, or whatever nice and shiny interface that makes poser administrators and PHBs drool, doesn't mean good, serious systems administrators don't consider the technology to be a vital part of a robust management strategy.
A characteristic common of multi-tasking RTOSs is that timeslices are very small, and context switches extremely frequent, to help assure that apps will be able to do something in the required timeline, which is not necessarily a small amount of time, but in many applications it is a short time. There are more complexities, but the bulk of the 'overhead' mentioned in the GP is probably the high percentage of time spent doing context switches rather than useful work. The key word here is multi-tasking RTOSs, you describe cases in which the OS is largely a base for a single application that does everything itself. This is very common in the RTOS world, but their do exist areas where pre-emptive multi-tasking RTOSes fulfill a need....
Of course, your point is correct too, a requisite step with respect to this particular aspect of a RTOS is generally considered to be doing whatever it takes to make the context switch as fast as possible. In a server or desktop OS historically context switches aren't nearly as optimized as the solution can be for most applications to lengthen the timeslice. Server platforms particularly tend to have long timeslices as their activity isn't highly interactive, and the percentage of the time the system can do useful work is more important than each application being able to do their thing in a timely manner. On a desktop OS, timeslices being shorter is helpful (fairly recently a lot of debate and configurability happened in linux with respect to this), as multiple applications are more directly interacting with users. With a handful of processes it isn't really noticeable but as it scales up the delays get into perceptible fractions of a second. Having a smooth interface is a bit more along the lines of a design point of RTOS, so it makes sense. Anyway, there is a penalty paid, but the timeslices for satisfying human interaction requirements may still be orders of magnitutde higher than those required for RTOS applications, depending on what's going on.
Xeons prior to Woodcrest did get stomped by Socket 940 Opterons, now with Intel Woodcrest dual-core vs. AMD Socket F dual cores, Intel I believe holds similar advantage that it does in the desktop line.
SDL wraps/can wrap audio/graphics/input, basically everything you just said. On MS platforms it frontends DirectX, so it's fairly obvious that they are aiming for a cross-platform DirectX alternative. I've programmed against it and it's pretty easy to use.
My mythfrontend referenced is also a diskless unit, whether Apple's will be diskless or not I've not seen confirmed, but as a reference with a diskfull server and 512MB of ram, I have a system with instant on (using ACPI sleep) that functionally is close to the previewed iTV, so Apple's undoubtedly gonna have it more smooth and tuned to the task, and what I acheived expect that to be the bare minimum of the set-top box's capability.
The massive amount of throughput required for raw streams would be impossible to trasmit, even over a good network, particularly not 802.11g... Decoding even HD streams is easy with video decoding offload. My 1.8 GHz AthlonXP under mythtv playing 1920x1080 streams has about 50% idle when using XvMC to assist with decoding (using the planar Geforce 6150), so their set top box should have no problem decoding even tough stuff.
You have a point, but the American Civil War largely doesn't mesh with it. Keep in mind the whole slavery thing wasn't an issue in the American Civil War until the Emancipation Proclamation (years into the war), and even then it was not so much as intrinsic concern over the basic human rights of slaves, but a political tool that both tinted the conflict in the world view (and obviously in the historical view), very much against the Confederacy. It also was a declaration that any states that chose to attempt to secede and fail would have their slavery abolished (to keep border states considering seceding from doing so). Note the phrasing of the proclamation was that slavery was abolished in all states 'in open rebellion', and didn't ban it anywhere else. If it were about human rights, it wouldn't have carried that condition. Ultimately the move was probably the biggest single step toward abolishing slavery, but if not for the immediate need for a political tool brought on by the war, the step would have come much later. So ultimately the South seceding caused slavery to be abolished sooner than it would have.
The american civil war is a much more complex situation than redneck southerners fighting to continue slavery, as a lot of people are taught/figure. If it had been, it would be a much more simpler thing to declare the Northern states as being in the right at the time, but it's not that clear cut (particularly in the first couple of years of th ewar).
As I said in my post, setting it up isn't admittedly the easiest thing in the world, but once it is set up, it ends up really easy to use. Setting it up as a single backend/frontend box (first thing I did) wasn't very hard. Even setting up a backend and frontend wasn't that much more so. Getting to a diskless system that can sleep I went through some convoluted stuff over the course of a few hours, but that is also the point where using Windows to acheive my goals becomes impossible, afaik. Maybe you could do something BartPE like, but ultimately the platform just wasn't designed for that stuff and even if possible, it probably would be as difficult or more so than what I did.
If you look piecewise at the parts I used, it costed about as much up front as a Tivo, but no monthly fees. I don't get cable (ditched it as all my content came from online or via major networks), so the cable provider DVR isn't an option, and if it were, another monthly fee. People at work with Tivos seem to be happy, other people who have other DVRs seem to complain, particularly from the cable company, about things like forced firmware upgrades that break frequently and such.
MCE doesn't have the flexibility for me to build what I want, and requires a higher hardware investment (i.e. another hard drive). Other DVRs aren't cheaper up front and/or come with a subscription fee to continue use, and in many cases are dodgy but without giving the users the ability to make it right or keep it right. MythTV fits my needs perfectly...
It enables me to make the ideal media setup, for me.
The potential for separation of backend and frontend allows me to have my loud, big, lots-o-storage system somewhere far away from my TV, and a quiet, yet affordable box with my TV.
My frontend is nothing but a micro ATX case with a motherboard (ASUS A8N-VM CSM), processor (Athlon XP64 3000), and 1 512M DIMM. No hard drive, no extra video card, booting diskless. Thanks to the linux base I'm able to PXE boot, and have a tmpfs root with about 40M of ram used, and nfs mount usr. Now I have a really slick frontend that I can sleep and resume, and it comes up in less time than my TV takes to turn on its lamp right back to whatever menu I left it at, but still have no hard disk whatsoever in it. It's very quiet, and passes the WAF test. The kind of power and flexibility I can get out of a mythtv on linux solution is far beyond anything that involves Windows (try having a fully persistant-storage free (including optical drives or usb storage) windows box that can run MCE and serve reliably as a frontend, persisting through all sorts of activity including sleep... My backend records OTA HD and uses a free service to get TV listings, no subscription, has everything stored on a software RAID5 with 4 250GB disks, and I can access it to make scheduling changes from anywhere via the web if someone say recommends a show while I'm at work. Can also download other media (i.e. fansubs), dump them in a particular directory tree, and the frontend can access it in an easy-to-use interface as well.
One thing I will say is that for more exotic configs, it naturally takes more work to set up than probably other things do, and in allowing the exotic configuration, a lot of confusing options end up facing the novice user (kinda like vi vs. notepad). Also, as it is only part of a full solution, it can't even simplify some config options because it quite frankly has no idea if the user will have a remote, if so what remote, if they will use a keyboard, maybe a joystick, if a joystick no idea on the keymapping... If it will be running backend and frontend type tasks on the same box, if separate the frontend may not know where the master backend is... It has various playback options that work better depending on your video card and such, and while they have a 'decent' default behavior, it doesn't de-interlace by default, doesn't enable any sort of sync to vblank by default, and doesn't enable XvMC by default, because it can't assume any of these are wanted or will perform right with the frontend's hardware. It could be assissted by a discovery architecture for the frontend (if localhost not responding, discover backends), and maybe a hardware/configuration database where it uses, say, lspci data and checks for XvMCConfig and other config files to have a better guess as to what the user can do, but it shouldn't sacrifice the power of it's configurability whatever may happen.
Once configured, it's slick and easy to use, no one has ever been confused by the interface that's used it at my house, I've never had to answer any questions pertaining to usage and once I got everything behaving correctly, I haven't had to touch configuration. Other people have scheduled recordings without being confused or anything, and that's about the hardest task left to do with the frontend. It could be leveraged as a part of a pre-configured solution where hardware and software config is already known (last I heard MCE had particular config requirements, so mythtv's ability to cope with a wider config probably contributes to this criticism).
I know I personally, and therefore scores of people who ever released an open-source project posted the tarball and fired the announce and within five-ten minutes realized they botched something and have a new version out...
Think it's really impossible to quantify 'Qucikest Patch Ever', but the one you point out may be in the running for quickest patch any significant amount of people gave a damn about..
IT depts. that are efficient and effective choose the software and hardware platforms they can support and standardize on it and provide support to those platforms. I accept this is a realistic expectation to set, an IT dept can only do so much and to fund an IT dept to be capable of doing all things for all people is just bad business.
IT depts however may lose some of that effectiveness and efficiency when they start mandating only what they approve is allowed and start taking proactive measures to keep employees in line. For example, most of my past was IT. I would depending on the company officially support whatever the company wanted to use. If that company approved of Solaris and Windows, and a Linux user called for software help, I would simply respond that I can't help them, but they are welcome to try to figure it out themselves or have me assist with a supported solution, even if I knew full well I could fix their problem if I gave a little time for it. A bad IT department may spend extra effort to reprimand the user for ever using linux and do all kinds of ungodly things to the infrastructure to more obviously break Linux clients as a deterrent in this example.
With a virtualization solution, the number of licenses required to be dealt with (Free licenses still have to be 'dealt with', i.e. make sure your usage legally matches the license) is at least four: -The host os -The virtualization software -The guest os -The application
For crossover it's three: -The host os -Crossover -The application
The Windows license is expensive, and if you have commercial support from Crossover office for the app, it's not something that 'might work 90%', it is something that the vendor is legally obligated to get to work 100%. Crossover is fairly specific about what they provide support for, and for those applications it isn't 9/10 assed, it's supposed to work right or they have to help you make it work right.
Add to that some complications in virtualization (overhead of full guest os in terms of storage, paradigm of switching between OSes intrusive (both in terms of interface and filesystem space). Virtualization is needed/appropriate for some desktop scenarios, and more server scenarios, but I'm just stressing the counterpoints to show crossover is not a solution made irrelevant by virtualization.
If Dell took AMD seriously in 2006 that would have happened, but not so sure about 2007..
Same with IBM, both only just now really started taking AMD seriously and did so just in time for Woodcrest to come and tip price-performance back to Intel systems. AMD still has the memory performance advantage, but Woodcrest/Conroe's 4 ops per clock and relatively aggressive pricing mean AMD has to do something. I don't know AMD's schedule for quad-core offhand, but know Intel Clovertown is supposed to be probably 2nd quarter of 07. It's possible that in going to quad-core Intel's memory architecture could choke them and give AMD a more thorough advantage, or that AMD also gets similar performance while going to quad-core as Intel gets with Woodcrest/Conroe and the scales tip to AMD again.
I have worked for companies with exclusive Compaq, Dell, and IBM deals and more or less they are all the same. Drives go on occasion in every one, I think I happened to see Dell have the most backlight failures (ironic, as the company with Dell was the smallest company with the fewest number of laptops, and I worked there fairly short term, and even the raw number of failures exceeds what I saw in compaq and thinkpads. I have seen one thinkpad backlight go. Li-ion batteries always degrade no matter who the vendor is, expect at least anual replacement if you want it to maintain more than 30% charge consistantly.
The whole recovery system is annoying, and par for the course nowadays, but I always wipe the drive and use linux anyway, so I don't miss the Windows media.
It also depends on the model maybe, I really like my current thinkpad, it has excellent viewing angle (so-called 'flexview' display, but I've seen a lot more thinkpads with typically crappy laptop screens.
I even got a keyboard for my workstation with a trackpoint because it appeals so much to me.
The positioning is perfect, the trackpoint is right there along the home row and the buttons are right next to my thumbs when touch typing. Before the trackpoint I hated any activity that involved alternating mouse and keyboard activity because I would have to drastically move my hand to the mouse or touchpad to use that, then move my hand back to the keyboard. The same crowd that desperately looks for keyboard shortcuts in applications ought to appreciate the trackpoint. I don't have to significantly alter my hand position to manipulate the pointer versus type. For games and similar mouse activity, only a mouse or trackball will do, but for day to day pointer manipulation, I'll take a trackpoint over a mouse or touchpad any day.
UltraNAV has been moderately useful for me, I used synclient to make the 'edges' take up the entire area and enabled circular scrolling, so I have an iPod like scroller to complement my trackpoint.
Trackpoint is perfect for the lazy, don't move my hands from the homerow to move the mouse or click. It's a little bit of a reach to scroll with the touchpad, but it is easier than using cursor keys or pgup/pgdown.
Still, I get really annoyed at the concept of the touchpad being the de-facto pointing device standard in laptops: -As the x-series demonstrates, touchpad takes up a lot of real-estate and makes it hard to do an ultra-portable -No tactile feedback, with trackpoint it exerts pressure and you have a more solid feel of tracking the cursor movement, whereas a touchpad you just glide over. -My hands have never ever accidentally manipulated a trackpoint. I run syndaemon to keep the touchpad disabled while typing, and disable everything but scrolling now, so it's not a big deal now (won't move or click the cursor even if I somehow typed really slowly and my wrist hits it), but the fact I have to do so much to make it not annoying is a bad sign. -I don't have to lift my fingers to continue mouse movement in a direction when I reach an edge, like in a touchpad.
Even if you have people in there with 4 or 5 SNESs that is a metric butt load of households with SNESs.
The name Nintendo is always going to be associated with gaming by non gamers... and parents will buy there children a N64 to replace/upgrade a SNES because it makes sense from a non informed consumers perspective.
(could also replace PS2/Sony with 2600/Atari for similar results, an established market means something, but it far from means as much as people give it credit for). Fact of the matter is that for the most part people aren't just sheep. More so than they should be, but when asked to shell out 600 bucks for something, they will consider it more thoroughly and not automatically buy it for their kids just because they had a PS2 and their kid liked the PS2.
To be fair, the Gamecube was fundamentally the same as PS2 and X-Box, the Wii is offering some potentially interesting innovation beyond 'more polygons, more lights, bigger discs'. Whether the Wii-mote will actually be fun or appealing remains to be seen, but it is an innovation that seems much more well executed and central compared to PS3's apparent last minute modification to mimick Wii and offset their likely legal-induced vibration function removal.
I never understood how the 'web hype' for Snakes on a Plane was ever expected to *help* the movie. Most of the 'web hype' was ridicule saying 'oh this movie is so campy, it makes me laugh'. You can tell from the marketing that the movie aimed to be somewhat serious, but the web hype and marketing all latched on to how campy it was. I think the people behind the movie were mistaken genuine ridicule for friendly jest, and called it web hype. Snakes on a Plane from all the 'web hype' I read was doomed to be a bad movie, and it lived up to what the web hype promised there.
Similarly, looking at the PS3 I see a lot of overconfidence on the part of Sony. The argument about price discrimination calling for such a high launch price ignores the obvious psychological effect of a high launch price even among those who wouldn't have been able to get one at launch anyway. Just cause some elitists/fanboys will buy your system no matter what, doesn't mean you scare away the more practical/indifferent gamers to gouge the elitists/fanboys for all they can.
The web discussions I think are more vital than people give it credit for. The target market for a 600 dollar console is clearly comprised of gaming enthusiasts, and most people like that are active participants in online discussions. The online discussions overwhelmingly are along the lines of 'at that price, no way'. From the time of launch to a significant price drop I predict PS3 will do poorly, and the question is if Sony recognizes it in time and their costs allow them to drop the price to prevent developer drop out. The effects of a weak launch may be difficult to overcome even if they do respond quickly, but it may be possible to pull it off.
Nintendo up to N64 was considered the nearly uncontested leader in the market. Despite having huge momentum leading up to, the N64 didn't do that well in the face of the newcomer Sony, and Gamecube hasn't done much better, and N64 wasn't as clearly overconfident as the PS3 seems to be. Admittedly the limitations of cartridges versus optical media played as well as poor third party relationships on the part of Nintendo played a role there whereas Sony is much healthier in those regards even with the PS3. Other apt comparison's in the price range are Neo-Geo and 3DO, both of which had significant hype and a lot of people saying 'these systems will be great', but no uptake because of the cost.
My strategy generally is to use a file for swap rather than a partition, even in linux. I figure that if memory has to be swapped in from disk, it's already crappy going to disk so the extra overhead doesn't matter much, and I have freedom to adjust it up or down depending on my needs. (This is a desktop/laptop circumnstance). I generally start at 512MB or so, increasing maybe if IO is faster on the drive. I view swap like a rumble strip on a road before a stop sign. With no swap, you don't realize a process leaked memory until it's too late, with swap, while it eats through your swap the performance will degrade and you'll see the end coming ahead of time, and may be able to head it off with a kill. It may be well an good your 4GB of ram is technically capable of handling the same load your 1GB RAM+1GB swap handled in the past, but having some noticable impact when things start going wroing is nice. I realize theoretically there are better approaches, but nothing gets in your face like poor performance and tons of disk accesses.
On a production server or a problematic system where I want support and the OS likes to dump a core to swap, I'll ensure a generous swap partition is available (generally observed active swapx1.5+physical memory size). In this case a file-backed swap may depend on layers of the kernel that are in an invalid state, and a swap partition is more likely to be reliably writable. The only system I would even theoretically hibernate on is my laptop, and I only ever suspend to ram or shutdown completely, so I don't consider my laptop as needing a swap partition of any significant size.
Slashdot Mirror
Wow, descending into geekier territory... I don't recall Voyager that much, but I do know they called the freaky guy who came because Wesley was in some wierd way special in TNG traveler. And that guy had used his powers to make the enterprise go ludicrously fast (plaid even) into the middle of no where when he flipped out in that episode. Can't remember the details, but he was traveler, he made the enterprise go out into the middle of nowhere, and it was all to get the kid off the show... err I mean help him realize his powers.
It says he started by coining the phrase it's what's inside that counts. I coulda sworn *I* coined the prhase trying to get girls to go out with me back in high school!
How the hell can someone claim a phrase is being coined when it's such a generic phrase used everywhere?
What about logging consoles to do historical information, view kernel panics, see the last screen a server spit out before unplanned power down? Textual consoles have extreme merit in complex large datacenters. And I can open and monitor 25 consoles concurrently on my screen text wise without sweating throughput or performance if I'm doing something on a large set of nodes..
Serial remains one of the most manageable approaches to console management. Video is, obviously, not loggable, not automatically monitorable, not greppable, and not amenable to low throughput, high latency remote access.. Serial devices and consequently drivers for them are so simple and straightforward, and the behavior so deterministic, that it is far preferable to something more complex (ethernet and usb) for a console. Ethernet certainly in questionable circumstances may suggest a driver unload/reload as a step to problem resolution, which is safer if not using as a console (though many times I have used ssh and chained the commands using semicolons). For example in that case, if your path contains an nfs mount, and you forget about it as you yank the network out, your chained command will hang as the shell tries to stat the nfs mount for the path. Part of the problem with relying solely upon the ethernet for console is the ethernet has more than one job to do, so it takes a fair amount more competent engineering to get to work right. Many newer systems offer to redirect textual serial traffic over IPMI, and that is admittedly decent *if* the vendor architects it robustly, which is difficult to ensure beyond hands-on experience with a brand and trusting in their consistancy. For example, e326 servers from IBM I wouldn't trust the net console, but an IBM x3455 I would be more confident in. USB, again, has similar complexity issues (it's multiplexed for keyboard/mouse/mass/storage/printing/scanning/etc etc). If you theoretically had bi-directional text console over some usb device, it's more difficult for a low level, simple piece of software to set up the usb controller and all requisite activities, then traverse the bus, identify the console devices, and then use it. Just like with an ethernet device where you may have cause to unload and reload a driver, a usb controller out to lunch with respect to a mass storage device would cause a similar issue. Enterprise distribution kernels tend to compile in the serial console and leave the usb controller modular, specifically with serial consoles in mind.
Serial console servers, in answer to your question, provide a scalable way for systems to access via the network serial consoles. By being dedicated, moderately simple systems with 40+ serial cables, they can provide access (via telnet generally) to a rack's worth of 1U servers, automatically log the content, or at the very least provide an administrator with remote console access at will to any given system.
Serial console is not obsolete in the least bit, just because it can't run your '31337' aero interface, or whatever nice and shiny interface that makes poser administrators and PHBs drool, doesn't mean good, serious systems administrators don't consider the technology to be a vital part of a robust management strategy.
A characteristic common of multi-tasking RTOSs is that timeslices are very small, and context switches extremely frequent, to help assure that apps will be able to do something in the required timeline, which is not necessarily a small amount of time, but in many applications it is a short time. There are more complexities, but the bulk of the 'overhead' mentioned in the GP is probably the high percentage of time spent doing context switches rather than useful work. The key word here is multi-tasking RTOSs, you describe cases in which the OS is largely a base for a single application that does everything itself. This is very common in the RTOS world, but their do exist areas where pre-emptive multi-tasking RTOSes fulfill a need....
Of course, your point is correct too, a requisite step with respect to this particular aspect of a RTOS is generally considered to be doing whatever it takes to make the context switch as fast as possible. In a server or desktop OS historically context switches aren't nearly as optimized as the solution can be for most applications to lengthen the timeslice. Server platforms particularly tend to have long timeslices as their activity isn't highly interactive, and the percentage of the time the system can do useful work is more important than each application being able to do their thing in a timely manner. On a desktop OS, timeslices being shorter is helpful (fairly recently a lot of debate and configurability happened in linux with respect to this), as multiple applications are more directly interacting with users. With a handful of processes it isn't really noticeable but as it scales up the delays get into perceptible fractions of a second. Having a smooth interface is a bit more along the lines of a design point of RTOS, so it makes sense. Anyway, there is a penalty paid, but the timeslices for satisfying human interaction requirements may still be orders of magnitutde higher than those required for RTOS applications, depending on what's going on.
Xeons prior to Woodcrest did get stomped by Socket 940 Opterons, now with Intel Woodcrest dual-core vs. AMD Socket F dual cores, Intel I believe holds similar advantage that it does in the desktop line.
SDL wraps/can wrap audio/graphics/input, basically everything you just said. On MS platforms it frontends DirectX, so it's fairly obvious that they are aiming for a cross-platform DirectX alternative. I've programmed against it and it's pretty easy to use.
My mythfrontend referenced is also a diskless unit, whether Apple's will be diskless or not I've not seen confirmed, but as a reference with a diskfull server and 512MB of ram, I have a system with instant on (using ACPI sleep) that functionally is close to the previewed iTV, so Apple's undoubtedly gonna have it more smooth and tuned to the task, and what I acheived expect that to be the bare minimum of the set-top box's capability.
The massive amount of throughput required for raw streams would be impossible to trasmit, even over a good network, particularly not 802.11g... Decoding even HD streams is easy with video decoding offload. My 1.8 GHz AthlonXP under mythtv playing 1920x1080 streams has about 50% idle when using XvMC to assist with decoding (using the planar Geforce 6150), so their set top box should have no problem decoding even tough stuff.
You have a point, but the American Civil War largely doesn't mesh with it. Keep in mind the whole slavery thing wasn't an issue in the American Civil War until the Emancipation Proclamation (years into the war), and even then it was not so much as intrinsic concern over the basic human rights of slaves, but a political tool that both tinted the conflict in the world view (and obviously in the historical view), very much against the Confederacy. It also was a declaration that any states that chose to attempt to secede and fail would have their slavery abolished (to keep border states considering seceding from doing so). Note the phrasing of the proclamation was that slavery was abolished in all states 'in open rebellion', and didn't ban it anywhere else. If it were about human rights, it wouldn't have carried that condition. Ultimately the move was probably the biggest single step toward abolishing slavery, but if not for the immediate need for a political tool brought on by the war, the step would have come much later. So ultimately the South seceding caused slavery to be abolished sooner than it would have.
The american civil war is a much more complex situation than redneck southerners fighting to continue slavery, as a lot of people are taught/figure. If it had been, it would be a much more simpler thing to declare the Northern states as being in the right at the time, but it's not that clear cut (particularly in the first couple of years of th ewar).
and passes the WAF test
As I said, the wife loves it.
As I said in my post, setting it up isn't admittedly the easiest thing in the world, but once it is set up, it ends up really easy to use. Setting it up as a single backend/frontend box (first thing I did) wasn't very hard. Even setting up a backend and frontend wasn't that much more so. Getting to a diskless system that can sleep I went through some convoluted stuff over the course of a few hours, but that is also the point where using Windows to acheive my goals becomes impossible, afaik. Maybe you could do something BartPE like, but ultimately the platform just wasn't designed for that stuff and even if possible, it probably would be as difficult or more so than what I did.
If you look piecewise at the parts I used, it costed about as much up front as a Tivo, but no monthly fees. I don't get cable (ditched it as all my content came from online or via major networks), so the cable provider DVR isn't an option, and if it were, another monthly fee. People at work with Tivos seem to be happy, other people who have other DVRs seem to complain, particularly from the cable company, about things like forced firmware upgrades that break frequently and such.
MCE doesn't have the flexibility for me to build what I want, and requires a higher hardware investment (i.e. another hard drive). Other DVRs aren't cheaper up front and/or come with a subscription fee to continue use, and in many cases are dodgy but without giving the users the ability to make it right or keep it right. MythTV fits my needs perfectly...
It enables me to make the ideal media setup, for me.
The potential for separation of backend and frontend allows me to have my loud, big, lots-o-storage system somewhere far away from my TV, and a quiet, yet affordable box with my TV.
My frontend is nothing but a micro ATX case with a motherboard (ASUS A8N-VM CSM), processor (Athlon XP64 3000), and 1 512M DIMM. No hard drive, no extra video card, booting diskless. Thanks to the linux base I'm able to PXE boot, and have a tmpfs root with about 40M of ram used, and nfs mount usr. Now I have a really slick frontend that I can sleep and resume, and it comes up in less time than my TV takes to turn on its lamp right back to whatever menu I left it at, but still have no hard disk whatsoever in it. It's very quiet, and passes the WAF test. The kind of power and flexibility I can get out of a mythtv on linux solution is far beyond anything that involves Windows (try having a fully persistant-storage free (including optical drives or usb storage) windows box that can run MCE and serve reliably as a frontend, persisting through all sorts of activity including sleep... My backend records OTA HD and uses a free service to get TV listings, no subscription, has everything stored on a software RAID5 with 4 250GB disks, and I can access it to make scheduling changes from anywhere via the web if someone say recommends a show while I'm at work. Can also download other media (i.e. fansubs), dump them in a particular directory tree, and the frontend can access it in an easy-to-use interface as well.
One thing I will say is that for more exotic configs, it naturally takes more work to set up than probably other things do, and in allowing the exotic configuration, a lot of confusing options end up facing the novice user (kinda like vi vs. notepad). Also, as it is only part of a full solution, it can't even simplify some config options because it quite frankly has no idea if the user will have a remote, if so what remote, if they will use a keyboard, maybe a joystick, if a joystick no idea on the keymapping... If it will be running backend and frontend type tasks on the same box, if separate the frontend may not know where the master backend is... It has various playback options that work better depending on your video card and such, and while they have a 'decent' default behavior, it doesn't de-interlace by default, doesn't enable any sort of sync to vblank by default, and doesn't enable XvMC by default, because it can't assume any of these are wanted or will perform right with the frontend's hardware. It could be assissted by a discovery architecture for the frontend (if localhost not responding, discover backends), and maybe a hardware/configuration database where it uses, say, lspci data and checks for XvMCConfig and other config files to have a better guess as to what the user can do, but it shouldn't sacrifice the power of it's configurability whatever may happen.
Once configured, it's slick and easy to use, no one has ever been confused by the interface that's used it at my house, I've never had to answer any questions pertaining to usage and once I got everything behaving correctly, I haven't had to touch configuration. Other people have scheduled recordings without being confused or anything, and that's about the hardest task left to do with the frontend. It could be leveraged as a part of a pre-configured solution where hardware and software config is already known (last I heard MCE had particular config requirements, so mythtv's ability to cope with a wider config probably contributes to this criticism).
I know I personally, and therefore scores of people who ever released an open-source project posted the tarball and fired the announce and within five-ten minutes realized they botched something and have a new version out...
Think it's really impossible to quantify 'Qucikest Patch Ever', but the one you point out may be in the running for quickest patch any significant amount of people gave a damn about..
Though not necessarily 64-bit precision flops, as are required for top500 scores... The cell isn't impressive double-precision wise.
Any source of HD is compressed with some algorithm (even terrestial broadcast is MPEG2).
IT depts. that are efficient and effective choose the software and hardware platforms they can support and standardize on it and provide support to those platforms. I accept this is a realistic expectation to set, an IT dept can only do so much and to fund an IT dept to be capable of doing all things for all people is just bad business.
IT depts however may lose some of that effectiveness and efficiency when they start mandating only what they approve is allowed and start taking proactive measures to keep employees in line. For example, most of my past was IT. I would depending on the company officially support whatever the company wanted to use. If that company approved of Solaris and Windows, and a Linux user called for software help, I would simply respond that I can't help them, but they are welcome to try to figure it out themselves or have me assist with a supported solution, even if I knew full well I could fix their problem if I gave a little time for it. A bad IT department may spend extra effort to reprimand the user for ever using linux and do all kinds of ungodly things to the infrastructure to more obviously break Linux clients as a deterrent in this example.
With a virtualization solution, the number of licenses required to be dealt with (Free licenses still have to be 'dealt with', i.e. make sure your usage legally matches the license) is at least four:
-The host os
-The virtualization software
-The guest os
-The application
For crossover it's three:
-The host os
-Crossover
-The application
The Windows license is expensive, and if you have commercial support from Crossover office for the app, it's not something that 'might work 90%', it is something that the vendor is legally obligated to get to work 100%. Crossover is fairly specific about what they provide support for, and for those applications it isn't 9/10 assed, it's supposed to work right or they have to help you make it work right.
Add to that some complications in virtualization (overhead of full guest os in terms of storage, paradigm of switching between OSes intrusive (both in terms of interface and filesystem space). Virtualization is needed/appropriate for some desktop scenarios, and more server scenarios, but I'm just stressing the counterpoints to show crossover is not a solution made irrelevant by virtualization.
If Dell took AMD seriously in 2006 that would have happened, but not so sure about 2007..
Same with IBM, both only just now really started taking AMD seriously and did so just in time for Woodcrest to come and tip price-performance back to Intel systems. AMD still has the memory performance advantage, but Woodcrest/Conroe's 4 ops per clock and relatively aggressive pricing mean AMD has to do something. I don't know AMD's schedule for quad-core offhand, but know Intel Clovertown is supposed to be probably 2nd quarter of 07. It's possible that in going to quad-core Intel's memory architecture could choke them and give AMD a more thorough advantage, or that AMD also gets similar performance while going to quad-core as Intel gets with Woodcrest/Conroe and the scales tip to AMD again.
I have worked for companies with exclusive Compaq, Dell, and IBM deals and more or less they are all the same. Drives go on occasion in every one, I think I happened to see Dell have the most backlight failures (ironic, as the company with Dell was the smallest company with the fewest number of laptops, and I worked there fairly short term, and even the raw number of failures exceeds what I saw in compaq and thinkpads. I have seen one thinkpad backlight go. Li-ion batteries always degrade no matter who the vendor is, expect at least anual replacement if you want it to maintain more than 30% charge consistantly.
The whole recovery system is annoying, and par for the course nowadays, but I always wipe the drive and use linux anyway, so I don't miss the Windows media.
It also depends on the model maybe, I really like my current thinkpad, it has excellent viewing angle (so-called 'flexview' display, but I've seen a lot more thinkpads with typically crappy laptop screens.
I even got a keyboard for my workstation with a trackpoint because it appeals so much to me.
The positioning is perfect, the trackpoint is right there along the home row and the buttons are right next to my thumbs when touch typing. Before the trackpoint I hated any activity that involved alternating mouse and keyboard activity because I would have to drastically move my hand to the mouse or touchpad to use that, then move my hand back to the keyboard. The same crowd that desperately looks for keyboard shortcuts in applications ought to appreciate the trackpoint. I don't have to significantly alter my hand position to manipulate the pointer versus type. For games and similar mouse activity, only a mouse or trackball will do, but for day to day pointer manipulation, I'll take a trackpoint over a mouse or touchpad any day.
UltraNAV has been moderately useful for me, I used synclient to make the 'edges' take up the entire area and enabled circular scrolling, so I have an iPod like scroller to complement my trackpoint.
Trackpoint is perfect for the lazy, don't move my hands from the homerow to move the mouse or click. It's a little bit of a reach to scroll with the touchpad, but it is easier than using cursor keys or pgup/pgdown.
Still, I get really annoyed at the concept of the touchpad being the de-facto pointing device standard in laptops:
-As the x-series demonstrates, touchpad takes up a lot of real-estate and makes it hard to do an ultra-portable
-No tactile feedback, with trackpoint it exerts pressure and you have a more solid feel of tracking the cursor movement, whereas a touchpad you just glide over.
-My hands have never ever accidentally manipulated a trackpoint. I run syndaemon to keep the touchpad disabled while typing, and disable everything but scrolling now, so it's not a big deal now (won't move or click the cursor even if I somehow typed really slowly and my wrist hits it), but the fact I have to do so much to make it not annoying is a bad sign.
-I don't have to lift my fingers to continue mouse movement in a direction when I reach an edge, like in a touchpad.
Even if you have people in there with 4 or 5 SNESs that is a metric butt load of households with SNESs.
The name Nintendo is always going to be associated with gaming by non gamers... and parents will buy there children a N64 to replace/upgrade a SNES because it makes sense from a non informed consumers perspective.
(could also replace PS2/Sony with 2600/Atari for similar results, an established market means something, but it far from means as much as people give it credit for).
Fact of the matter is that for the most part people aren't just sheep. More so than they should be, but when asked to shell out 600 bucks for something, they will consider it more thoroughly and not automatically buy it for their kids just because they had a PS2 and their kid liked the PS2.
To be fair, the Gamecube was fundamentally the same as PS2 and X-Box, the Wii is offering some potentially interesting innovation beyond 'more polygons, more lights, bigger discs'. Whether the Wii-mote will actually be fun or appealing remains to be seen, but it is an innovation that seems much more well executed and central compared to PS3's apparent last minute modification to mimick Wii and offset their likely legal-induced vibration function removal.
I never understood how the 'web hype' for Snakes on a Plane was ever expected to *help* the movie. Most of the 'web hype' was ridicule saying 'oh this movie is so campy, it makes me laugh'. You can tell from the marketing that the movie aimed to be somewhat serious, but the web hype and marketing all latched on to how campy it was. I think the people behind the movie were mistaken genuine ridicule for friendly jest, and called it web hype. Snakes on a Plane from all the 'web hype' I read was doomed to be a bad movie, and it lived up to what the web hype promised there.
Similarly, looking at the PS3 I see a lot of overconfidence on the part of Sony. The argument about price discrimination calling for such a high launch price ignores the obvious psychological effect of a high launch price even among those who wouldn't have been able to get one at launch anyway. Just cause some elitists/fanboys will buy your system no matter what, doesn't mean you scare away the more practical/indifferent gamers to gouge the elitists/fanboys for all they can.
The web discussions I think are more vital than people give it credit for. The target market for a 600 dollar console is clearly comprised of gaming enthusiasts, and most people like that are active participants in online discussions. The online discussions overwhelmingly are along the lines of 'at that price, no way'. From the time of launch to a significant price drop I predict PS3 will do poorly, and the question is if Sony recognizes it in time and their costs allow them to drop the price to prevent developer drop out. The effects of a weak launch may be difficult to overcome even if they do respond quickly, but it may be possible to pull it off.
Nintendo up to N64 was considered the nearly uncontested leader in the market. Despite having huge momentum leading up to, the N64 didn't do that well in the face of the newcomer Sony, and Gamecube hasn't done much better, and N64 wasn't as clearly overconfident as the PS3 seems to be. Admittedly the limitations of cartridges versus optical media played as well as poor third party relationships on the part of Nintendo played a role there whereas Sony is much healthier in those regards even with the PS3. Other apt comparison's in the price range are Neo-Geo and 3DO, both of which had significant hype and a lot of people saying 'these systems will be great', but no uptake because of the cost.
My strategy generally is to use a file for swap rather than a partition, even in linux. I figure that if memory has to be swapped in from disk, it's already crappy going to disk so the extra overhead doesn't matter much, and I have freedom to adjust it up or down depending on my needs. (This is a desktop/laptop circumnstance). I generally start at 512MB or so, increasing maybe if IO is faster on the drive. I view swap like a rumble strip on a road before a stop sign. With no swap, you don't realize a process leaked memory until it's too late, with swap, while it eats through your swap the performance will degrade and you'll see the end coming ahead of time, and may be able to head it off with a kill. It may be well an good your 4GB of ram is technically capable of handling the same load your 1GB RAM+1GB swap handled in the past, but having some noticable impact when things start going wroing is nice. I realize theoretically there are better approaches, but nothing gets in your face like poor performance and tons of disk accesses.
On a production server or a problematic system where I want support and the OS likes to dump a core to swap, I'll ensure a generous swap partition is available (generally observed active swapx1.5+physical memory size). In this case a file-backed swap may depend on layers of the kernel that are in an invalid state, and a swap partition is more likely to be reliably writable. The only system I would even theoretically hibernate on is my laptop, and I only ever suspend to ram or shutdown completely, so I don't consider my laptop as needing a swap partition of any significant size.