For media playback in a HTPC configuration, I would recommmend Zoomplayer for Windows.
I'm not sure about any possible MacOS offerings...
For a linux based system I've not seen anything that works too damn well in the particular setup. Xine seems best as is, but to truly be cool for HTPC, another interface would be designed. Until I found Zoomplayer, it looked like my solution would be a custom interface to mplayer or xine, but with ZoomPlayer, it looks like Windows is still the best choice for HTPC...
I would love for someone to give evidence to the contrary, however,,, I like having solutions that I can tweak for my indicual taste..
Well, for one, hot plug is not consistant on PS/2 ports, and it is on USB.
For mice, the extra bandwidth results in more frequent updates.
And finally, it could help reduce cable problems. I mean, for example with a KVM, only one cord needs to plug in for both mouse and keyboard if it could double as a USB hub. *Anything* that could help a KVM reduce cable mess is very good.
If the thing gets scroll-locked, does ctrl-q unfreeze it? I know its a general rule and you ought to try it next time it freezes if you didn't already know about ctrl-s and ctrl-q.
I don't have any KVM, but I would think ctrl-q would unfreeze it in lieux of scroll lock, it works in non-kvm situations.
Monsanto has the dumbest patent that is *severely* hurting innovation in the plant genetics research field. Basically, as far as my wife tells me, their patent manages not only to cover what they have discovered regarding certain plants, but also covers things, but in certain cases things not yet discovered by them, in certain cases. I do not know the patent number, but it seems that they patented everything about certain key plants and managed to get words to the effect of 'and all discoveries not yet known' to persist in the patent. So if someone else tries to beat them to the punch regarding something with these plants, they'll be sued into bankruptcy before they can get anywhere with it.
Would this part of the patent stand up in true due process of law? No way in hell. But as we have seen time and time again, the US justice system does not fairly handle civil cases. Almost always the party with more money wins, and for this reason this patent may never go away, unless a behemoth company sees fit to do so...
Still, in this case it is likely just an excuse. Mujabe exercises control in part through starvation, and if food were in large supply, his power would be weakened.
I've seen some of the stuff they are doing with corn and have been given a pretty good description of it. Most of the Genetic Engineering is ultimately just an extremely controlled and fast way to do what breeding does in the long term. Pesticides hold more potential harm than pure genetic engineering. The questionable thing is when they bring in hormone treatments to cattle and stuff, that, like pesticides is ultimately eaten by the consumer...
Well, the upstream bandwidth is true, but there is nothing inherent about a T1 that makes it able to carry more IPs, it's just a connection and you can cram as many IPs you want on either end of any connection.
That being said, companies that can make due with a single T1 frequently rely on another company for hosting, since 1.5 mbps really isn't enough to serve content in this day and age, so more and more DSL is a more viable option....
Give this thing some thought here. This is a sort of cable modem FUD. sure, in DSL the connection between your station and the CO is a dedicated line and you can get guaranteed 3mbps down and 384kpbs up to the CO, but the CO has a pipe that ultimately gets shared as well. So the formula is the same ultimately. Unless the bandwidth on the coax side is worse than the pipe side, there isn't too much of a difference. There are some differences that *could* make a difference:
- Proxy at the CO - newsfeed from the CO rather than through it - Services that you actually want served from the CO
Peer-to-Peer operations among customers still capped at 384kbps, so only stuff at the CO can really exploit the advantage of not being a shared bandwidth.
What makes the differences is that frequently, the CO being a branch of a telco company is much more likely to have a much fatter pipe than your average cable company. This is valid, but not always the case. Around where I live, DSL and cable modem are pretty much the same, with cable modems getting the edge in burst speed. All this because the cable company works with the local University and is patched into their extraordinarily fat pipe and thus is not afflicted by the standard problems of a cable company.
Of course by this statement you mean BSD ports is one of *few* (not only) distribution systems out there that is both comprehensive enough and easy enough that people don't try to bypass it and do it by hand.
For example, RedHat Network verifies downloads. The problem here is that the network was not too comprehensive, not really that integrated into the 'core' of the package management (more of an add-on, so it's not necessarily in your face every time you deal with package installs), and is made inconvenient by its cost. Not saying it is bad to charge for it, just that for most users out there the service is not enough of an added benefit to justify the cost. Hell even trying to stick to RPMs at all falls through, even if not sticking to red hat network. When I ran redhat, what redhat provided was pretty slim choice of packages from them, and what was there was outdated by the time they shipped, and not many independent projects offered RPMs, so most of my system was unmanaged....
Now debian with apt is more comprehensive and loads more convenient (free, 'more' in your face than rhn, but there is still dpkg). Of course packages still out of date....
Now my current favorite is gentoo with its portage system. Truly the core of the 'package' management system is so tightly intertwined with the distribution system that it's hard to ignore. They stay almost entirely cutting edge and nearly everything I want is in there. The one thing I had always admired about the BSDs was the ports system, but the hardware support under linux was better, so gentoo is a good medium....
Of course none of this is possible on a commercial platform fed by commercial apps. First off, payment methods complicate distribution. Secondly, in a group of businesses in it for the money, what sane business would make it easy to get *competing* software? For example, MS's 'windows update' sometimes offers free MS apps, but beyond that, nothing comes out of it. Even if Nero was free, and even if Zoomplayer is free *and* better than Windows Media Player, MS would never distribute them as they would compete and threaten MS's future hold over tight drm control in the future...
Bleh, I would not want to use that interface, for several reasons:
The 'page flipping' navigation requires more manual work and offers no intuitive advantages, it is not intuitive to flip a page twice and see different content... Cool for a demo, but bad for usage, that would suck horribly...
The print thing, that would be hard too.... Basically, you call the document into a view mode completely devoid of visual cues in order to get an acceptable print. Worse yet, printing a book would take a long time if you could only print the current display contents. Removing the visual cues is critically bad for a general purpose interface.
The general description of your interface seems to be centralized around typing/writing words to navigate. That is recall memory, not very good to ask users to recall from scratch whenever they want to do anything. The advantage of graphical is it exploits much more accessible recognition memory. The visual cues serve to help along the user if unfamiliar. The power of command line interfaces is undeniable, but to insist that a common user should be made to rely upon it again is a step back. GUI wise, I found efm and rox to have the nice compromise, a single keystroke brings access to the command line for powerful stuff and fast access to stuff available to recall memory, but offering the visual cues when things are not etched in stone in my memory...
Re:Notice the "more" link...
on
GUIs for Everyone
·
· Score: 3, Interesting
Actually, it kinda confused me when I saw a link at the bottom of the first column. I knew there was a second column, but did not know which way I was supposed to go to continue the thread I was on. If it was newspaper style, the more link would be the way, but it could be that the more was supposed to be interpreted after the whole article. I highlighted the link to see, and all was made clear, but it certainly threw me for a loop there, hardly intuitive...
Seriously, if one makes strict use of package management and thinks carefully about the apps they install, the entropy of the system tends not to increase. Back when I ran redhat, it was usually easier to get the source tarball and compile, resulting in/usr/local having high entropy. Now I use gentoo, and I have yet to go outside portage for a package. Now the problem of/home entropy remains....
My WinXP install also is pretty streamlined, only what I want. I oversee it like a hawk and think carefully about upgrades and changes to the system. With this regimen, it holds up well, though I rarely use it (maybe that also has something to do with it...). Now where you really run into this problem is on systems of casual users who don't care until it's too late. They have a temporary need, they install an app forever. They see something nifty, they install it without a second thought, without a second thought to resident programs loaded...
In short, any platform can show 'decay' over installed time, but its more a fault of the usage pattern rather than the platform itself. Any reasonable platform will give you the freedom to do what you want, even if the ultimate result is shooting yourself in the foot with your performance and functionality...
I work for a company that supports Windows, Irix, Aix, Solaris, and HP-UX. While it complicates QA, supporting n platfomrs does not require n times the amount of QA for one product. Especially if one is being aged out for another. Each additionally platform requires less additional QA than the previous, to a plateau. As much as companies love to spew the gargantuan cost of QA for multiple platforms, it is not nearly so bad as they say..
True, but if if there *had* to be a choice between x86 and ia64, I would think ia64 would be better.... And your point is exactly why I don't get Intel's strategy. They sacrifice their head start and now get evaluated 'fairly' against competing architecturs like PPC, MIPS and Sparc. They control Alpha and PA-RISC is being flushed. MIPS is pretty much earmarked for embedded apps by the market now (Irix systems aren't doing well, are they?), so the 'major' players in the workstation/server arena are PPC, Sparc, and Intel architecture... All other things equal, PPC looks really tempting in particular....
Of course, MS could make all the difference, unfortunately....
Yes, he's praying for standardization, using AMD's standards which is directly related to Hammer's success. Itanium was to be Intel's one and only 64-bit future, and only when faced with AMD's 32-bit backward compatible architecture did they design a fallback, the Yamhill, which would be compatible with the Hammer and legacy apps. The headline is *not* misleading at all, for once, he wants AMD's Hammer standard, not IA64.
It seems odd though. Putting aside market situation and prices to look at the pure technology aspect of it, IA64 is a better architecture, it isn't burdened with backwards compatibility. Especially with linux (which already works with IA-64, as well as most apps), there is little reason to hold on to the dated IA32 architecture, which inherits stuff from early 80s. I could see why MS would be on the x86-64 bandwagon (if users' upgrade paths force them to change architectures, they may be just as likely to go PPC as they would IA64), but not Linux...
It made sense when moving to 32-bit from 16-bit to keep backwards compatiblity, assembler was widely used back then out of necessity, and thus porting applications was non-trivial. Now, in an age where most everything is written in high-level languages, this is the perfect opportunity to start with a clean slate. Companies can easily recompile and do additionaly testing and earn back the money it cost to do so in short order, if their application is important to the market.... Of course all of this is from a technological standpoint....
The fact of the market is that Yamhill/x86-64 is the future of x86. Itanium was a nice dream and all, but when you look at the two platforms and the variety of software they support, the choice is clear. Not everything will be ported to IA64 and knowing that it is hard to justify the jump...
On some level it makes sense to have a lot of choice (I run gentoo, I like the choices...). But sometimes too much choice gets in the way in terms of usability and even functionality.
For example, X is the only game in town (essentially), so there is the common denominator in terms of network interoperability. Implementing widgets is left to a higher level depending on X primitives to do the work. Xaw, Qt, Gtk, motif, etc Are the choices. From the end-user perspective, the differences are purely cosmetic, and with theming, they become indistinguishable, with the difference being mostly in the API. Now, this interferes with network operation, as they have to send a lot of data describing a button to have it drawn on a remote X server. Becomes sluggish quickly on low speed links. Also, it is drawn with the 'theme' on the clients filesystem, rather than the display system's settings, so there are two problems. Now if a graphics system dominated with an integrated widget set, the choice is eliminated, but this single offering is pretty much the way to do it. We know what we want in a Toolkit, and having a single toolkit with multiple language bindings offers the best compromise between choice and functionality. KDE and Gnome take some fundamentally different approaches and both have value. There is less impact here so long as the choices remain few, so long as no standard exists to say how applications should register launchers and menus. It's no bigger to handle two. Both would benefit from a standard regarding applications registering themselves in a standard way.
Hell, even drag and drop is a mess because of choice. Xdnd is nice in *theory*, but it leaves way too much to choice on the part of the implementing application. I, and many others, have developed small libraries to deal with the many different drag and drop methods. Kde, netscape, mozilla, nautilus, gmc, rox, e17 and many others each have at least one or two quirks that are different from all others, so accepting and processing a drop from another application in linux is less trivial than it should be...
The taskmanager itself is not VMS, just some of the ways processes are managed and identified is. A very poor example I admit, since the things taskmanager show are pretty much the same across all platforms (just usually hidden), but it does look more 'Unixy' than say Win9x or MacOS classic... Though my limited work with VAX in the 90s made me loathe VMS, at least there I could kill a process no matter what....
But they *do* notice how they don't have a nice easy interface which lets them change total desktop resoultion and color depth *on the fly*. Even a wrapper for xf86config doesn't help this, as changing color depth and resolution would break many assumptions that need to hold true in X.
X should be implemented on a higher level for 'legacy support'. Just as the CVS developers have recognized the deficiencies of CVS and developed subversion to replace it, it is time we faced the fact that some core elements of X push the need for retirement. We have seen what works well and what works very badly, as well as what we want to do that we can't with X today.
Network transparency is good, and while X has been good at it, it isn't the best anymore in terms of technology (RDP has shown X up speedwise). X sends drawing primitives over the network. While more efficient than VNC's image methodology, it is less efficient than sending basic widget descriptions over the line, then primitives, then images in that preferred order. Another thing that could help is to integrate a mode of operation that is client/connection state agnostic. By this I mean a network interruption/client crash should leave networked accessed applications running and available for pickup on a resume, like a VNC or Terminal Server session. This opens up a can of worms in rootless operation (how should the user be able to know what is running easily?), but a 'rooted' mode should at least be available, even if rootless worked (rooted mode is useful, which is one of the reasons (along with client state independence) why x0rfbserver enjoys relative popularity despite offering piss-poor network performance....
As much as I like linux, this proves next to nothing. Linux's 'lack' of user friendliness is not a matter of technology, it is a matter of politics.
The technology is fine and no one will dispute that. You can build a nice gui over top of any sufficiently good core, which almost all modern OS's offer now. For example, XP's core is the evolution from the NT core, which was heavily inspired by VMS. You can see in the taskmanager particularly signs of the VMS underpinings underneath. VMS by itself is quite similar to Unix systems, so XP itself demonstrates that the UI on top makes the usability difference, and the solid core only helps (by delivering good performance with high stability).
The difference between Mac/Windows and Linux is that a single entity controls the system from top to bottom. Any disagreements as to how to do it are settled inside the company and a single offering is made to the public that is highly integrated, where each part knows *exactly* what to find where when it needs something. For a small example, an application installing on Mac or Win knows exactly how to register itself to show icons and menus in the right spots, whereas in linux, it isn't clear cut. You can probably manage to show up in Gnome and KDE, but there are other options. I love the breadth of choice and how I can pick and choose my favorite component for everything, but it does prevent offering a unified interface to home users.
Also, they distribute easy-to-install binaries. This relates to the previous point in that they *can* do this and not run into any wildly devating configuration that won't run that particular version (i.e. kernel/gcc/glibc versions differ a lot in the linux world). This is also because they don't have the free source ideology as a driving force. Sure, Darwin is open, but it is more of a side note, and what comes out of apple (with MacOSX) is tightly controlled. Source is easy for me to install, but it can take a long time and some people think it difficult. They could care less about the philosohy of Free software, they just want stuff to work easy and quickly.
Finally, these systems don't try to fit into an existing standard. I'm of course referring mainly to ditching X. X is a great and powerful/flexible system. I love X, but current implementations lack a lot of things XP and OSX have in terms of colorspace handling and access to hardware functions. Two clear things that come to mind are true alpha transparency (not copy and blend as all the translucency under X is) and the ability to change resolution and color depth on the fly without the 'slippery desktop'. Sure, extensions could be written to patch over this stuff, but it was more efficient to simply write a new low level graphics system and let X lie on top of it if needed. This is the way to go, it works well with Windows (Exceed) as well as MacOSX(XDarwin). You optionally get all the power of X without the limitations underneath. For linux users and developers, X is 'good enough' and there is no dominating business authority to force developers to do something more advanced.
Linux remains my preferred platform, though I want to try OSX. I like having choices and am a good enough admin to not care about the roughness around the edges, but for a common user to be satisfied, it needs to be consistant no matter where they may go..
ummm, still no confirmation of an agp slot there.... I don't care if it has the highest FPS in town, I want something as functional as an all-in-wonder... I know it says 'tv-encoder' but that often means encoding signal *to* tv, and even so, tv capture support under linux may not be possible... Of course with zoomplayer there is actually an acceptable Media player for windows for the role of a home theater pc...
Wireless is good, and I think the flaw in execution with the keyboard/mouse is not so much being plugged in, but the mouse cable tends to be too short, causing stuff like you describe... If you had a PC mouse plugged in, your cable would be so long that problem wouldn't happen... but then again you have too much ugly cable again... Perhaps more ubiquitous bluetooth might help..
Putting everything in front will look too crowded. If you are using ps/2 components, you probably are not hot-plugging them, so they can afford to be in back. If you want to have a nice setup coming out of the front with a decent reach, get a usb keyboard with integrated usb hub and plug a USB mouse into that keyboard. Why the hell would you want keyboard and mouse both to go all the way to the system when they just need a single connection...
While an expensive solution, apple seems to have cable reduction high on their list. You have one cable between monitor and system driving power and signal, one cable to keyboard and mouse (since mouse plugs into keyboard, which makes a *hell* of a lot more sense than the traditional PC way, Sun and Apple have it right..). But if apple is unacceptable, their are keyboards and monitors with built in USB hubs, so you can have a more convenient spot to plug stuff in. Of course, if you have a monitor with speakers and a USB hub you want to use, you have speaker, display, usb, and power cable going to it... Nasty... Technically you can get away with 4 cables out of a mac, network, power, display, keyboard, but add one for sound for a decent rig... Hell, get an iMac and not worry about the display cable at all, just worry about not being modular and having something in need of repair or upgrade...
This thing is clearly targetted at areas like Home Theater, where there aren't really relevant dongle-requiring apps.. If you are running something that requires a dongle, then you probably are at a business buying pre-built systems, not rolling their own..
Slashdot Mirror
For media playback in a HTPC configuration, I would recommmend Zoomplayer for Windows.
I'm not sure about any possible MacOS offerings...
For a linux based system I've not seen anything that works too damn well in the particular setup. Xine seems best as is, but to truly be cool for HTPC, another interface would be designed. Until I found Zoomplayer, it looked like my solution would be a custom interface to mplayer or xine, but with ZoomPlayer, it looks like Windows is still the best choice for HTPC...
I would love for someone to give evidence to the contrary, however,,, I like having solutions that I can tweak for my indicual taste..
Well, for one, hot plug is not consistant on PS/2 ports, and it is on USB.
For mice, the extra bandwidth results in more frequent updates.
And finally, it could help reduce cable problems. I mean, for example with a KVM, only one cord needs to plug in for both mouse and keyboard if it could double as a USB hub.
*Anything* that could help a KVM reduce cable mess is very good.
If the thing gets scroll-locked, does ctrl-q unfreeze it? I know its a general rule and you ought to try it next time it freezes if you didn't already know about ctrl-s and ctrl-q.
I don't have any KVM, but I would think ctrl-q would unfreeze it in lieux of scroll lock, it works in non-kvm situations.
Monsanto has the dumbest patent that is *severely* hurting innovation in the plant genetics research field. Basically, as far as my wife tells me, their patent manages not only to cover what they have discovered regarding certain plants, but also covers things, but in certain cases things not yet discovered by them, in certain cases. I do not know the patent number, but it seems that they patented everything about certain key plants and managed to get words to the effect of 'and all discoveries not yet known' to persist in the patent. So if someone else tries to beat them to the punch regarding something with these plants, they'll be sued into bankruptcy before they can get anywhere with it.
Would this part of the patent stand up in true due process of law? No way in hell. But as we have seen time and time again, the US justice system does not fairly handle civil cases. Almost always the party with more money wins, and for this reason this patent may never go away, unless a behemoth company sees fit to do so...
Still, in this case it is likely just an excuse. Mujabe exercises control in part through starvation, and if food were in large supply, his power would be weakened.
I've seen some of the stuff they are doing with corn and have been given a pretty good description of it. Most of the Genetic Engineering is ultimately just an extremely controlled and fast way to do what breeding does in the long term. Pesticides hold more potential harm than pure genetic engineering. The questionable thing is when they bring in hormone treatments to cattle and stuff, that, like pesticides is ultimately eaten by the consumer...
Well, the upstream bandwidth is true, but there is nothing inherent about a T1 that makes it able to carry more IPs, it's just a connection and you can cram as many IPs you want on either end of any connection.
That being said, companies that can make due with a single T1 frequently rely on another company for hosting, since 1.5 mbps really isn't enough to serve content in this day and age, so more and more DSL is a more viable option....
Give this thing some thought here. This is a sort of cable modem FUD. sure, in DSL the connection between your station and the CO is a dedicated line and you can get guaranteed 3mbps down and 384kpbs up to the CO, but the CO has a pipe that ultimately gets shared as well. So the formula is the same ultimately. Unless the bandwidth on the coax side is worse than the pipe side, there isn't too much of a difference. There are some differences that *could* make a difference:
- Proxy at the CO
- newsfeed from the CO rather than through it
- Services that you actually want served from the CO
Peer-to-Peer operations among customers still capped at 384kbps, so only stuff at the CO can really exploit the advantage of not being a shared bandwidth.
What makes the differences is that frequently, the CO being a branch of a telco company is much more likely to have a much fatter pipe than your average cable company. This is valid, but not always the case. Around where I live, DSL and cable modem are pretty much the same, with cable modems getting the edge in burst speed. All this because the cable company works with the local University and is patched into their extraordinarily fat pipe and thus is not afflicted by the standard problems of a cable company.
DRM is a fine acronym, means Digital Rights Mitigation, right? :)
Of course by this statement you mean BSD ports is one of *few* (not only) distribution systems out there that is both comprehensive enough and easy enough that people don't try to bypass it and do it by hand.
For example, RedHat Network verifies downloads. The problem here is that the network was not too comprehensive, not really that integrated into the 'core' of the package management (more of an add-on, so it's not necessarily in your face every time you deal with package installs), and is made inconvenient by its cost. Not saying it is bad to charge for it, just that for most users out there the service is not enough of an added benefit to justify the cost. Hell even trying to stick to RPMs at all falls through, even if not sticking to red hat network. When I ran redhat, what redhat provided was pretty slim choice of packages from them, and what was there was outdated by the time they shipped, and not many independent projects offered RPMs, so most of my system was unmanaged....
Now debian with apt is more comprehensive and loads more convenient (free, 'more' in your face than rhn, but there is still dpkg). Of course packages still out of date....
Now my current favorite is gentoo with its portage system. Truly the core of the 'package' management system is so tightly intertwined with the distribution system that it's hard to ignore. They stay almost entirely cutting edge and nearly everything I want is in there. The one thing I had always admired about the BSDs was the ports system, but the hardware support under linux was better, so gentoo is a good medium....
Of course none of this is possible on a commercial platform fed by commercial apps. First off, payment methods complicate distribution. Secondly, in a group of businesses in it for the money, what sane business would make it easy to get *competing* software? For example, MS's 'windows update' sometimes offers free MS apps, but beyond that, nothing comes out of it. Even if Nero was free, and even if Zoomplayer is free *and* better than Windows Media Player, MS would never distribute them as they would compete and threaten MS's future hold over tight drm control in the future...
Bleh, I would not want to use that interface, for several reasons:
The 'page flipping' navigation requires more manual work and offers no intuitive advantages, it is not intuitive to flip a page twice and see different content... Cool for a demo, but bad for usage, that would suck horribly...
The print thing, that would be hard too.... Basically, you call the document into a view mode completely devoid of visual cues in order to get an acceptable print. Worse yet, printing a book would take a long time if you could only print the current display contents. Removing the visual cues is critically bad for a general purpose interface.
The general description of your interface seems to be centralized around typing/writing words to navigate. That is recall memory, not very good to ask users to recall from scratch whenever they want to do anything. The advantage of graphical is it exploits much more accessible recognition memory. The visual cues serve to help along the user if unfamiliar. The power of command line interfaces is undeniable, but to insist that a common user should be made to rely upon it again is a step back. GUI wise, I found efm and rox to have the nice compromise, a single keystroke brings access to the command line for powerful stuff and fast access to stuff available to recall memory, but offering the visual cues when things are not etched in stone in my memory...
Actually, it kinda confused me when I saw a link at the bottom of the first column. I knew there was a second column, but did not know which way I was supposed to go to continue the thread I was on. If it was newspaper style, the more link would be the way, but it could be that the more was supposed to be interpreted after the whole article. I highlighted the link to see, and all was made clear, but it certainly threw me for a loop there, hardly intuitive...
emerge clean.
/usr/local having high entropy. Now I use gentoo, and I have yet to go outside portage for a package. Now the problem of /home entropy remains....
Poof.
Seriously, if one makes strict use of package management and thinks carefully about the apps they install, the entropy of the system tends not to increase. Back when I ran redhat, it was usually easier to get the source tarball and compile, resulting in
My WinXP install also is pretty streamlined, only what I want. I oversee it like a hawk and think carefully about upgrades and changes to the system. With this regimen, it holds up well, though I rarely use it (maybe that also has something to do with it...). Now where you really run into this problem is on systems of casual users who don't care until it's too late. They have a temporary need, they install an app forever. They see something nifty, they install it without a second thought, without a second thought to resident programs loaded...
In short, any platform can show 'decay' over installed time, but its more a fault of the usage pattern rather than the platform itself. Any reasonable platform will give you the freedom to do what you want, even if the ultimate result is shooting yourself in the foot with your performance and functionality...
I work for a company that supports Windows, Irix, Aix, Solaris, and HP-UX. While it complicates QA, supporting n platfomrs does not require n times the amount of QA for one product. Especially if one is being aged out for another. Each additionally platform requires less additional QA than the previous, to a plateau. As much as companies love to spew the gargantuan cost of QA for multiple platforms, it is not nearly so bad as they say..
True, but if if there *had* to be a choice between x86 and ia64, I would think ia64 would be better.... And your point is exactly why I don't get Intel's strategy. They sacrifice their head start and now get evaluated 'fairly' against competing architecturs like PPC, MIPS and Sparc. They control Alpha and PA-RISC is being flushed. MIPS is pretty much earmarked for embedded apps by the market now (Irix systems aren't doing well, are they?), so the 'major' players in the workstation/server arena are PPC, Sparc, and Intel architecture... All other things equal, PPC looks really tempting in particular....
Of course, MS could make all the difference, unfortunately....
Yes, he's praying for standardization, using AMD's standards which is directly related to Hammer's success. Itanium was to be Intel's one and only 64-bit future, and only when faced with AMD's 32-bit backward compatible architecture did they design a fallback, the Yamhill, which would be compatible with the Hammer and legacy apps. The headline is *not* misleading at all, for once, he wants AMD's Hammer standard, not IA64.
It seems odd though. Putting aside market situation and prices to look at the pure technology aspect of it, IA64 is a better architecture, it isn't burdened with backwards compatibility. Especially with linux (which already works with IA-64, as well as most apps), there is little reason to hold on to the dated IA32 architecture, which inherits stuff from early 80s. I could see why MS would be on the x86-64 bandwagon (if users' upgrade paths force them to change architectures, they may be just as likely to go PPC as they would IA64), but not Linux...
It made sense when moving to 32-bit from 16-bit to keep backwards compatiblity, assembler was widely used back then out of necessity, and thus porting applications was non-trivial. Now, in an age where most everything is written in high-level languages, this is the perfect opportunity to start with a clean slate. Companies can easily recompile and do additionaly testing and earn back the money it cost to do so in short order, if their application is important to the market.... Of course all of this is from a technological standpoint....
The fact of the market is that Yamhill/x86-64 is the future of x86. Itanium was a nice dream and all, but when you look at the two platforms and the variety of software they support, the choice is clear. Not everything will be ported to IA64 and knowing that it is hard to justify the jump...
On some level it makes sense to have a lot of choice (I run gentoo, I like the choices...). But sometimes too much choice gets in the way in terms of usability and even functionality.
For example, X is the only game in town (essentially), so there is the common denominator in terms of network interoperability. Implementing widgets is left to a higher level depending on X primitives to do the work. Xaw, Qt, Gtk, motif, etc Are the choices. From the end-user perspective, the differences are purely cosmetic, and with theming, they become indistinguishable, with the difference being mostly in the API. Now, this interferes with network operation, as they have to send a lot of data describing a button to have it drawn on a remote X server. Becomes sluggish quickly on low speed links. Also, it is drawn with the 'theme' on the clients filesystem, rather than the display system's settings, so there are two problems. Now if a graphics system dominated with an integrated widget set, the choice is eliminated, but this single offering is pretty much the way to do it. We know what we want in a Toolkit, and having a single toolkit with multiple language bindings offers the best compromise between choice and functionality. KDE and Gnome take some fundamentally different approaches and both have value. There is less impact here so long as the choices remain few, so long as no standard exists to say how applications should register launchers and menus. It's no bigger to handle two. Both would benefit from a standard regarding applications registering themselves in a standard way.
Hell, even drag and drop is a mess because of choice. Xdnd is nice in *theory*, but it leaves way too much to choice on the part of the implementing application. I, and many others, have developed small libraries to deal with the many different drag and drop methods. Kde, netscape, mozilla, nautilus, gmc, rox, e17 and many others each have at least one or two quirks that are different from all others, so accepting and processing a drop from another application in linux is less trivial than it should be...
The taskmanager itself is not VMS, just some of the ways processes are managed and identified is. A very poor example I admit, since the things taskmanager show are pretty much the same across all platforms (just usually hidden), but it does look more 'Unixy' than say Win9x or MacOS classic... Though my limited work with VAX in the 90s made me loathe VMS, at least there I could kill a process no matter what....
But they *do* notice how they don't have a nice easy interface which lets them change total desktop resoultion and color depth *on the fly*. Even a wrapper for xf86config doesn't help this, as changing color depth and resolution would break many assumptions that need to hold true in X.
X should be implemented on a higher level for 'legacy support'. Just as the CVS developers have recognized the deficiencies of CVS and developed subversion to replace it, it is time we faced the fact that some core elements of X push the need for retirement. We have seen what works well and what works very badly, as well as what we want to do that we can't with X today.
Network transparency is good, and while X has been good at it, it isn't the best anymore in terms of technology (RDP has shown X up speedwise). X sends drawing primitives over the network. While more efficient than VNC's image methodology, it is less efficient than sending basic widget descriptions over the line, then primitives, then images in that preferred order. Another thing that could help is to integrate a mode of operation that is client/connection state agnostic. By this I mean a network interruption/client crash should leave networked accessed applications running and available for pickup on a resume, like a VNC or Terminal Server session. This opens up a can of worms in rootless operation (how should the user be able to know what is running easily?), but a 'rooted' mode should at least be available, even if rootless worked (rooted mode is useful, which is one of the reasons (along with client state independence) why x0rfbserver enjoys relative popularity despite offering piss-poor network performance....
As much as I like linux, this proves next to nothing. Linux's 'lack' of user friendliness is not a matter of technology, it is a matter of politics.
The technology is fine and no one will dispute that. You can build a nice gui over top of any sufficiently good core, which almost all modern OS's offer now. For example, XP's core is the evolution from the NT core, which was heavily inspired by VMS. You can see in the taskmanager particularly signs of the VMS underpinings underneath. VMS by itself is quite similar to Unix systems, so XP itself demonstrates that the UI on top makes the usability difference, and the solid core only helps (by delivering good performance with high stability).
The difference between Mac/Windows and Linux is that a single entity controls the system from top to bottom. Any disagreements as to how to do it are settled inside the company and a single offering is made to the public that is highly integrated, where each part knows *exactly* what to find where when it needs something. For a small example, an application installing on Mac or Win knows exactly how to register itself to show icons and menus in the right spots, whereas in linux, it isn't clear cut. You can probably manage to show up in Gnome and KDE, but there are other options. I love the breadth of choice and how I can pick and choose my favorite component for everything, but it does prevent offering a unified interface to home users.
Also, they distribute easy-to-install binaries. This relates to the previous point in that they *can* do this and not run into any wildly devating configuration that won't run that particular version (i.e. kernel/gcc/glibc versions differ a lot in the linux world). This is also because they don't have the free source ideology as a driving force. Sure, Darwin is open, but it is more of a side note, and what comes out of apple (with MacOSX) is tightly controlled. Source is easy for me to install, but it can take a long time and some people think it difficult. They could care less about the philosohy of Free software, they just want stuff to work easy and quickly.
Finally, these systems don't try to fit into an existing standard. I'm of course referring mainly to ditching X. X is a great and powerful/flexible system. I love X, but current implementations lack a lot of things XP and OSX have in terms of colorspace handling and access to hardware functions. Two clear things that come to mind are true alpha transparency (not copy and blend as all the translucency under X is) and the ability to change resolution and color depth on the fly without the 'slippery desktop'. Sure, extensions could be written to patch over this stuff, but it was more efficient to simply write a new low level graphics system and let X lie on top of it if needed. This is the way to go, it works well with Windows (Exceed) as well as MacOSX(XDarwin). You optionally get all the power of X without the limitations underneath. For linux users and developers, X is 'good enough' and there is no dominating business authority to force developers to do something more advanced.
Linux remains my preferred platform, though I want to try OSX. I like having choices and am a good enough admin to not care about the roughness around the edges, but for a common user to be satisfied, it needs to be consistant no matter where they may go..
No AGP slot though, which is what I need for my ideal system. It is in the works, however, as other posts have pointed out...
ummm, still no confirmation of an agp slot there.... I don't care if it has the highest FPS in town, I want something as functional as an all-in-wonder... I know it says 'tv-encoder' but that often means encoding signal *to* tv, and even so, tv capture support under linux may not be possible... Of course with zoomplayer there is actually an acceptable Media player for windows for the role of a home theater pc...
Wireless is good, and I think the flaw in execution with the keyboard/mouse is not so much being plugged in, but the mouse cable tends to be too short, causing stuff like you describe... If you had a PC mouse plugged in, your cable would be so long that problem wouldn't happen... but then again you have too much ugly cable again... Perhaps more ubiquitous bluetooth might help..
Putting everything in front will look too crowded. If you are using ps/2 components, you probably are not hot-plugging them, so they can afford to be in back. If you want to have a nice setup coming out of the front with a decent reach, get a usb keyboard with integrated usb hub and plug a USB mouse into that keyboard. Why the hell would you want keyboard and mouse both to go all the way to the system when they just need a single connection...
http://www.newegg.com/app/ViewProduct.asp?submit=m anufactory&catalog=3&manufactory=1465&DEPA =1
Thought this one is not there yet, you can bet it will appear there soon.
While an expensive solution, apple seems to have cable reduction high on their list. You have one cable between monitor and system driving power and signal, one cable to keyboard and mouse (since mouse plugs into keyboard, which makes a *hell* of a lot more sense than the traditional PC way, Sun and Apple have it right..). But if apple is unacceptable, their are keyboards and monitors with built in USB hubs, so you can have a more convenient spot to plug stuff in. Of course, if you have a monitor with speakers and a USB hub you want to use, you have speaker, display, usb, and power cable going to it... Nasty... Technically you can get away with 4 cables out of a mac, network, power, display, keyboard, but add one for sound for a decent rig... Hell, get an iMac and not worry about the display cable at all, just worry about not being modular and having something in need of repair or upgrade...
This thing is clearly targetted at areas like Home Theater, where there aren't really relevant dongle-requiring apps.. If you are running something that requires a dongle, then you probably are at a business buying pre-built systems, not rolling their own..