No, that won't work. The RAM we use needs to be refreshed many times each second to maintain the charge of each bit. There are chips out there that maintain their state when unpowered, but they're significantly slower.
What you'd need to do is power the CPU, RAM and hard drive until you can dump the registers to RAM, and then dump RAM to the hard drive. However, to dump RAM to the hard drive, you'd need to power the whole motherboard -- since you need the northbridge, southbridge and all the PCI slots since there's no way to tell in hardware where your IDE/SCSI controller is -- and all IDE/SCSI devices -- because you never know in hardware which one of them you need to dump to.
In other words, with current hardware, you need to power the whole system until you can execute a suspend-to-disk.
Why didn't Doom 3 for Linux ship with this? Why does about every game I have bought in the past two years on Windows support surround sound just fine?
Allow me to rewrite your question from an opposite perspective:
Why did id choose to write its sound code using an API that hasn't been actively developed by the community in years, and from which everyone is moving away? Why didn't they write code that works with what people are actually using?
People are working on sound for Linux. It's called ALSA. It's what pretty much everyone using a 2.6 kernel will be using. It does desktop audio. It does professional audio. [1] It emulates OSS for legacy compatibility, but if you want to actually take advantage of its features, you need to actually use it.
So, yes, why didn't Doom 3 on Linux ship with this? Because id didn't put in the extra effort, and because they wanted to support the old API for some reason. This isn't the fault of 'the community.' The API is already out there. ALSA didn't just suddenly gain support for surround sound. It's had it. The fact here is that id is just now including support for the current Linux sound architecture.
Would you blame Microsoft if Halflife 2 only used features from DirectX 6 at first, and then in a later patch they updated it to use DirectX 9?
[1] ALSA doesn't work too well on some cards unfortunately. The reason for this is that some companies refuse to release specifications in order for drivers to be written. This means that the developers (only a few people) have to reverse engineer the cards to write drivers. This is hardly the fault of 'the community' either, and really, they've done a remarkable job on some of them, considering what they've had to work with.
It's not quite as black and white as you make it out, and my comment wasn't about how much I pay for software, but the way I can install it.
I'm running Linux, and I have programs that I bought installed. Right now it's just Quake 3, but there are other Linux games I have around, I think, and they work similarly. Quake 3 is handled by my package manager (portage). I put in the cd typed "emerge quake3" and it was set up and ready to run. If I installed Guitoo, or some other graphical front-end, I could have inserted the cd, clicked on quake3, and clicked install.
Other package managers might not handle such pay-for packages similarly, but they probably could.
I just fail to see how drag-and-drop is the end-all of software installation. Click one button isn't any harder.
Would I buy a stereo by looking at a list? Maybe, if that list were an online catalog, with pictures and links to the manufacturer's web page. Package managers typically have such links so you can find out information about a package, so it's not like I'm just rolling some dice and installing randomly.
Yes, in the real world, program installation is neither drag-n-drop or select-n-click. You need to look up information to differentiate open source stuff? Well, yes, but you might need to find and install several shareware apps before you find exactly what you want to buy. Neither one is easier than the other. They aren't even very different fundamentally.
I just get a little peeved when someone comes along and says, "The only way for Linux to succeed is for it to do Z exactly like OSX," and they get modded up to +5. The was Linux does software installation is fine, and only gets better over time. OSX hasn't jumped to 50% marketshare either, and in fact, depending on who you ask, Linux is neck-in-neck with OSX on the desktop.
Apologies for the rant. I need to stop reading Slashdot for a while, I think.
If they're following the Linux Filesystem Hierarchy Standard, they'll put it exactly where it says in what I quoted, which, incidentally, seems to be wher Slackware is putting it. I don't know what they actually do. However, you still haven't answered where the logical place to put it is, other than/usr/lib. The only thing that immediately comes to mind is/opt, but that's most likely not the right place to put it either, assuming it's an official package for your distribution.
What you appear to be saying is that instead of every distribution's "asshat filesystem architect" choosing where to put installed packages, you want every single developer to individually choose where his package goes? That way there's absolutely no enforcement of the way things are laid out on a particular distribution? If I like to put all the software I build in/boot/foobar/bucknasty, the dammit, that's the only sensible place to put it. Yeah, that makes a lot more sense.
If OSX is to be truly ready for the desktop, we need a system like in Linux. Something that is intuitive and simple as looking at a list of available applications of a type, picking the one I want, and clicking a button that says 'install'.
I don't want to have to go to a store and buy CDs or spend a long time searching Google for software that will run on my machine, then download an archive, and finally get the delivery media opened, and drag it somewhere on my hard drive.
Seriously, how is Drag-n-Drop easier than Select-n-Click? Of course, saying "OSX is good" is a safe bet here, because you'll automatically get modded up. I'm not saying OSX is hard, but Linux is not hard in this area either.
Purpose/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22]
Applications may use a single subdirectory under/usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
/usr/lib/mozilla is for all the libraries and support binaries and so on that mozilla has. The only thing that should be elsewhere is/usr/bin/mozilla which should be a script or binary that starts up mozilla (eg. calls mozilla-xremote-client or some such), and a few other random pieces sprinkled around (like KDE/Gnome menu entry info).
Can you name a modern package manager (apt, yum, portage,...) that doesn't fulfill this requirement, assuming you're using a managed package repository, and not trying to install foo.rpm off of Joe's Elite Software Website?
"The Gimp is a shit sandwich" gets modded up as insightful.
My pointing out that someone is being given software for free and they instead choose to complain about it and call it a "shit sandwich" get modded as flamebait.
Nobody has to give you anything for free. The Gimp developers write their software out of their own interest, and give it away out of the goodness of their heart. So unless you want to pay them, or do the work yourself, don't complain about what you get. You don't have to eat a "shit sandwich." You can have absolutely nothing instead.
Gimp already is pretty far away from tradinional GUI.
If that's true, then why does Photoshop on MacOS continue to have an interface very much like The Gimp (or, one could more correctly say, The Gimp has an interface much like Photoshop on MacOS)?
Also, notice that no one complains about Photoshop's interface on MacOS. Perhaps that means it's not a flaw inherent in that sort of interface at all.
There may be UI flaws in The Gimp (and quite likely in Photoshop, on both Mac and Windows), but they probably aren't best solved by wrapping everything in a big window.
If the interface is crippled, why does Photoshop on MacOS (where it originated) still have a Gimp-like interface? Do you see people flaming Adobe for this interface every time Photoshop is brought up? No, instead Photoshop is one of MacOS's big claims to fame. Could it be that Photoshop's Windows interface is an artifact of the way that Windows handles things (taskbar and such), rather than the alternative being inherently flawed?
Perhaps Gimp on Windows would be better if it had a Photoshop on Windows UI, but things aren't the same in Linux. Using a separate desktop for the Gimp is quite easy, and provides many of the benefits of a single-window interface. The only immediate difference that comes to mind is the want of a single menu in a non-moving place, and I agree, I wish gtk would support this like KDE and MacOS does (single application menu in the top left, if you want). However, encasing every application in a big window is not a good solution to this problem.
The Gimp on Windows is closer to an afterthought than a #1 priority. The Gimp developers should be primarily concerned with making a good interface on the primary system for which it's designed, and that's Linux. It doesn't make sense to make an application primarily for Linux, but have a UI designed to work around the particular quirks of Windows or MacOS or BeOS or whatever.
Quite frankly, if anyone's on a high horse, it's you, and everyone else demanding that The Gimp developers address UI issues that only you have deemed of highest importance. If you want things 'fixed,' you'll probably either have to do it yourself, or give some monetary compensation to someone who can do it for you. Comlaining on Slashdot and throwing insults at "fan boys" won't get you anywhere, especially with a "problem" that the majority of users probably don't see as a problem. Perhaps it's you that have learned to cope with a crippled window management system that is worked around by the applications you use.
As a final question: if Photoshop hasn't changed in 10 years, why do you keep buying new versions? You could just keep using your 10 year old version without loss of value, right? Or has Photoshop actually added new features that make newer versions useful. And might those new features be more useful than a rewrite of The Gimp's GUI subsystem?
Most of these products probably aren't marketed as 'iPod killers'. They're just marketed as MP3/music players. However, that doesn't make for good headlines/page view tallies on mp3newswire or Slashdot, so people feel compelled to call every mp3 player an iPod killer.
iPods are currently the most popular mp3 player (by far), so it's easy to characterize any mp3 player in terms of an iPod. I could just as easily characterize everything as a Nomad killer, or an iRiver killer, but less people would know what I'm talking about, and it wouldn't make sense since they're not the most popular mp3 player.
Or are you saying that you only buy the most popular of any given product space? Will you not drink RC Cola because I could say, "It's like Pepsi." Do you only buy Kleenex brand facial tissues? Would you have never bought a portable cassette player that's not a Sony Walkman?
Then go find an equivalent program that's coded in bare X11. It probably won't be as usable, or look as nice, or do nearly as much, though, because coding in bare X11 is way more work, and the developers will have to spend more time making their own GUI system instead of focusing on making the application actually do stuff.
Those libraries are around so that not everyone has to rewrite the same stuff every time they build an application. Do you think glibc is useless too? Should we all be writing our own memcpy routines for every program we write? Or how about we scrap X11 and have every program access the framebuffer directly? Sure, it's more work, but I won't have to install X11 or XDirectFB or some other graphical subsystem just to use graphical programs.
I worked at a company where we used a certain web-based collaboration suite. Part of my job was to fix existing bugs in said suite some of which were caused by our particular setup. For our particular version of the suite, this was their supported setup:
Weblogic 7 JDK 1.3.x
Now, our Weblogic people, whom we had no control over, decided to upgrade to Weblogic 8. Weblogic 8 requires JDK 1.4. It won't work with 1.3, or at least, I couldn't get it to work in my hours of trying (Note, 1.3 to 1.4 is just a "minor" version change, not a major revision like 1.x to 2.x (which, I might add, usually signals a significant break in API compatibility, so you probably should have known), although with Sun's naming conventions, you never really know).
Now, when you use our particular version of the collaboration software with JDK 1.4 and Weblogic 8, it breaks various parts of the application. The solution? "We don't know what the problem is but it's fixed in our upgrade release." Now, we could just upgrade our suite of collaboration software, except it will break tons of stuff that we built on top of it, I assure you.
I had to dig through their source and track down what was broken and fix it myself. Keep in mind, this suite is the best in its realm, so with anyone else, you'd probably be worse off.
So don't tell me that Open Source has problems with version compatibility that commercial software just doesn't have. These systems are all produced by big corporations, and they just flat don't work between revisions. It's a struggle whatever you use.
1. Find what you want in a list of packages 2. Click to install 3. Enjoy!
Debian/Ubuntu with a front end for the package manager can pretty much do that (as can many other systems, I'm sure). If you're willing to go slogging through tons of web pages looking for LSB certified packages, then it should be no problem to slog through a list of possible packages to install. And Debian's sources will have every package you could reasonably want. If you don't find it in apt, you probably won't find an LSB certified package (because it will be some small-time/new stuff that you'll have to build from source).
You shouldn't have to recompile your kernel unless you have really weird hardware. Vendor kernels packaged with the system should work for any remotely normal machine (barring the currently poorly-supported due to uncooperative hardware vendors crop of wireless cards).
Okay. If I use Linux From Scratch, or even Red Hat, I can do everything that Gentoo does by hand.
I just checked, and I have 459 packages on my system. Sure, you could look at the./configure output for every single one of them, and figure out what optional support they have, and then enable/disable the flags as appropriate, and in addition, fetch all the optional dependencies by yourself. Do you really have the time and energy to do that for hundreds of packages?
With use flags, you can, for the most part, set them once globally and then build your system, and everything will have appropraite support. Let's suppose you're some kind of fanatic and want to eliminate jpeg support from your computer. Isn't it easier to add USE=-jpeg to a config file than it is to track down all (20 or so on my computer) packages that have optional jpeg support and compile them without?
If you change your mind about wanting support for something on Slack, are there tools for evaluating which packages need to be recompiled, and which packages can be removed? Or do you have to do all that manually?
It's not just flexibility that's important, it's the automation of that flexibility. You can get the power/flexibility advantages of any system if you do everything by hand, but if it's not convenient it's rather worthless, since you spend more time preparing for things than actually doing them.
Gentoo has a pretty good way of passing configure flags and the like into the compiling package (use flags). I'd be willing to bet that most people use those.
So if I don't want to use X, it's easy to have everything compile with svga support, but not waste time trying to support and link to X libraries. And if I want X but not svga and DirectFB support, it's easy to do that as well.
For example, at one time I had mplayer compiled with support for all three. Then later I deleted DirectFB (since I never use it), and mplayer failed to run, because it was trying to load libraries that weren't there. I was a bit confused at the errors at first, before I realized that I needed to recompile, so I googled for the error messages I was getting, and found a bug report for some other distribution. I believe their fix was, "You must have DirectFB installed," whereas the Gentoo solution would be, "recompile without support for DirectFB."
There are other examples, like support for various databases, GUI toolkits (mozilla could be either GTK 1 or GTK 2 for a while) and desktop environments (do you want package Z's support for Gnome, KDE, both or neither?).
That flexibility is much more interesting than creating a custom filesystem layout (which, incidentally, you can do on any distribution I've ever tried).
All of Apple's computers, except the really high end ones, come with 256 MB of RAM standard. That's low these days. 512 is pretty standard, and if I were building a computer, I'd put 1 GB in, because that only costs about $150. Upgrading from 256 MB to 1 GB costs $225 for a Mac, though. The video cards are also on the low end.
When I was pricing recently, I came up with a setup that goes something like this:
The price of that was around $900. It doesn't include a monitor, but I can buy a 17" CRT (which the eMac has) for a little over $100. So are you saying that the eMac with a G4 1.25 GHz, a Radeon 9200, and a 40 GB hard drive will outperform the above machine (both would have a gig of RAM for equivalent pricing)?
Looking at the Mac store, I'd call the iMac a mid-range machine, and it starts at $1,300. Upgrade the hard drive and memory to what I'd consider acceptable, and it ends up being like $1,600.
I can't really fight on the laptop front, though. I really have no desire for a laptop, so I'm not in touch with their pricing. I could do some research, if you wish, though.
Where are the mid-range machines for $900? I looked at the online apple store, but the closest I could find are eMacs for $800, and iBooks for $1000. Neither one of those are really what I'd consider mid-range machines today.
Well, true, their prices are well above Newegg's, but that's true of pretty much any physical store over an online reseller. If you buy stuff at Best Buy or CompUSA or whatever, you can probably expect to pay at least 50% more than whatever Newegg is selling the retail-box version for.
Someone noted that you have to weigh that against the wait, but there's also some stuff you probably don't want to buy online. I've heard bad things about buying things like LCDs online. From what I hear, usually brick-and-mortar stores have better return policies for things like dead pixels than your typical online reseller.
I've never been to a Fry's, so I can't comment on them.
Slashdot Mirror
No, that won't work. The RAM we use needs to be refreshed many times each second to maintain the charge of each bit. There are chips out there that maintain their state when unpowered, but they're significantly slower.
What you'd need to do is power the CPU, RAM and hard drive until you can dump the registers to RAM, and then dump RAM to the hard drive. However, to dump RAM to the hard drive, you'd need to power the whole motherboard -- since you need the northbridge, southbridge and all the PCI slots since there's no way to tell in hardware where your IDE/SCSI controller is -- and all IDE/SCSI devices -- because you never know in hardware which one of them you need to dump to.
In other words, with current hardware, you need to power the whole system until you can execute a suspend-to-disk.
Why didn't Doom 3 for Linux ship with this? Why does about every game I have bought in the past two years on Windows support surround sound just fine?
Allow me to rewrite your question from an opposite perspective:
Why did id choose to write its sound code using an API that hasn't been actively developed by the community in years, and from which everyone is moving away? Why didn't they write code that works with what people are actually using?
People are working on sound for Linux. It's called ALSA. It's what pretty much everyone using a 2.6 kernel will be using. It does desktop audio. It does professional audio. [1] It emulates OSS for legacy compatibility, but if you want to actually take advantage of its features, you need to actually use it.
So, yes, why didn't Doom 3 on Linux ship with this? Because id didn't put in the extra effort, and because they wanted to support the old API for some reason. This isn't the fault of 'the community.' The API is already out there. ALSA didn't just suddenly gain support for surround sound. It's had it. The fact here is that id is just now including support for the current Linux sound architecture.
Would you blame Microsoft if Halflife 2 only used features from DirectX 6 at first, and then in a later patch they updated it to use DirectX 9?
[1] ALSA doesn't work too well on some cards unfortunately. The reason for this is that some companies refuse to release specifications in order for drivers to be written. This means that the developers (only a few people) have to reverse engineer the cards to write drivers. This is hardly the fault of 'the community' either, and really, they've done a remarkable job on some of them, considering what they've had to work with.
It's not quite as black and white as you make it out, and my comment wasn't about how much I pay for software, but the way I can install it.
I'm running Linux, and I have programs that I bought installed. Right now it's just Quake 3, but there are other Linux games I have around, I think, and they work similarly. Quake 3 is handled by my package manager (portage). I put in the cd typed "emerge quake3" and it was set up and ready to run. If I installed Guitoo, or some other graphical front-end, I could have inserted the cd, clicked on quake3, and clicked install.
Other package managers might not handle such pay-for packages similarly, but they probably could.
I just fail to see how drag-and-drop is the end-all of software installation. Click one button isn't any harder.
Would I buy a stereo by looking at a list? Maybe, if that list were an online catalog, with pictures and links to the manufacturer's web page. Package managers typically have such links so you can find out information about a package, so it's not like I'm just rolling some dice and installing randomly.
Yes, in the real world, program installation is neither drag-n-drop or select-n-click. You need to look up information to differentiate open source stuff? Well, yes, but you might need to find and install several shareware apps before you find exactly what you want to buy. Neither one is easier than the other. They aren't even very different fundamentally.
I just get a little peeved when someone comes along and says, "The only way for Linux to succeed is for it to do Z exactly like OSX," and they get modded up to +5. The was Linux does software installation is fine, and only gets better over time. OSX hasn't jumped to 50% marketshare either, and in fact, depending on who you ask, Linux is neck-in-neck with OSX on the desktop.
Apologies for the rant. I need to stop reading Slashdot for a while, I think.
If they're following the Linux Filesystem Hierarchy Standard, they'll put it exactly where it says in what I quoted, which, incidentally, seems to be wher Slackware is putting it. I don't know what they actually do. However, you still haven't answered where the logical place to put it is, other than /usr/lib. The only thing that immediately comes to mind is /opt, but that's most likely not the right place to put it either, assuming it's an official package for your distribution.
/boot/foobar/bucknasty, the dammit, that's the only sensible place to put it. Yeah, that makes a lot more sense.
What you appear to be saying is that instead of every distribution's "asshat filesystem architect" choosing where to put installed packages, you want every single developer to individually choose where his package goes? That way there's absolutely no enforcement of the way things are laid out on a particular distribution? If I like to put all the software I build in
If OSX is to be truly ready for the desktop, we need a system like in Linux. Something that is intuitive and simple as looking at a list of available applications of a type, picking the one I want, and clicking a button that says 'install'.
I don't want to have to go to a store and buy CDs or spend a long time searching Google for software that will run on my machine, then download an archive, and finally get the delivery media opened, and drag it somewhere on my hard drive.
Seriously, how is Drag-n-Drop easier than Select-n-Click? Of course, saying "OSX is good" is a safe bet here, because you'll automatically get modded up. I'm not saying OSX is hard, but Linux is not hard in this area either.
Where would you put all that stuff?
Can you name a modern package manager (apt, yum, portage, ...) that doesn't fulfill this requirement, assuming you're using a managed package repository, and not trying to install foo.rpm off of Joe's Elite Software Website?
Yes, brilliant job moderators.
"The Gimp is a shit sandwich" gets modded up as insightful.
My pointing out that someone is being given software for free and they instead choose to complain about it and call it a "shit sandwich" get modded as flamebait.
Nobody has to give you anything for free. The Gimp developers write their software out of their own interest, and give it away out of the goodness of their heart. So unless you want to pay them, or do the work yourself, don't complain about what you get. You don't have to eat a "shit sandwich." You can have absolutely nothing instead.
You're right. It seems that more and more people are looking for Barack Obama porn.
http://www.vidalinux.com/
Gentoo underneath, easy installation on top (not that typing stuff verbatim from the web site isn't easy, but you get what I mean).
Gimp already is pretty far away from tradinional GUI.
If that's true, then why does Photoshop on MacOS continue to have an interface very much like The Gimp (or, one could more correctly say, The Gimp has an interface much like Photoshop on MacOS)?
Also, notice that no one complains about Photoshop's interface on MacOS. Perhaps that means it's not a flaw inherent in that sort of interface at all.
There may be UI flaws in The Gimp (and quite likely in Photoshop, on both Mac and Windows), but they probably aren't best solved by wrapping everything in a big window.
Yeah, that's way better than:
"Give me a sandwich with prosciutto and bacon!"
"All I have is regular ham."
"Fuck you! You can only make shit sandwiches with regular ham!"
Those Gimp developers are real assholes.
If the interface is crippled, why does Photoshop on MacOS (where it originated) still have a Gimp-like interface? Do you see people flaming Adobe for this interface every time Photoshop is brought up? No, instead Photoshop is one of MacOS's big claims to fame. Could it be that Photoshop's Windows interface is an artifact of the way that Windows handles things (taskbar and such), rather than the alternative being inherently flawed?
Perhaps Gimp on Windows would be better if it had a Photoshop on Windows UI, but things aren't the same in Linux. Using a separate desktop for the Gimp is quite easy, and provides many of the benefits of a single-window interface. The only immediate difference that comes to mind is the want of a single menu in a non-moving place, and I agree, I wish gtk would support this like KDE and MacOS does (single application menu in the top left, if you want). However, encasing every application in a big window is not a good solution to this problem.
The Gimp on Windows is closer to an afterthought than a #1 priority. The Gimp developers should be primarily concerned with making a good interface on the primary system for which it's designed, and that's Linux. It doesn't make sense to make an application primarily for Linux, but have a UI designed to work around the particular quirks of Windows or MacOS or BeOS or whatever.
Quite frankly, if anyone's on a high horse, it's you, and everyone else demanding that The Gimp developers address UI issues that only you have deemed of highest importance. If you want things 'fixed,' you'll probably either have to do it yourself, or give some monetary compensation to someone who can do it for you. Comlaining on Slashdot and throwing insults at "fan boys" won't get you anywhere, especially with a "problem" that the majority of users probably don't see as a problem. Perhaps it's you that have learned to cope with a crippled window management system that is worked around by the applications you use.
As a final question: if Photoshop hasn't changed in 10 years, why do you keep buying new versions? You could just keep using your 10 year old version without loss of value, right? Or has Photoshop actually added new features that make newer versions useful. And might those new features be more useful than a rewrite of The Gimp's GUI subsystem?
Most of these products probably aren't marketed as 'iPod killers'. They're just marketed as MP3/music players. However, that doesn't make for good headlines/page view tallies on mp3newswire or Slashdot, so people feel compelled to call every mp3 player an iPod killer.
iPods are currently the most popular mp3 player (by far), so it's easy to characterize any mp3 player in terms of an iPod. I could just as easily characterize everything as a Nomad killer, or an iRiver killer, but less people would know what I'm talking about, and it wouldn't make sense since they're not the most popular mp3 player.
Or are you saying that you only buy the most popular of any given product space? Will you not drink RC Cola because I could say, "It's like Pepsi." Do you only buy Kleenex brand facial tissues? Would you have never bought a portable cassette player that's not a Sony Walkman?
Then go find an equivalent program that's coded in bare X11. It probably won't be as usable, or look as nice, or do nearly as much, though, because coding in bare X11 is way more work, and the developers will have to spend more time making their own GUI system instead of focusing on making the application actually do stuff.
Those libraries are around so that not everyone has to rewrite the same stuff every time they build an application. Do you think glibc is useless too? Should we all be writing our own memcpy routines for every program we write? Or how about we scrap X11 and have every program access the framebuffer directly? Sure, it's more work, but I won't have to install X11 or XDirectFB or some other graphical subsystem just to use graphical programs.
I worked at a company where we used a certain web-based collaboration suite. Part of my job was to fix existing bugs in said suite some of which were caused by our particular setup. For our particular version of the suite, this was their supported setup:
Weblogic 7
JDK 1.3.x
Now, our Weblogic people, whom we had no control over, decided to upgrade to Weblogic 8. Weblogic 8 requires JDK 1.4. It won't work with 1.3, or at least, I couldn't get it to work in my hours of trying (Note, 1.3 to 1.4 is just a "minor" version change, not a major revision like 1.x to 2.x (which, I might add, usually signals a significant break in API compatibility, so you probably should have known), although with Sun's naming conventions, you never really know).
Now, when you use our particular version of the collaboration software with JDK 1.4 and Weblogic 8, it breaks various parts of the application. The solution? "We don't know what the problem is but it's fixed in our upgrade release." Now, we could just upgrade our suite of collaboration software, except it will break tons of stuff that we built on top of it, I assure you.
I had to dig through their source and track down what was broken and fix it myself. Keep in mind, this suite is the best in its realm, so with anyone else, you'd probably be worse off.
So don't tell me that Open Source has problems with version compatibility that commercial software just doesn't have. These systems are all produced by big corporations, and they just flat don't work between revisions. It's a struggle whatever you use.
The AMD board has PCI-X slots (1 at 133 MHz, 2 at 66 MHz), while the Intel board has 3 32 bit PCI slots, both in addition to the 16x PCI-E slots.
This is not a case of someone confusing PCI-X with PCI-E.
"Mom said I played too much games so we got a Mac instead. Now I get top grades!"
You might have to refresh a couple times before you see that one.
Yes, I realize that Macs have games, but the parent reminded me of that site, and the same could be said for Linux.
How is your list of options different from, say:
1. Find what you want in a list of packages
2. Click to install
3. Enjoy!
Debian/Ubuntu with a front end for the package manager can pretty much do that (as can many other systems, I'm sure). If you're willing to go slogging through tons of web pages looking for LSB certified packages, then it should be no problem to slog through a list of possible packages to install. And Debian's sources will have every package you could reasonably want. If you don't find it in apt, you probably won't find an LSB certified package (because it will be some small-time/new stuff that you'll have to build from source).
You shouldn't have to recompile your kernel unless you have really weird hardware. Vendor kernels packaged with the system should work for any remotely normal machine (barring the currently poorly-supported due to uncooperative hardware vendors crop of wireless cards).
Okay. If I use Linux From Scratch, or even Red Hat, I can do everything that Gentoo does by hand.
./configure output for every single one of them, and figure out what optional support they have, and then enable/disable the flags as appropriate, and in addition, fetch all the optional dependencies by yourself. Do you really have the time and energy to do that for hundreds of packages?
I just checked, and I have 459 packages on my system. Sure, you could look at the
With use flags, you can, for the most part, set them once globally and then build your system, and everything will have appropraite support. Let's suppose you're some kind of fanatic and want to eliminate jpeg support from your computer. Isn't it easier to add USE=-jpeg to a config file than it is to track down all (20 or so on my computer) packages that have optional jpeg support and compile them without?
If you change your mind about wanting support for something on Slack, are there tools for evaluating which packages need to be recompiled, and which packages can be removed? Or do you have to do all that manually?
It's not just flexibility that's important, it's the automation of that flexibility. You can get the power/flexibility advantages of any system if you do everything by hand, but if it's not convenient it's rather worthless, since you spend more time preparing for things than actually doing them.
Gentoo has a pretty good way of passing configure flags and the like into the compiling package (use flags). I'd be willing to bet that most people use those.
So if I don't want to use X, it's easy to have everything compile with svga support, but not waste time trying to support and link to X libraries. And if I want X but not svga and DirectFB support, it's easy to do that as well.
For example, at one time I had mplayer compiled with support for all three. Then later I deleted DirectFB (since I never use it), and mplayer failed to run, because it was trying to load libraries that weren't there. I was a bit confused at the errors at first, before I realized that I needed to recompile, so I googled for the error messages I was getting, and found a bug report for some other distribution. I believe their fix was, "You must have DirectFB installed," whereas the Gentoo solution would be, "recompile without support for DirectFB."
There are other examples, like support for various databases, GUI toolkits (mozilla could be either GTK 1 or GTK 2 for a while) and desktop environments (do you want package Z's support for Gnome, KDE, both or neither?).
That flexibility is much more interesting than creating a custom filesystem layout (which, incidentally, you can do on any distribution I've ever tried).
I can't think of any major package systems without a front-end. I've even seen a front-end for Slackware installation.
Well...
All of Apple's computers, except the really high end ones, come with 256 MB of RAM standard. That's low these days. 512 is pretty standard, and if I were building a computer, I'd put 1 GB in, because that only costs about $150. Upgrading from 256 MB to 1 GB costs $225 for a Mac, though. The video cards are also on the low end.
When I was pricing recently, I came up with a setup that goes something like this:
Athlon 64 2800+
1 GB RAM
200 GB hard drive
GeForce 6600
The price of that was around $900. It doesn't include a monitor, but I can buy a 17" CRT (which the eMac has) for a little over $100. So are you saying that the eMac with a G4 1.25 GHz, a Radeon 9200, and a 40 GB hard drive will outperform the above machine (both would have a gig of RAM for equivalent pricing)?
Looking at the Mac store, I'd call the iMac a mid-range machine, and it starts at $1,300. Upgrade the hard drive and memory to what I'd consider acceptable, and it ends up being like $1,600.
I can't really fight on the laptop front, though. I really have no desire for a laptop, so I'm not in touch with their pricing. I could do some research, if you wish, though.
Where are the mid-range machines for $900? I looked at the online apple store, but the closest I could find are eMacs for $800, and iBooks for $1000. Neither one of those are really what I'd consider mid-range machines today.
Well, true, their prices are well above Newegg's, but that's true of pretty much any physical store over an online reseller. If you buy stuff at Best Buy or CompUSA or whatever, you can probably expect to pay at least 50% more than whatever Newegg is selling the retail-box version for.
Someone noted that you have to weigh that against the wait, but there's also some stuff you probably don't want to buy online. I've heard bad things about buying things like LCDs online. From what I hear, usually brick-and-mortar stores have better return policies for things like dead pixels than your typical online reseller.
I've never been to a Fry's, so I can't comment on them.