Someone else already posted a single source to get everything you need for VLC on Suse
As I explained to that rather rude gentleman, that was my source for the RPMs. Unfortunately, there were more RPMs missing from that site than there were available.
Regarding your mouse, is it the only USB device you have?
I have a USB hub with a bunch of stuff plugged in, but I unplugged it for this experiment.
The mouse was set up correctly on all Linux distributions I tried it on. It seems to be something inherent in the kernel. It's possible that it has something more to do with the BIOS than anything else. Although it does work on Windows, so that doesn't say much for Linux. I'll be trying a few of the suggestions I got later.
Except that's where I got it from. All the packages for SuSE are NOT there. Off the top of my head, libtheora, libart_gpl, and a bunch of others are missing.
I will be more civilized than you are and not call you a twit in response.
I was (obviously) exaggerating the 300. The real number was closer to 15-20 RPMs, only one or two of which was in YaST. The application was VideoLAN (a.k.a. VLC) video player. Check my Journal for the full scoop.
If each of a dozen apps has 100 KB of app and 9 MB of libraries, would you want to download 9 MB of libraries a dozen times over?
It's pretty hard to download 650 MB per ISO at 16 MB per hour, the nominal speed of dial-up. It's pretty hard to upgrade from dial-up in many geographic areas. Would you want to download 3 Linux ISOs over a dial up?
Sorry, you're not winning me over. You can have my Mac and all it's duplicate shared libraries (which really is practically zero considering that I tend to only have one program for each task I need) when you pry it from my cold dead fingers.
Besides, this is how programs for Windows, Mac OS X, and Java handle it. They all figured out long ago that consumers want everything in one package. Period.
"I use tons of Open Source on my RedHat, and I have never needed to compile anything. I usually get them from RedHat via ftp." Well, that's not quite true. But it might be. I'm sure OpenDarwin doesn't provide packages for everything on freshmeat, or sourceforge, or whatever...
OpenDarwin doesn't have everything, that's true. But there's pretty much everything I need there. And there's a whole community of developers who are creating.APPs of the best programs. For example, there was a nice DMG for VideoLAN for my Mac, but on SuSE I had to get the RPM (and 300 dependencies) from a variety of third parties.
It doesn't sound like a good solution to force all users to download all the gnome libraries (or Qt, or X11 for that matter) for all applications that depend on it.
Says you. As a Mac user, I'm very happy that's how it works. Memory is cheap (I've got 640 MB) and my time just isn't worth broken dependencies. How many times have QT and GTK changed? How many programs have broken when GLIBC or STD-LIBC have changed? Dependencies are a nightmare. If it's not a core system lib, it should be part of the program. If it is a core system lib, then it *always* be backward compatible (you hear me Stallman?!).
Anything that absolutely should be a library (e.g. X11) can be created as a.framework "file" (which is also a special directory). Overall, there are very few libraries that end up getting made into frameworks,
It's what happens. Whenever a change is made to the KDE menu (KDE 3.1), it will usually not show up until you log out and log back on. Sometimes it mysteriously shows up after a half hour plus, but that's just too long to wait for a menu item to show up. Especially when you just created it via the menu editor!
Well, normally you have to use an installer even though the method you describe (copy.app folder to Applications) was the way Apple intended it to work.
I'm typing on a Mac right now, and I can assure you that most programs come in DMG files *without* installers. The only programs with installers are ones that need to insert system components of some sort. Even Office X is as simple as drag and drop.
However, this is beside the point. To install a typical Free/Open Source program on Mac OS X, you normally have to recompile it! And sometimes even that doesn't work, because the coders used linux-only features that are not available on the BSD-based Mac OS X.
I use tons of Open Source on my Mac, and I have never needed to compile anything. I usually get them from OpenDarwin via WebDAV.
If you install software made (packaged) for Mac OS X, it's easy. But if you use Fedora and install software made (packaged) for Fedora, that's easy too. Or if you use Debian and install software made (packaged) for Debian.
Sorry, the packages themselves tend to be easy, but almost no one is helpful enough to give you all the dependencies that you need before installing. Mac software comes with all the dependencies inside the.app file. That's why I'm able to download something like ToastCD or LAME GUI (both based on Open Source) and never have to install any dependencies.
That's funny, because IT JUST HAPPENED ON SUSE! I had to track down 300 different RPMs just to get the thing installed. Once it was installed and working fine, I installed the NVidia driver. VLC no longer runs due to an NVidia incompatibility with libc. Is this just a figment of my imagination?
From what I've seen so far, there are only two possible desktops for the average user:
1. SuSE 2. Java Desktop System (SuSE based)
I haven't had a chance to try Xandros, so that may be a competitor as well. The biggest problem is that the Linux developers have to get off their high horse and make binary distribution as easy as source distribution. SuSE, RedHat, Mandrake, etc. are all Linux, but all need different RPM files. And then some RPMs may not match the version of libc/glibc you use.
What's the standard solution? "Just recompile it."
That is *not* acceptable for the average end user. Take a look at Mac OS X. They got it right. You download the DMG, it mounts as a folder, you copy the "program" (really a folder that the OS makes look like a file) to your Applications directory. Done.
Linux OTOH, goes like this: Find the RPM you want. Try to install and get a list of dependencies. Go track down every dependency you need (because you should already have libart_gpl and libtheora, right?!) and then install the dependencies. After spending and hour or two just to install one piece of software, log out and log back in so the menus update. Then try to run the software and hope that you didn't accidently install an incompatible binary. ARRRGGGHHH!!!
How do you figure? What do you mean by OEM? Where do you buy these OEM machines with RedHat on them? From RedHat? HP? IBM? I know IBM has built "solutions" for people based on several different distros, if memory serves, and I know that you can purchase machines with several distros pre-installed.
Why is that important anyway? Surely any company that can afford a datacenter of any meaningful size can afford to pay a sysadmin who can handle installing Linux herself.
It seems to me that you've never actually supported a corporate environment. These OEM installs and contracts are in place not because they are better than custom built machines, but because there's someone to blame (other than the technology department) when things go wrong.
How about you come back when you know what you're talking about?
burn song.wav to cd1 as audio-cd burn all songs in c:\mp3 to cd1 as data-cd
that would be pretty easy and friendly. But no os does that AFAIK. No reason you couldn't make a bash alias to do that and then it would be easy for people.
Actually, that looks pretty close to AppleScript. Unfortunately, the "ease of use" tends to become a liability to advanced users, as they have difficulty remembering the syntax.
2. RedHat !f= (doesn't fucking equal) *nix on x86.
If you're a company looking for OEM machines, it does.
3. WTF does Apache have to do with ANYTHING? Apache is Apache, it's the same Apache whether running on an x86 *nix or a "Unix Machine".
I didn't say Apache had anything to do with anything. I said that RedHat's XInetD happily screws up the process of starting and stopping it.
4. I have never seen a *nix without a large number of startup / shutdown / whatever scripts, and I have yet to see any major headaches from toying with them, anywhere, ever, on any *nix. Why on earth is this non-existent "x86 *nix" problem not also a problem on "Unix Machines" that also have lots of scripts?
It's only a problem on RedHat. They have tons and tons of interdependent shell scripts that do Lord knows what, but the system breaks when they stop working. A perfect example (albeit no longer applicable) was the old X-Windows init script. It was designed to allow you to switch Window Managers from a shell script. It was actually pretty neat, but the slightest X11 change would throw the whole script out of whack, and suddenly X-Windows wouldn't work anymore. I've never seen any other Unix use so many fragile scripts in the core system.
Wrong. In 2000 when SGI offered me an O2 for $25,000, it would've taken 5 of them to do the same job as one $3,000 Dell Pentium2.
It's called "capacity planning". If you're buying a bigger machine than your capacity calls for, then of course you're spending extra money. OTOH, if you can put your web server, email server, domain server. file server, etc. all in the same box, then you're saving money over the proliferating x86 boxes.
BTW, four years ago, Sun was pretty much the only Unix machine vendor that was attempting to attack the low end as well as the high end. IBM sort of did, but most of their small machines were for product demoing purposes.
I suppose that in the 4 years that've gone by since a UNIX dealer has last tried to sell me anything, they might've gone more into a desperation mode and started reducing prices to get competitive with Intel/AMD systems again.
Sun makes some very nice Ultrasparc Rackmount and Blade systems starting at $999. That's pretty hard to beat, even for Dell.
Those are all areas where an x86 PC trounces Sun or SGI systems. With Sun, the annual maintenance fee can often exceed the lifetime ownership cost of a PC variant.
I don't know if you've been paying attention, but Dell has also been charging exorbitant yearly maintenance fees for their server products. I know a small company that just payed $50,000 to Dell for their yearly maintenance. When you consider that those maintenance costs are for replacement of hardware that fails (and with Dell it *will* fail), there's simply no way to get away without those costs. The only alternative is to do without maintenance and absorb any costs for replacement hardware. And I'd much rather do that with a small Sun machine and a Solaris Free license than I would a Dell.
Funny how you latch on to the worst of the bunch and then loudly proclaim how much all Unix machines suck. Sun machines are *nice*. I'm sorry you've had the displeasure of having to deal with AIX, but that doesn't mean that other vendors don't have their act together. Personally, I'll never understand why people keep buying the massive heaps of garbage that IBM puts out. Oh, that's right: "No one ever got fired for buying IBM."
Why, because you've found some mystical, magical fix for it? The reality is that RPM hell is a symptom of a larger problem -- that different programs often want different versions of shared libraries.
Actually, I have. It's called Mac OS X. And somehow ISVs are able to release all kinds of software based on Open Source without littering my hard drive. Examples include Safari (KHTML), OpenOffice, a LAME GUI that integrates with iTunes, DigiTunnel VPN, Firebird/Thunderbird, VideoLAN player, and ToastCD. All of these install by opening the DMG file and dragging the application to the Applications folder (or wherever else you want it).
The basic problem with RPM hell, is that RedHat made the decision to base every component of the OS on the RPM package manager. This means that really stupid dependencies like the version of Bash (for GUI apps even!) interfere with the system. FreeBSD doesn't have this problem, because all of their packages assume the base system. It doesn't bother to check if you have BASH, TCSH, or KSH installed, because it doesn't matter!
While I agree with what you're saying, I do have to say that companies like Sun have a point. They simply can't embrace a toolkit like QT without forcing their customers into unexpected costs. QT is far superior to GTK (although Sun is helping GTK catch up), but the Unix companies already did this once with Motif. They're unlikely to do it again.
That being said, TrollTech should continue to serve their customers and develop a great product. Those who are willing to absorb the costs of QT will find themselves with a great product.
Sadly enough, BSDs are not really considered in large corporate environments. Companies are too busy competing over who's got the "best" stuff to care about anything that actually *works*. It's all about posturing. Thankfully, many web service providers and ISPs keep chugging along with BSD, and nobody's the wiser.
Sun is attempting to deliver a powerful solution that the market *needs*. However, the market *wants* something different. As a result, Sun is reinventing themselves to make money. It's really a sad state of affairs, but then again the entire economic setup is.
Unfortunately, we don't have a better name for that family of chips. It's kind of long to be naming out Sparc, PowerPC, MIPS, Alpha, etc.
As you said, MIPS is pretty close. I think that only the SIMD instructions that various hardware vendors have added are actually multiple cycle per instruction.
I don't know what those other problems you speak of stem from, for I have many RedHat boxes and have not experienced them. Perhaps the admins are idiots?
Yes and no. The GDM problem, for example, happens when you configure the hostname. For some lame reason, GDM tries to do a reverse lookup on the hostname, and fails to start if it can't. I don't remember all the details right now, but it didn't even like it if you used a hosts file.
The starting of daemons problems are caused by RedHat's insistence on trying to map XinetD to the concept of Windows Services. The configuration tools never work right, and the whole thing happily blows up. I've tried to tell admins to use the command line, but they want to do it the "RedHat approved way" for purposes of support.
It may have improved, but last I checked, RedHat systems are littered with extremely complex shell scripts to do every little thing. These shell scripts work fine if you don't dive too deep into the system, but they easily start breaking as soon as you start trying to ratchet up security, or install system level software.
RPM hell is, well, RPM hell. Eventually you install yourself into a corner, where you've got a set of mismatched dependencies. After that point, you can only force installs. You can't even uninstall anything because the dependencies have gotten so tangled. Thus the "standard" position for managing RedHat servers is to multiply them like windows machines (one task per machine), and reinstall the OS every time you requisition a machine. This procedure is covered over by the constant need to "upgrade" to the latest and greatest (and highly unstable beta software) release of RedHat Linux.
A Solaris box is also difficult to work with on the first go-round. Usually you get sent to Sun classes and everything becomes clear.
A Solaris box is complex. But I've really never seen anyone do irreparable harm through normal use of the machine. I remember when I received my first Solaris machine. I was a Unix newb, and had to struggle through quite a bit. But I found that the machine was well designed and laid out, and eventually I found everything I needed. The only concern I ever had with Solaris was trying to reign in the Open Source software from making a big mess out of my hard disk. (Ok, this goes in/usr/local, this goes in/opt, this goes in/usr/share/, that goes in/use/bin, this goes... over there! Oh, and you don't need the Sun 'tar' utility. Use this instead! Ugh.)
Are you saying that this is an inherent language problem, or simply an implementation problem? i.e. Does the Jython interpreter display this issue, or only the native Python compiler/interpreter?
When referring to concepts like Total Cost of Ownership and capabilities/features offered, one has to refer to the "Complete Package". The primary competitors are:
Sun Solaris (UltraSpace) HPUX AIX WinTel LinTel (pretty much only RedHat comes in OEM form)
The later two represent the "low-end" x86 platform, while the former three represent the "high-end" Unix/RISC platform.
You wrote an entire reponse to something he didn't say. He never said he was advocating Winx86. He said that the older SUN/SGI style hardware was losing marketshare in favor of X86 hardware. Which of course is correct. He didn't say that these cheaper X86 boxes wouldn't be running a *nix.
Allow me clarify. When I say "Unix Machines", I am referring to Sun, SGI, HP, and IBM Unix based hardware. While these machines can run other OSes, they are designed and engineered to run a variant of the Unix operating system. Thus "Unix machines". I was not referring to the operating system in specific.
And yes, RedHat does self-destruct at the slightest provocation. It's actually rather enjoyable (in a morbid way) to grab a bag of popcorn and watch as GDM suddenly disables itself, or the Apache "service" suddenly fails to start, or watch admins struggle with XInetD, only to have all their other "services" go haywire, or (my personal favorite) watch the admins struggle with some insanely masochistic script that no longer works because of some minor system change. Not to mention all the other scripts that were dependent on that script, which are now quite broken. I'm not even *going* to mention RPM hell.
Well judging by the amount of people dropping their old UNIX gear, and taking up rackfulls of AMD or Intel boxes (especially the new 64bit offerings), i'd say the answer to that is a big YES.
I would disagree. And I'll tell you why:
1. It takes fewer Unix boxes to accomplish the same job as the ever multiplying rabbits^W x86 machines. This consolidation makes for lower overall costs in equipment and maintenance. Unfortunately, x86 looks cheaper up front. No one considers concepts like capacity planning. Just add another box. They're cheap!
2. Dell (and their competitors) charge a mint for "server hardware". So much that Sun hardware often comes in cheaper. Again, managers thing x86 == cheap and Sun == Expensive.
3. Unix machines allow you much more flexibility in remote maintenance, system configuration (just try to tweak the size of write buffers on Windows), and live upgrades. Linux theoretically offers many of the same benefits, but RedHat deployments have a tendency to self destruct. I've seen admins actually afraid to touch their RedHat boxes for fear that something will go wrong.
4. Performance isn't everything. Reliability, uptime, maintainability, etc. are all worth paying extra for. The short sightedness of the industry results in these factors often being ignored. As a result, big money is spent on all three areas *after the fact*. (A company I worked for once had a Dell RAID controller go. The entire production database was corrupted on ALL drives. That hurt.)
Long term, Unix machines still win the day. This is very much due to the fact that the entire machine is engineered instead of cobbled together. It's just too bad that the entire industry is only looking at the short term.
Slashdot Mirror
Someone else already posted a single source to get everything you need for VLC on Suse
As I explained to that rather rude gentleman, that was my source for the RPMs. Unfortunately, there were more RPMs missing from that site than there were available.
Regarding your mouse, is it the only USB device you have?
I have a USB hub with a bunch of stuff plugged in, but I unplugged it for this experiment.
The mouse was set up correctly on all Linux distributions I tried it on. It seems to be something inherent in the kernel. It's possible that it has something more to do with the BIOS than anything else. Although it does work on Windows, so that doesn't say much for Linux. I'll be trying a few of the suggestions I got later.
Except that's where I got it from. All the packages for SuSE are NOT there. Off the top of my head, libtheora, libart_gpl, and a bunch of others are missing.
I will be more civilized than you are and not call you a twit in response.
I was (obviously) exaggerating the 300. The real number was closer to 15-20 RPMs, only one or two of which was in YaST. The application was VideoLAN (a.k.a. VLC) video player. Check my Journal for the full scoop.
If each of a dozen apps has 100 KB of app and 9 MB of libraries, would you want to download 9 MB of libraries a dozen times over?
It's pretty hard to download 650 MB per ISO at 16 MB per hour, the nominal speed of dial-up. It's pretty hard to upgrade from dial-up in many geographic areas. Would you want to download 3 Linux ISOs over a dial up?
Sorry, you're not winning me over. You can have my Mac and all it's duplicate shared libraries (which really is practically zero considering that I tend to only have one program for each task I need) when you pry it from my cold dead fingers.
Besides, this is how programs for Windows, Mac OS X, and Java handle it. They all figured out long ago that consumers want everything in one package. Period.
That's good to hear. Now SuSE just needs to update. :-)
"I use tons of Open Source on my RedHat, and I have never needed to compile anything. I usually get them from RedHat via ftp." Well, that's not quite true. But it might be. I'm sure OpenDarwin doesn't provide packages for everything on freshmeat, or sourceforge, or whatever...
.APPs of the best programs. For example, there was a nice DMG for VideoLAN for my Mac, but on SuSE I had to get the RPM (and 300 dependencies) from a variety of third parties.
.framework "file" (which is also a special directory). Overall, there are very few libraries that end up getting made into frameworks,
OpenDarwin doesn't have everything, that's true. But there's pretty much everything I need there. And there's a whole community of developers who are creating
It doesn't sound like a good solution to force all users to download all the gnome libraries (or Qt, or X11 for that matter) for all applications that depend on it.
Says you. As a Mac user, I'm very happy that's how it works. Memory is cheap (I've got 640 MB) and my time just isn't worth broken dependencies. How many times have QT and GTK changed? How many programs have broken when GLIBC or STD-LIBC have changed? Dependencies are a nightmare. If it's not a core system lib, it should be part of the program. If it is a core system lib, then it *always* be backward compatible (you hear me Stallman?!).
Anything that absolutely should be a library (e.g. X11) can be created as a
It's what happens. Whenever a change is made to the KDE menu (KDE 3.1), it will usually not show up until you log out and log back on. Sometimes it mysteriously shows up after a half hour plus, but that's just too long to wait for a menu item to show up. Especially when you just created it via the menu editor!
Well, normally you have to use an installer even though the method you describe (copy .app folder to Applications) was the way Apple intended it to work.
.app file. That's why I'm able to download something like ToastCD or LAME GUI (both based on Open Source) and never have to install any dependencies.
I'm typing on a Mac right now, and I can assure you that most programs come in DMG files *without* installers. The only programs with installers are ones that need to insert system components of some sort. Even Office X is as simple as drag and drop.
However, this is beside the point. To install a typical Free/Open Source program on Mac OS X, you normally have to recompile it! And sometimes even that doesn't work, because the coders used linux-only features that are not available on the BSD-based Mac OS X.
I use tons of Open Source on my Mac, and I have never needed to compile anything. I usually get them from OpenDarwin via WebDAV.
If you install software made (packaged) for Mac OS X, it's easy. But if you use Fedora and install software made (packaged) for Fedora, that's easy too. Or if you use Debian and install software made (packaged) for Debian.
Sorry, the packages themselves tend to be easy, but almost no one is helpful enough to give you all the dependencies that you need before installing. Mac software comes with all the dependencies inside the
That's funny, because IT JUST HAPPENED ON SUSE! I had to track down 300 different RPMs just to get the thing installed. Once it was installed and working fine, I installed the NVidia driver. VLC no longer runs due to an NVidia incompatibility with libc. Is this just a figment of my imagination?
From what I've seen so far, there are only two possible desktops for the average user:
1. SuSE
2. Java Desktop System (SuSE based)
I haven't had a chance to try Xandros, so that may be a competitor as well. The biggest problem is that the Linux developers have to get off their high horse and make binary distribution as easy as source distribution. SuSE, RedHat, Mandrake, etc. are all Linux, but all need different RPM files. And then some RPMs may not match the version of libc/glibc you use.
What's the standard solution? "Just recompile it."
That is *not* acceptable for the average end user. Take a look at Mac OS X. They got it right. You download the DMG, it mounts as a folder, you copy the "program" (really a folder that the OS makes look like a file) to your Applications directory. Done.
Linux OTOH, goes like this: Find the RPM you want. Try to install and get a list of dependencies. Go track down every dependency you need (because you should already have libart_gpl and libtheora, right?!) and then install the dependencies. After spending and hour or two just to install one piece of software, log out and log back in so the menus update. Then try to run the software and hope that you didn't accidently install an incompatible binary. ARRRGGGHHH!!!
Agreed. OEM support is a big issue. Many of the problems I ran into when testing various distros wouldn't happen on an OEM machine.
How do you figure? What do you mean by OEM? Where do you buy these OEM machines with RedHat on them? From RedHat? HP? IBM? I know IBM has built "solutions" for people based on several different distros, if memory serves, and I know that you can purchase machines with several distros pre-installed.
Why is that important anyway? Surely any company that can afford a datacenter of any meaningful size can afford to pay a sysadmin who can handle installing Linux herself.
It seems to me that you've never actually supported a corporate environment. These OEM installs and contracts are in place not because they are better than custom built machines, but because there's someone to blame (other than the technology department) when things go wrong.
How about you come back when you know what you're talking about?
If the os let a person say:
burn song.wav to cd1 as audio-cd
burn all songs in c:\mp3 to cd1 as data-cd
that would be pretty easy and friendly. But no os does that AFAIK. No reason you couldn't make a bash alias to do that and then it would be easy for people.
Actually, that looks pretty close to AppleScript. Unfortunately, the "ease of use" tends to become a liability to advanced users, as they have difficulty remembering the syntax.
1. Why are people running GDM on servers?
Because Dell ships them that way?
2. RedHat !f= (doesn't fucking equal) *nix on x86.
If you're a company looking for OEM machines, it does.
3. WTF does Apache have to do with ANYTHING? Apache is Apache, it's the same Apache whether running on an x86 *nix or a "Unix Machine".
I didn't say Apache had anything to do with anything. I said that RedHat's XInetD happily screws up the process of starting and stopping it.
4. I have never seen a *nix without a large number of startup / shutdown / whatever scripts, and I have yet to see any major headaches from toying with them, anywhere, ever, on any *nix. Why on earth is this non-existent "x86 *nix" problem not also a problem on "Unix Machines" that also have lots of scripts?
It's only a problem on RedHat. They have tons and tons of interdependent shell scripts that do Lord knows what, but the system breaks when they stop working. A perfect example (albeit no longer applicable) was the old X-Windows init script. It was designed to allow you to switch Window Managers from a shell script. It was actually pretty neat, but the slightest X11 change would throw the whole script out of whack, and suddenly X-Windows wouldn't work anymore. I've never seen any other Unix use so many fragile scripts in the core system.
Wrong. In 2000 when SGI offered me an O2 for $25,000, it would've taken 5 of them to do the same job as one $3,000 Dell Pentium2.
It's called "capacity planning". If you're buying a bigger machine than your capacity calls for, then of course you're spending extra money. OTOH, if you can put your web server, email server, domain server. file server, etc. all in the same box, then you're saving money over the proliferating x86 boxes.
BTW, four years ago, Sun was pretty much the only Unix machine vendor that was attempting to attack the low end as well as the high end. IBM sort of did, but most of their small machines were for product demoing purposes.
I suppose that in the 4 years that've gone by since a UNIX dealer has last tried to sell me anything, they might've gone more into a desperation mode and started reducing prices to get competitive with Intel/AMD systems again.
Sun makes some very nice Ultrasparc Rackmount and Blade systems starting at $999. That's pretty hard to beat, even for Dell.
Those are all areas where an x86 PC trounces Sun or SGI systems. With Sun, the annual maintenance fee can often exceed the lifetime ownership cost of a PC variant.
I don't know if you've been paying attention, but Dell has also been charging exorbitant yearly maintenance fees for their server products. I know a small company that just payed $50,000 to Dell for their yearly maintenance. When you consider that those maintenance costs are for replacement of hardware that fails (and with Dell it *will* fail), there's simply no way to get away without those costs. The only alternative is to do without maintenance and absorb any costs for replacement hardware. And I'd much rather do that with a small Sun machine and a Solaris Free license than I would a Dell.
Funny how you latch on to the worst of the bunch and then loudly proclaim how much all Unix machines suck. Sun machines are *nice*. I'm sorry you've had the displeasure of having to deal with AIX, but that doesn't mean that other vendors don't have their act together. Personally, I'll never understand why people keep buying the massive heaps of garbage that IBM puts out. Oh, that's right: "No one ever got fired for buying IBM."
Why, because you've found some mystical, magical fix for it? The reality is that RPM hell is a symptom of a larger problem -- that different programs often want different versions of shared libraries.
Actually, I have. It's called Mac OS X. And somehow ISVs are able to release all kinds of software based on Open Source without littering my hard drive. Examples include Safari (KHTML), OpenOffice, a LAME GUI that integrates with iTunes, DigiTunnel VPN, Firebird/Thunderbird, VideoLAN player, and ToastCD. All of these install by opening the DMG file and dragging the application to the Applications folder (or wherever else you want it).
The basic problem with RPM hell, is that RedHat made the decision to base every component of the OS on the RPM package manager. This means that really stupid dependencies like the version of Bash (for GUI apps even!) interfere with the system. FreeBSD doesn't have this problem, because all of their packages assume the base system. It doesn't bother to check if you have BASH, TCSH, or KSH installed, because it doesn't matter!
While I agree with what you're saying, I do have to say that companies like Sun have a point. They simply can't embrace a toolkit like QT without forcing their customers into unexpected costs. QT is far superior to GTK (although Sun is helping GTK catch up), but the Unix companies already did this once with Motif. They're unlikely to do it again.
That being said, TrollTech should continue to serve their customers and develop a great product. Those who are willing to absorb the costs of QT will find themselves with a great product.
Sadly enough, BSDs are not really considered in large corporate environments. Companies are too busy competing over who's got the "best" stuff to care about anything that actually *works*. It's all about posturing. Thankfully, many web service providers and ISPs keep chugging along with BSD, and nobody's the wiser.
Sun is attempting to deliver a powerful solution that the market *needs*. However, the market *wants* something different. As a result, Sun is reinventing themselves to make money. It's really a sad state of affairs, but then again the entire economic setup is.
Unfortunately, we don't have a better name for that family of chips. It's kind of long to be naming out Sparc, PowerPC, MIPS, Alpha, etc.
As you said, MIPS is pretty close. I think that only the SIMD instructions that various hardware vendors have added are actually multiple cycle per instruction.
I don't know what those other problems you speak of stem from, for I have many RedHat boxes and have not experienced them. Perhaps the admins are idiots?
/usr/local, this goes in /opt, this goes in /usr/share/, that goes in /use/bin, this goes... over there! Oh, and you don't need the Sun 'tar' utility. Use this instead! Ugh.)
Yes and no. The GDM problem, for example, happens when you configure the hostname. For some lame reason, GDM tries to do a reverse lookup on the hostname, and fails to start if it can't. I don't remember all the details right now, but it didn't even like it if you used a hosts file.
The starting of daemons problems are caused by RedHat's insistence on trying to map XinetD to the concept of Windows Services. The configuration tools never work right, and the whole thing happily blows up. I've tried to tell admins to use the command line, but they want to do it the "RedHat approved way" for purposes of support.
It may have improved, but last I checked, RedHat systems are littered with extremely complex shell scripts to do every little thing. These shell scripts work fine if you don't dive too deep into the system, but they easily start breaking as soon as you start trying to ratchet up security, or install system level software.
RPM hell is, well, RPM hell. Eventually you install yourself into a corner, where you've got a set of mismatched dependencies. After that point, you can only force installs. You can't even uninstall anything because the dependencies have gotten so tangled. Thus the "standard" position for managing RedHat servers is to multiply them like windows machines (one task per machine), and reinstall the OS every time you requisition a machine. This procedure is covered over by the constant need to "upgrade" to the latest and greatest (and highly unstable beta software) release of RedHat Linux.
A Solaris box is also difficult to work with on the first go-round. Usually you get sent to Sun classes and everything becomes clear.
A Solaris box is complex. But I've really never seen anyone do irreparable harm through normal use of the machine. I remember when I received my first Solaris machine. I was a Unix newb, and had to struggle through quite a bit. But I found that the machine was well designed and laid out, and eventually I found everything I needed. The only concern I ever had with Solaris was trying to reign in the Open Source software from making a big mess out of my hard disk. (Ok, this goes in
Are you saying that this is an inherent language problem, or simply an implementation problem? i.e. Does the Jython interpreter display this issue, or only the native Python compiler/interpreter?
When referring to concepts like Total Cost of Ownership and capabilities/features offered, one has to refer to the "Complete Package". The primary competitors are:
Sun Solaris (UltraSpace)
HPUX
AIX
WinTel
LinTel (pretty much only RedHat comes in OEM form)
The later two represent the "low-end" x86 platform, while the former three represent the "high-end" Unix/RISC platform.
You wrote an entire reponse to something he didn't say. He never said he was advocating Winx86. He said that the older SUN/SGI style hardware was losing marketshare in favor of X86 hardware. Which of course is correct. He didn't say that these cheaper X86 boxes wouldn't be running a *nix.
Allow me clarify. When I say "Unix Machines", I am referring to Sun, SGI, HP, and IBM Unix based hardware. While these machines can run other OSes, they are designed and engineered to run a variant of the Unix operating system. Thus "Unix machines". I was not referring to the operating system in specific.
And yes, RedHat does self-destruct at the slightest provocation. It's actually rather enjoyable (in a morbid way) to grab a bag of popcorn and watch as GDM suddenly disables itself, or the Apache "service" suddenly fails to start, or watch admins struggle with XInetD, only to have all their other "services" go haywire, or (my personal favorite) watch the admins struggle with some insanely masochistic script that no longer works because of some minor system change. Not to mention all the other scripts that were dependent on that script, which are now quite broken. I'm not even *going* to mention RPM hell.
Oh yeah, RedHat boxes are lots of fun.
Well judging by the amount of people dropping their old UNIX gear, and taking up rackfulls of AMD or Intel boxes (especially the new 64bit offerings), i'd say the answer to that is a big YES.
I would disagree. And I'll tell you why:
1. It takes fewer Unix boxes to accomplish the same job as the ever multiplying rabbits^W x86 machines. This consolidation makes for lower overall costs in equipment and maintenance. Unfortunately, x86 looks cheaper up front. No one considers concepts like capacity planning. Just add another box. They're cheap!
2. Dell (and their competitors) charge a mint for "server hardware". So much that Sun hardware often comes in cheaper. Again, managers thing x86 == cheap and Sun == Expensive.
3. Unix machines allow you much more flexibility in remote maintenance, system configuration (just try to tweak the size of write buffers on Windows), and live upgrades. Linux theoretically offers many of the same benefits, but RedHat deployments have a tendency to self destruct. I've seen admins actually afraid to touch their RedHat boxes for fear that something will go wrong.
4. Performance isn't everything. Reliability, uptime, maintainability, etc. are all worth paying extra for. The short sightedness of the industry results in these factors often being ignored. As a result, big money is spent on all three areas *after the fact*. (A company I worked for once had a Dell RAID controller go. The entire production database was corrupted on ALL drives. That hurt.)
Long term, Unix machines still win the day. This is very much due to the fact that the entire machine is engineered instead of cobbled together. It's just too bad that the entire industry is only looking at the short term.