I would say the edits to Heston's speeches didn't change the meaning much, if at all, with the rather significant exception of the "from my cold,dead hands" clip, which was rather outright deceptive and portrayed entirely out of context. The rest of the omissions seemed par from the course, and the omitted material really didn't do much to contradict Moore's portrayal of the spirit of the speech. The posted examination of the movie has some good points, but when analyzing the different country death tolls by guns and the canada-US comparisons, the critic makes a lot of stretches at least as dubious as the ones claimed against Moore.
Ultimately, I would say Bowling for Columbine had one hell of a tilt to it, and in some points outright misleading, but facts were still presented as facts, no facts were changed (did Moore outright *say* the 'from my cold dead hands' was from the speech? Strong suggestion but still). I think it is pretty much the only way to counter popular culture's extreme spin in the other direction. His spin is a necessity in the face of overwhelmingly opposite and strong spin by popular media...
Of course, the example doesn't really speak to the 'not for the desktop issue'. This illustrates that linux can work for the professional workstation, not that it is ready for the home desktop, or even the corporate desktop. I would wager the HR people, receptionists, higher level management types, accountants, and others of their kind were using Windows. This is not saying that it is technically incapable of dealing with the task, or that it is too hard.
The dominating factor here will be the labor market. Non-hardcore computer users are intimidated by the mere word 'linux'. If the job description included the word 'linux' for a secretary position, you can be that the market of people that feel they can fulfill that role is small, and those that feel they can would expect more money as they are a rarer candidate than Windows users. Companies realize that Windows is doing fine in those roles and that any savings in licensing is offset by the higher pay for the run of the mil positions. In higher-tech careers, most of those people have Linux skills anyway, and so the divide isn't so great, and thus the licensing and technology benefits of Linux pay off in the workstation and server realm.
And though I'd like to believe some distributions are now at least as easy to use as Windows or OSX, I have to admit that I really can't get into the frame of reference of a novice easily anymore, and I don't think many experienced users really can. I realize that because of this, I really can't say if it is easy enough or not. I think a lot of the people defending Linux on the desktop have this same problem and just won't realize it, though I think the same can be said of some experienced users who would assume the common user incapable of understanding certain tasks that are well within the common user's grasp...
As far as I know, OSX does not have that anywhere in there, and it would do them absolutely no good whatsoever. The point is to run binaries made for linux under FreeBSD by providing compatible kernel calls, but not emulating anything like the instruction set. If OSX had that feature, they could happily run LinuxPPC apps, and that is it. The interest and native commercial app support for Linux on PPC is far far more insignificant than OSX. For all the claims that OSX is not taken seriously,Linux PPC is not even a dot on the radar even for companies releasing products on Linux in x86 world.
Well, seeing as how a side effect of this is seeing through clothes, you can bet those security people will be paying attention when attractive people walk through. But with ugly terrorists, security guards may avert their eyes just to miss the sight of the body..
It is not so much that Apple tweaked their systems, but that they crippled competitors and used those results for comparison. If Apple can not, for all their tweaking get their own systems up to the cheaper x86 boxes performance levels when those boxes are tweaked, there is a severe problem there...
If you want to scale more, and your nodes have tons of ram, you could likely stuff the whole os into ramdisk and then use the local disk for the scratch space. Once booted, the network impact of nfs goes away.
Of course, you could use System installer Suite (http://www.sisuite.org/) which is *similar* to the rsync method mentioned by the other poster, but you get to skip the redhat install step in favor of SiS's tools.
Yes there is. It is true that the bandwidth of the links are different and are not changed. It is also true that latency has little to do with thing (there are flags on packets that affect latency, but they do not change during a session in almost every imaginable case). TCP does implement backoff. If packets are apparently dropped, the frequency of the retransmits is reduced.
You are right that the networks that TCP runs over are heterogenuous in terms of 'speed' (latency and throughput in this case), and for this very reason, TCP implements this algorithm to compensate for this fact. TCP will reduce link utilization until the weakest link between source and destination can handle it. If it didn't implement this, the number of retransmits would be unimaginable, and in fact in the case of a system having a high throughput link to the next hop, communication beyond that next hop would just not be possible.
Be tried to sell BeOS, it failed miserably, then gave it away for free in a last ditch effort to increase interest in the platform, and while extremely neat, the commercial interest remained weak.
Now, it is in the hands of another company trying to sell it again. At the same time, so many groups have extended in very good ways the free edition of BeOS5, and thus this somewhat improved commercial BeOS faces very similar, yet free competition.
I really don't see much hope in this, but it would be interesting to see how they fare.
I think his first point is valid. Even if the implementation is well partitioned and easy to apply updates to segments of the OS atomically, the problem remains that the *architecture* is designed to be too tight-knit. They are forced to honor this as earlier programs utilized this interconnectedness to do what they did (just as a lot of programs that *should* be usable by a common user only work for Administrator class users). Having to work around their backwards compatibility is biting them in the ass.
As to your statement that the same thing happens among Linux vendors in the 3/4 points, that is just totally off base. It is true that some vendors (*cough* redhat *cough*) have a history of adopting totally new, uncompatible versions of major packages before those versions reach 'stable' (glibc, gcc for example), but it is not meant to break compatibility. Especially with gcc, the promise of the new x86 backend was so great and it was thought at the time the final gcc 3.0 would be ABI/API compatible, and that the codebase was extremely close to release and very stable. They found out that neither was the case and got stuck with a bastardized gcc '2.96', but it was hardly a strategy to push other vendors out. The ultimate point is that all these technologies that are used that break inter-distro compatibility are open, well documented technologies, and thus by definition cannot be used to secretly push out competition and make compatiblity impossible. Also, in each case, there were real, compelling reasons for the changes.
Meanwhile, MS has a proven history of making trivial changes for the express purpose of breaking competitor products (Windows being changed to not run on DR-DOS for example). With a closed codebase, this becomes a real possiblity.
Why not just accept invalid IP addresses? Is it *really* so horrible? Designating a range of addresses to never be used is extremely wasteful. I can see maybe keeping addresses under 300 per octet (253 isn't as mindgrabbingly obvious as 332 for example), but to set aside perfectly good addresses for this is silly. Maybe with IPv6 it would work (but even then, would someone notice a single 'H' character in place of one of the hex digits? I'm not talking about taking screen captures and scrutinizing an address, but with a IPv6 shown momentarily, a single invalid hex character would work well), but IPv4 is rather crowded...
That could have well been intentional, ala the 555-xxxx phone numbers. I've seen a number of mass media things use invalid IP addresses, and though I have seen no one say anything, I have always assumed they just wanted to make sure they didn't use an address actually used by a valid system, as to reduce liability.
Proprietary and closed will keep this where it is. A shame really. There should be more effort to replace X.
X is nice, but is showing it's age. Problems I see:
Memory usage. It is true that application pixmap memory gets counted as X mem, not application memory, but X's primitives are, well, too primitive. The amount of memory required to represent widgets of high level toolkits in X is way too high because everything is represented by some really basic primitives, *especially* when apps draw complex things (i.e. gradients) and those things just have to be stored as pixmaps, even though they *could* be described in far less memory. Same goes for toolkit buttons that all look *similar* but not identical, even if heavily themed, they could share resources and modify them as needed for equal flexiblity consuming *much* fewer resources.
Network transparency. People always praise X for it's network transparency. This is just plain wrong, it sucks at that function. It may be better than other systems in many ways, but being the best does not mean it doesn't suck...
One thing is that it is way too bandwidth intensive. *Especially* here the X primitives are just *too* primitive for their own good. Drawing a button could be reduced to a single, small, insignificant amount of traffic, but in X, the client must describe every detail of just how to draw the button. With Xaw, they reduce the pain by using ass-ugly widgets that can be represented with relatively few X primitives. Meanwhile, modern good looking widgets make things ten times worse for the network. Even buttons with complex themes could be represented with a small amount of traffic if only the primitives were more sophisticated.
It follows that more sophisticated 'primitives' would improve the 'network transparency' for the end user in terms of look and feel as well, since the system attached to the screen can dictate how widgets look rather than the remote system running the app. In X if you run an application on two different systems, the remote themes dictate look and it detracts from the transparency and consistency aspect of things.
Also, when the connection is interrupted or the system serving the display to the program dies, the program dies with it. This is ugly. On the other hand, I don't think the MS approach of having each system have it's own screen is too hot either (RDP). What I would like to see is a hybrid of the approaches. Having the 'screen' like functionality of RDP/VNC where running where applications continue to run in the event of an interruption, but have application windows interleave with other windows rather than be kept in separate 'desktop' windows.
I can see two solutions: A completely new project to make a somewhat X-like system with more useful primitives. The native network protocol need not be X compatible, but an application running on *top* of it could provide X compatibility. That way, the project could truly ditch all the legacy stuff and start afresh, leaving the option of the legacy stuff for those that *need* it, and not forcing it upon those who do not. The difficulty associated with the anti-aliasing of fonts a while back proves that legacy stuff is really making progress difficult. I think this is the best way to go.
As a compromise, could GTK and/or QT be implemented as X extensions, where GTK/QT widgets would be primitives rather than basic shapes and raw pixmap data? While it would not address the 'screen-like' functionality I would wish, it would serve to reduce memory usage and network traffic. It would probably still be bloated a bit much, but if people are *really* adverse to ditching X, this would make it a lot more tolerable.
I can tell you right now that anything IBM releases is tested on *at least* RH and SuSE, and that GPFS *should* work independent of your distribution, only certain glibc and kernel revisions are strongly suggested.
And, btw, though GPFS is a neat option, it is kind of overkill for most home networks. The two things it really facilitates is sharing the same SCSI attached storage between different physically connected hosts and making separate storage on different hosts appear as one device to any member node. Presumably in a home network you only have the resources for one host with one set of storage. In the situation of a competent administrator, I would say exported a filesystem through nfs and samba provides the ideal configuration, easy to setup, and so long as you firewall it right and have no untrusted people living in your residence, it is secure. If someone breaks into your residence, chances are you have bigger problems than network infiltration at that point. Other options are, again, unnecessarily overkill for a *home* network.
Not true, you are describing Parity RAM. Let's review:
Normal RAM: no errors detected Parity RAM: an extra bit is used to store the XOR of all the othe bits on the line. If the math doesn't work, the OS can be informed the data at a particular address is corrupt, and let the software decide how to best cope with the condition. Only odd numbers of bit errors can be detected. ECC RAM: Uses a more complicated method and even more bits to provide single-bit error *correction* and double-bit error detection. The odds of two bits on the same line being corrupt is slim unless the ram is really bad. Single bit errors cause no problems. Double bit errors are at *least* detected. More than that and chances are the memory module is so screwed that even if the OS doesn't get it reported, the problem will be obvious to the user.
Re:Isn't there something missing from this "review
on
Video Codec Comparison
·
· Score: 1
That is a valid point, but in terms of really clean, complex footage, there aren't many places to go for uncompressed, digital content. Professionally published DVDs of high bitrate provide nearly artifact-free video, and I would say that is certainly 'good enough' for the purposes of showing off a codec.
What I don't agree with is the use of JPEG to encode captures of the footage for demo purposes. PNG would have been a far far better choice. I know still images alone are never a good indication of a codecs performance with respect to motion and such, but lossless stills would have at least been more indicative than lossy stills.
Despite the claims of mplayer documentation, I have found, for at least animated content, that xvid performs *FAR* better than libavcodec. Content encoded with libavcodec was downright blocky at even 200-300 kbps more than xvid's smooth output.
It's not as simple as that. The people wanting to run 64-bit appas for big things don't have a problem. In essence, Itanium was made to solve a problem already solved. PA-RISC, Sparc, PPC, MIPS, and others already have 64-bit variants. Companies that need the 64-bit address space and such already have solutions, and don't care a bit about MS offerings on their servers. This is evidenced by MS withdrawing their unpopular ports of WnNT to non-x86 platforms years back.
Itanium may be a true server class chipd and capable of pulling off the same stuff PA-RISC and Sparc can. But if there is *any* performance advantage, it is so slight that it is overshadowed by pathetic industry and software support. Sure you will soon be able to run Windows, and have been able to run linux, but ultimately there isn't much to run on those systems.
AMD has struck a cord here. A lot of large environments (especially clusters) have been getting by on 32-bit architecture because of the great applications support and price/performance ratios. The Opteron falls into the same price/performance league as those 32-bit systems in use, can equal or best those processors in 32 bit tasks, and as the software matures and gets recompiled, smoothly migrate to 64-bit operation without a hiccup. When these huge clusters are running software packages that costs millions to develop, there is a vested interest in continueing to use them while simultaneously ironing out the kinks in their 64-bit versions.
There is a damn good reason why IBM and others are finally acknowledging AMD as worthy of building servers around. Itanium sales have been pathetic, and there has been much more customer interest in the possibility of upcoming Opteron products than the reality of existing Itanium systems.
Porting is a red herring, OSX and Win32 already have good X imlementations. That benefit would certainly be an important one if those ports were not there.
Now don't underestimate the benefits of a graphics architecture that makes use of GL. It doesn't have to be slower or less efficient than 'standard' 2D operation, and graphics cards are working a lot on their 3D support and ensuring their cards and drivers support 3D operation as completely as they can. While *most* 2D cores provide hardware support for operations like alpha blending, smooth scaling, etc. in 2D operations, not all do. And even for those that do, focusing on GL in the drivers, which contains all those operation as a subset means more efficient development and new features being implemented more quickly. OSX has done it, I've heard MS plans to do it in the future. And if this project gains interest, general *nix systems could gain a graphics subsystem as capable as OSX without losing compatibility, that really excites me.
While your point about pixel-precision has some foundation, I believe that inprecision in consumer graphics card only appears after scaling or rotating objects, and that in a 2D plane where everything is flat, unscaled, and completely parallel to the screen, this is not a problem. OSX uses consumer graphics card and a great percentage of their target audience are professional video and graphics people who would not tolerate such inprecision should it occur. Should tricks start being implemented where windows are rotated, zoomed, and such, then the on-screen result would potentially contain distortions, but from the perspective of the Xlib calls, the surface being written to is constant and pixel precise, those calls have no way of knowing how the user will perceive that surface.
No, hardware manufacturers do *not* have an easier time of it. Just look at the current state of hardware support. The *last* thing to be supported by drivers is 3D functionality. The degrees of difficulty are: exposing a framebuffer for writing (extremely easy, can even be done without any effort if card supports VBE), accelerating 2D, and the ultimate, accelerating 3D. I don't think skipping 2D functions is a relevant concept here, I'm not that familiar with writing graphics driver, but I'd guess that the 2D functions would be implemented in the natural course of reaching the 3D functions. Even if skipping the 2D stuff is a valid concept, It doesn't buy anything as it seems the 2D functions are extremely easy.
Perhaps you are confusing the benefits to what lies above OpenGL to what lies below. You write an application in pure OpenGL, it can easily be ported to othe architectures. This would mean the X server in this article is likely easily portable itself (depending on how many X calls it does and how well modulated those calls are), so getting *it* to run on Windows or OSX is easy, as it depends on GL. Writing the drivers that GL depends on is a much harder problem, and in no way guaranteed cross platform. Those drivers once created *permit* cross platform application development, but are not themselves cross platform.
Cross platform hardware support is only accomplished through well architected driver code that has as little cross-platform code as possible and that code be in a modular place. It is a matter of driver developers doing it right and their job is made no easier simply because yet another GL app is released.
For a *business*, building a server if almost always the wrong path. When buying a prebuilt system, that support and QA is vitally important. Even in popular combinations, the amount of testing in a home-brew system is nil. Even if the IT *knows* what they are doing, the staff can be shuffled around, quit, whatever and leave the business in a difficult situation. Even if the staff is static, dealing with a defective, warrantied part is occasionally difficult, as the hardware company may try to blame other parts in your system or the software being ran before offering repair or exchange, whereas Dell, Hpaq, IBM, and the like will bend over backwards to kiss the asses of business customers and really have no one else to blame if the whole package comes from them. As the complexity of a system increases, the more vital it becomes to have a vendor ready to stand by the product as a whole, as the added complexity gives individual hardware vendors more things to blame. Servers are certainly a significant step in complexity, with multiple processors, multiple mass storage busses and devices.
Plus, there are just some things you cannot do when you roll your own system that server vendors provide, *particularly* in the rack environment. Blades are great for racks, but you certainly can't build your own. The health monitoring and management software with servers from the big names is very nice and not possible in your home system. I know IBM 1U servers knowadays come with a built-in kvm-like functionality where you just have a plug from one 1U server to the next and one to the previous server and all the systems in the chain understand if they receive a certain key sequence on the keyboard, that they switch to the appropriate system. KVMs for racks full of servers are typically a nightmare for cable management, so this is a nice resolution...
Now for home use, home built is pretty much fine. Slight downtime while you fight it out with the vendors is no big deal. The savings and intimate knowledge of your system has more value (unless you are going to fire yourself...) than it does in a business where the extra cost is negligible compared to the budget, and where the guy who builds it may be gone next week. And the bonuses don't matter as much in a standalone system as it does in the middle of a lot of other racks.
I'm glad this news *finally* makes it to slashdot as it certainly has *never* been discussed before. On a related note, has anyone heard about that new 'evil bit' RFC? I'm surprised that has never made it on slashdot.
First, whether you are a consultant or an employee, the issue is still the same, and they have the same expectations.
When faced with something I find dubious when first starting a project or taking on a consulting task, I do not assume an air of 'I know everything and this *will* fail'. I find it is actually more effective to ask questions that will lead them in the direction of figuring out the flaw for themselves. Also, it is not infrequent that there is *something* they neglected to mention that actually reveals what they want to be reasonable in context of the situation, and when that comes out in such a discussion, it doesn't make you look like a presumptious ass. If they figure out the flaw and where your questions where going, they appreciate not only your foresight, but helping them to understand the issue at a more fundamental level. If they reveal a piece of the puzzle that makes their request reasonable, or even if you end up having to point out the flaw yourself, they appreciate your effort to understand more about the big picture and how your piece fits in before just jumping in with a 'yes, sir' or flat out rejecting it without trying to understand why they might not be idiots.
Slashdot Mirror
I would say the edits to Heston's speeches didn't change the meaning much, if at all, with the rather significant exception of the "from my cold,dead hands" clip, which was rather outright deceptive and portrayed entirely out of context. The rest of the omissions seemed par from the course, and the omitted material really didn't do much to contradict Moore's portrayal of the spirit of the speech. The posted examination of the movie has some good points, but when analyzing the different country death tolls by guns and the canada-US comparisons, the critic makes a lot of stretches at least as dubious as the ones claimed against Moore.
Ultimately, I would say Bowling for Columbine had one hell of a tilt to it, and in some points outright misleading, but facts were still presented as facts, no facts were changed (did Moore outright *say* the 'from my cold dead hands' was from the speech? Strong suggestion but still). I think it is pretty much the only way to counter popular culture's extreme spin in the other direction. His spin is a necessity in the face of overwhelmingly opposite and strong spin by popular media...
I wouldn't put too much stock into a vague comment like this with nothing even remotely solid behind it made by yet another Brue Perens fake.
If you believe some super-secret open source (now there is an oxymoron) project is in the works to replicate premiere, I have a bridge for sale...
Of course, the example doesn't really speak to the 'not for the desktop issue'. This illustrates that linux can work for the professional workstation, not that it is ready for the home desktop, or even the corporate desktop. I would wager the HR people, receptionists, higher level management types, accountants, and others of their kind were using Windows. This is not saying that it is technically incapable of dealing with the task, or that it is too hard.
The dominating factor here will be the labor market. Non-hardcore computer users are intimidated by the mere word 'linux'. If the job description included the word 'linux' for a secretary position, you can be that the market of people that feel they can fulfill that role is small, and those that feel they can would expect more money as they are a rarer candidate than Windows users. Companies realize that Windows is doing fine in those roles and that any savings in licensing is offset by the higher pay for the run of the mil positions. In higher-tech careers, most of those people have Linux skills anyway, and so the divide isn't so great, and thus the licensing and technology benefits of Linux pay off in the workstation and server realm.
And though I'd like to believe some distributions are now at least as easy to use as Windows or OSX, I have to admit that I really can't get into the frame of reference of a novice easily anymore, and I don't think many experienced users really can. I realize that because of this, I really can't say if it is easy enough or not. I think a lot of the people defending Linux on the desktop have this same problem and just won't realize it, though I think the same can be said of some experienced users who would assume the common user incapable of understanding certain tasks that are well within the common user's grasp...
As far as I know, OSX does not have that anywhere in there, and it would do them absolutely no good whatsoever. The point is to run binaries made for linux under FreeBSD by providing compatible kernel calls, but not emulating anything like the instruction set. If OSX had that feature, they could happily run LinuxPPC apps, and that is it. The interest and native commercial app support for Linux on PPC is far far more insignificant than OSX. For all the claims that OSX is not taken seriously,Linux PPC is not even a dot on the radar even for companies releasing products on Linux in x86 world.
Well, seeing as how a side effect of this is seeing through clothes, you can bet those security people will be paying attention when attractive people walk through. But with ugly terrorists, security guards may avert their eyes just to miss the sight of the body..
It is not so much that Apple tweaked their systems, but that they crippled competitors and used those results for comparison. If Apple can not, for all their tweaking get their own systems up to the cheaper x86 boxes performance levels when those boxes are tweaked, there is a severe problem there...
If you want to scale more, and your nodes have tons of ram, you could likely stuff the whole os into ramdisk and then use the local disk for the scratch space. Once booted, the network impact of nfs goes away.
Of course, you could use System installer Suite (http://www.sisuite.org/) which is *similar* to the rsync method mentioned by the other poster, but you get to skip the redhat install step in favor of SiS's tools.
Yes there is. It is true that the bandwidth of the links are different and are not changed. It is also true that latency has little to do with thing (there are flags on packets that affect latency, but they do not change during a session in almost every imaginable case). TCP does implement backoff. If packets are apparently dropped, the frequency of the retransmits is reduced.
You are right that the networks that TCP runs over are heterogenuous in terms of 'speed' (latency and throughput in this case), and for this very reason, TCP implements this algorithm to compensate for this fact. TCP will reduce link utilization until the weakest link between source and destination can handle it. If it didn't implement this, the number of retransmits would be unimaginable, and in fact in the case of a system having a high throughput link to the next hop, communication beyond that next hop would just not be possible.
Be tried to sell BeOS, it failed miserably, then gave it away for free in a last ditch effort to increase interest in the platform, and while extremely neat, the commercial interest remained weak.
Now, it is in the hands of another company trying to sell it again. At the same time, so many groups have extended in very good ways the free edition of BeOS5, and thus this somewhat improved commercial BeOS faces very similar, yet free competition.
I really don't see much hope in this, but it would be interesting to see how they fare.
I think his first point is valid. Even if the implementation is well partitioned and easy to apply updates to segments of the OS atomically, the problem remains that the *architecture* is designed to be too tight-knit. They are forced to honor this as earlier programs utilized this interconnectedness to do what they did (just as a lot of programs that *should* be usable by a common user only work for Administrator class users). Having to work around their backwards compatibility is biting them in the ass.
As to your statement that the same thing happens among Linux vendors in the 3/4 points, that is just totally off base. It is true that some vendors (*cough* redhat *cough*) have a history of adopting totally new, uncompatible versions of major packages before those versions reach 'stable' (glibc, gcc for example), but it is not meant to break compatibility. Especially with gcc, the promise of the new x86 backend was so great and it was thought at the time the final gcc 3.0 would be ABI/API compatible, and that the codebase was extremely close to release and very stable. They found out that neither was the case and got stuck with a bastardized gcc '2.96', but it was hardly a strategy to push other vendors out. The ultimate point is that all these technologies that are used that break inter-distro compatibility are open, well documented technologies, and thus by definition cannot be used to secretly push out competition and make compatiblity impossible. Also, in each case, there were real, compelling reasons for the changes.
Meanwhile, MS has a proven history of making trivial changes for the express purpose of breaking competitor products (Windows being changed to not run on DR-DOS for example). With a closed codebase, this becomes a real possiblity.
Why not just accept invalid IP addresses? Is it *really* so horrible? Designating a range of addresses to never be used is extremely wasteful. I can see maybe keeping addresses under 300 per octet (253 isn't as mindgrabbingly obvious as 332 for example), but to set aside perfectly good addresses for this is silly. Maybe with IPv6 it would work (but even then, would someone notice a single 'H' character in place of one of the hex digits? I'm not talking about taking screen captures and scrutinizing an address, but with a IPv6 shown momentarily, a single invalid hex character would work well), but IPv4 is rather crowded...
That could have well been intentional, ala the 555-xxxx phone numbers. I've seen a number of mass media things use invalid IP addresses, and though I have seen no one say anything, I have always assumed they just wanted to make sure they didn't use an address actually used by a valid system, as to reduce liability.
Proprietary and closed will keep this where it is. A shame really. There should be more effort to replace X.
X is nice, but is showing it's age. Problems I see:
Memory usage. It is true that application pixmap memory gets counted as X mem, not application memory, but X's primitives are, well, too primitive. The amount of memory required to represent widgets of high level toolkits in X is way too high because everything is represented by some really basic primitives, *especially* when apps draw complex things (i.e. gradients) and those things just have to be stored as pixmaps, even though they *could* be described in far less memory. Same goes for toolkit buttons that all look *similar* but not identical, even if heavily themed, they could share resources and modify them as needed for equal flexiblity consuming *much* fewer resources.
Network transparency. People always praise X for it's network transparency. This is just plain wrong, it sucks at that function. It may be better than other systems in many ways, but being the best does not mean it doesn't suck...
One thing is that it is way too bandwidth intensive. *Especially* here the X primitives are just *too* primitive for their own good. Drawing a button could be reduced to a single, small, insignificant amount of traffic, but in X, the client must describe every detail of just how to draw the button. With Xaw, they reduce the pain by using ass-ugly widgets that can be represented with relatively few X primitives. Meanwhile, modern good looking widgets make things ten times worse for the network. Even buttons with complex themes could be represented with a small amount of traffic if only the primitives were more sophisticated.
It follows that more sophisticated 'primitives' would improve the 'network transparency' for the end user in terms of look and feel as well, since the system attached to the screen can dictate how widgets look rather than the remote system running the app. In X if you run an application on two different systems, the remote themes dictate look and it detracts from the transparency and consistency aspect of things.
Also, when the connection is interrupted or the system serving the display to the program dies, the program dies with it. This is ugly. On the other hand, I don't think the MS approach of having each system have it's own screen is too hot either (RDP). What I would like to see is a hybrid of the approaches. Having the 'screen' like functionality of RDP/VNC where running where applications continue to run in the event of an interruption, but have application windows interleave with other windows rather than be kept in separate 'desktop' windows.
I can see two solutions:
A completely new project to make a somewhat X-like system with more useful primitives. The native network protocol need not be X compatible, but an application running on *top* of it could provide X compatibility. That way, the project could truly ditch all the legacy stuff and start afresh, leaving the option of the legacy stuff for those that *need* it, and not forcing it upon those who do not. The difficulty associated with the anti-aliasing of fonts a while back proves that legacy stuff is really making progress difficult. I think this is the best way to go.
As a compromise, could GTK and/or QT be implemented as X extensions, where GTK/QT widgets would be primitives rather than basic shapes and raw pixmap data? While it would not address the 'screen-like' functionality I would wish, it would serve to reduce memory usage and network traffic. It would probably still be bloated a bit much, but if people are *really* adverse to ditching X, this would make it a lot more tolerable.
I can tell you right now that anything IBM releases is tested on *at least* RH and SuSE, and that GPFS *should* work independent of your distribution, only certain glibc and kernel revisions are strongly suggested.
And, btw, though GPFS is a neat option, it is kind of overkill for most home networks. The two things it really facilitates is sharing the same SCSI attached storage between different physically connected hosts and making separate storage on different hosts appear as one device to any member node. Presumably in a home network you only have the resources for one host with one set of storage. In the situation of a competent administrator, I would say exported a filesystem through nfs and samba provides the ideal configuration, easy to setup, and so long as you firewall it right and have no untrusted people living in your residence, it is secure. If someone breaks into your residence, chances are you have bigger problems than network infiltration at that point. Other options are, again, unnecessarily overkill for a *home* network.
Not true, you are describing Parity RAM. Let's review:
Normal RAM: no errors detected
Parity RAM: an extra bit is used to store the XOR of all the othe bits on the line. If the math doesn't work, the OS can be informed the data at a particular address is corrupt, and let the software decide how to best cope with the condition. Only odd numbers of bit errors can be detected.
ECC RAM: Uses a more complicated method and even more bits to provide single-bit error *correction* and double-bit error detection. The odds of two bits on the same line being corrupt is slim unless the ram is really bad. Single bit errors cause no problems. Double bit errors are at *least* detected. More than that and chances are the memory module is so screwed that even if the OS doesn't get it reported, the problem will be obvious to the user.
That is a valid point, but in terms of really clean, complex footage, there aren't many places to go for uncompressed, digital content. Professionally published DVDs of high bitrate provide nearly artifact-free video, and I would say that is certainly 'good enough' for the purposes of showing off a codec.
What I don't agree with is the use of JPEG to encode captures of the footage for demo purposes. PNG would have been a far far better choice. I know still images alone are never a good indication of a codecs performance with respect to motion and such, but lossless stills would have at least been more indicative than lossy stills.
Despite the claims of mplayer documentation, I have found, for at least animated content, that xvid performs *FAR* better than libavcodec. Content encoded with libavcodec was downright blocky at even 200-300 kbps more than xvid's smooth output.
But all American movies *do* seem to rely exclusively on explosions and cleavage nowadays...
It's not as simple as that. The people wanting to run 64-bit appas for big things don't have a problem. In essence, Itanium was made to solve a problem already solved. PA-RISC, Sparc, PPC, MIPS, and others already have 64-bit variants. Companies that need the 64-bit address space and such already have solutions, and don't care a bit about MS offerings on their servers. This is evidenced by MS withdrawing their unpopular ports of WnNT to non-x86 platforms years back.
Itanium may be a true server class chipd and capable of pulling off the same stuff PA-RISC and Sparc can. But if there is *any* performance advantage, it is so slight that it is overshadowed by pathetic industry and software support. Sure you will soon be able to run Windows, and have been able to run linux, but ultimately there isn't much to run on those systems.
AMD has struck a cord here. A lot of large environments (especially clusters) have been getting by on 32-bit architecture because of the great applications support and price/performance ratios. The Opteron falls into the same price/performance league as those 32-bit systems in use, can equal or best those processors in 32 bit tasks, and as the software matures and gets recompiled, smoothly migrate to 64-bit operation without a hiccup. When these huge clusters are running software packages that costs millions to develop, there is a vested interest in continueing to use them while simultaneously ironing out the kinks in their 64-bit versions.
There is a damn good reason why IBM and others are finally acknowledging AMD as worthy of building servers around. Itanium sales have been pathetic, and there has been much more customer interest in the possibility of upcoming Opteron products than the reality of existing Itanium systems.
Porting is a red herring, OSX and Win32 already have good X imlementations. That benefit would certainly be an important one if those ports were not there.
Now don't underestimate the benefits of a graphics architecture that makes use of GL. It doesn't have to be slower or less efficient than 'standard' 2D operation, and graphics cards are working a lot on their 3D support and ensuring their cards and drivers support 3D operation as completely as they can. While *most* 2D cores provide hardware support for operations like alpha blending, smooth scaling, etc. in 2D operations, not all do. And even for those that do, focusing on GL in the drivers, which contains all those operation as a subset means more efficient development and new features being implemented more quickly. OSX has done it, I've heard MS plans to do it in the future. And if this project gains interest, general *nix systems could gain a graphics subsystem as capable as OSX without losing compatibility, that really excites me.
While your point about pixel-precision has some foundation, I believe that inprecision in consumer graphics card only appears after scaling or rotating objects, and that in a 2D plane where everything is flat, unscaled, and completely parallel to the screen, this is not a problem. OSX uses consumer graphics card and a great percentage of their target audience are professional video and graphics people who would not tolerate such inprecision should it occur. Should tricks start being implemented where windows are rotated, zoomed, and such, then the on-screen result would potentially contain distortions, but from the perspective of the Xlib calls, the surface being written to is constant and pixel precise, those calls have no way of knowing how the user will perceive that surface.
No, hardware manufacturers do *not* have an easier time of it. Just look at the current state of hardware support. The *last* thing to be supported by drivers is 3D functionality. The degrees of difficulty are: exposing a framebuffer for writing (extremely easy, can even be done without any effort if card supports VBE), accelerating 2D, and the ultimate, accelerating 3D. I don't think skipping 2D functions is a relevant concept here, I'm not that familiar with writing graphics driver, but I'd guess that the 2D functions would be implemented in the natural course of reaching the 3D functions. Even if skipping the 2D stuff is a valid concept, It doesn't buy anything as it seems the 2D functions are extremely easy.
Perhaps you are confusing the benefits to what lies above OpenGL to what lies below. You write an application in pure OpenGL, it can easily be ported to othe architectures. This would mean the X server in this article is likely easily portable itself (depending on how many X calls it does and how well modulated those calls are), so getting *it* to run on Windows or OSX is easy, as it depends on GL. Writing the drivers that GL depends on is a much harder problem, and in no way guaranteed cross platform. Those drivers once created *permit* cross platform application development, but are not themselves cross platform.
Cross platform hardware support is only accomplished through well architected driver code that has as little cross-platform code as possible and that code be in a modular place. It is a matter of driver developers doing it right and their job is made no easier simply because yet another GL app is released.
I know you can build your own rack system, but you can *not* build your own blade. 14 systems in 7U is very nice.
For a *business*, building a server if almost always the wrong path. When buying a prebuilt system, that support and QA is vitally important. Even in popular combinations, the amount of testing in a home-brew system is nil. Even if the IT *knows* what they are doing, the staff can be shuffled around, quit, whatever and leave the business in a difficult situation. Even if the staff is static, dealing with a defective, warrantied part is occasionally difficult, as the hardware company may try to blame other parts in your system or the software being ran before offering repair or exchange, whereas Dell, Hpaq, IBM, and the like will bend over backwards to kiss the asses of business customers and really have no one else to blame if the whole package comes from them. As the complexity of a system increases, the more vital it becomes to have a vendor ready to stand by the product as a whole, as the added complexity gives individual hardware vendors more things to blame. Servers are certainly a significant step in complexity, with multiple processors, multiple mass storage busses and devices.
Plus, there are just some things you cannot do when you roll your own system that server vendors provide, *particularly* in the rack environment. Blades are great for racks, but you certainly can't build your own. The health monitoring and management software with servers from the big names is very nice and not possible in your home system. I know IBM 1U servers knowadays come with a built-in kvm-like functionality where you just have a plug from one 1U server to the next and one to the previous server and all the systems in the chain understand if they receive a certain key sequence on the keyboard, that they switch to the appropriate system. KVMs for racks full of servers are typically a nightmare for cable management, so this is a nice resolution...
Now for home use, home built is pretty much fine. Slight downtime while you fight it out with the vendors is no big deal. The savings and intimate knowledge of your system has more value (unless you are going to fire yourself...) than it does in a business where the extra cost is negligible compared to the budget, and where the guy who builds it may be gone next week. And the bonuses don't matter as much in a standalone system as it does in the middle of a lot of other racks.
I'm glad this news *finally* makes it to slashdot as it certainly has *never* been discussed before. On a related note, has anyone heard about that new 'evil bit' RFC? I'm surprised that has never made it on slashdot.
First, whether you are a consultant or an employee, the issue is still the same, and they have the same expectations.
When faced with something I find dubious when first starting a project or taking on a consulting task, I do not assume an air of 'I know everything and this *will* fail'. I find it is actually more effective to ask questions that will lead them in the direction of figuring out the flaw for themselves. Also, it is not infrequent that there is *something* they neglected to mention that actually reveals what they want to be reasonable in context of the situation, and when that comes out in such a discussion, it doesn't make you look like a presumptious ass. If they figure out the flaw and where your questions where going, they appreciate not only your foresight, but helping them to understand the issue at a more fundamental level. If they reveal a piece of the puzzle that makes their request reasonable, or even if you end up having to point out the flaw yourself, they appreciate your effort to understand more about the big picture and how your piece fits in before just jumping in with a 'yes, sir' or flat out rejecting it without trying to understand why they might not be idiots.