I would like to disagree with the moderation of your comment, it is *not* funny. It is $&#*ing tragic. There was a problem "every printer needs it's own #!*& driver", there were at least two solutions, postscript and PCL that date back to at least the 1980s. But, unless you've got something fancy enough to be considered a network printer, odds are that "the printer still needs it's own #!*& driver". Postscript printers were not-so-common in the 1980's because it was computationally expensive and microprocessors and RAM were not cheap back in the 1980's, but they *are* cheap now. So, let's recap:
1) We had a problem
2) We found a technical solution 30 years ago
3) We still have the same problem, I have no idea why.
So Microsoft claims 11% less users use the start menu in Windows 7 vs. Vista. I'll believe that; I assume everybody using Vista uses the start menu, so they're only deprecating a feature used by 89% of all users.
The problem with, say Ubuntu, packaging a lot of open source software without contributing upstream is that Ubuntu doesn't just package the software unmodified, they make changes to add desired features, fix bugs, and get different pieces of software to integrate better. But, since they don't contribute many of their changes upstream, the upstream developers will change the software without any regard for whether the downstream Ubuntu patches, so if the Ubuntu people want to pull in a new version of the upstream code, they also have to update their patches. As Ubuntu introduces more and more patches, they do more and more work maintaining their local branch of the software, until it gets to the point where they are expending as much effort as if they'd just wrote things themselves. For Ubuntu, this is most pronounced with GNOME, Canonical was not involved enough in GNOME development, so the GNOME guys went off and did their own thing while Canonical developed Unity. Now you have two frontends to GNOME, but the Ubuntu guys can't get certain upstream changes made, because upstream doesn't care about Unity, only GNOME shell, which means more work for Ubuntu developers.
It's true that if you don't need to patch anything, then there's really no incentive to contribute, but when you *are* going to make modifications then you're in the situation Zemlin's talking about; it's almost always in your self-interest to get the changes merged in upstream. It's a little bit of extra work in the short-term that saves you effort in the long run.
Despite massive code-churn, chrome's UI has been pretty much static, at least for as long as it's had a Linux port. I think they're on to something. Once people get used to using the browser (or any program, for that matter), they don't want to relearn the interface after every update, they just want the damn thing to work.
I sincerely doubt XFCE will ever get a major UI overhaul like Gnome and KDE periodically do, for one, I don't think they have enough developers that they'd even want to try.
I imagine you could probably get someone to give you a pentium-based computer for free, and it may indeed perform sufficiently well to accomplish some basic, low-load server type tasks, but I think most people would prefer to put processors that were designed sometime in the last decade in their servers instead.
The mac mini is a great little machine, and it's not even over-priced if you *want* something that small, but it's kind of limited in it's I/O capabilities. You can put two hardrives in the latest revision, as long as you're OK with losing the optical drive, and then you can spend the better part of a day trying to take one out and replace it if it fails. I suppose other people may have different opinions, but if I ran a server for my business, I'd want the hardware maintenance to be dead simple. In fact, I'd want hot-swappable drives, so I don't even have to take the machine down to do the drive replacement. And I'd want at least the *option* to install at least 4 sata/esate drives.
The "mini-server" runs $999 currently, for that price, I'm sure you could build or buy yourself a much bigger, but also much more convenient to work on tower, with as powerful a processor, and significantly expanded I/O options, which also probably consumes a bit more power as well as performs slightly better. Then install CentOS and you're good to go.
But, to reply more to the parent than to you: it's not like you're just going to be using this over wireless internet; some people actually have DSL or better connections with less then 40ms of latency; at rates like that a codec latency of 4ms is still 20% of the total latency. At that kind of latency 45ms you could play music with someone without driving yourself crazy because you both sound like your lagging behind the beat (you WILL both appear to be lagging to each other, but 45ms is a small enough amount of latency that it won't completely destroy the performance). In fact, even 100ms of total latency is probably survivable in a mid-tempo song (but will be very noticable), anything you can do at the codec level to chop that down improves the experience.
Wasn't the whole point of IPv6 being essentially independent of IPv4 so that you COULD run dual stacks? Because it would be completely un-reasonable to be able to cut-over from one addressing protocol to another world wide in any reasonable fashion? So... yes, dual stacks for the next 20 years on main-stream devices, maybe 70-80 years for niche needs sounds reasonable to me.
The thing is you can't necessarily fix a bad gui, unless you're working with something where you have access to the source and can replace the code; with cli, you can alway's script your way around a problem. Your programs doesn't validate input? Write an input validater and pipe it through that. Obviously, cli is great for batch operations and automation, as well. Even if it's a black box, proprietary system. Even if you can change the code, which is easier to do? Spend 15 minutes or less working in your favorite scripting language or source the application source, patch it, re-compile if necessary, test, then apply the operation? (Especially if this is a one-off operation).
According to the article, blaze customers can get "up to 10mbs" of bandwidth, though they don't specifiy if that's up/down or split symmetrically. This probably reflects an improvement in the technology over the past decade. As long as the latency isn't horrible, this sounds quite competitive vs. aDSL, although aDSL is also much, much cheaper (at least in areas with a reasonably dense population). Of course, the whole point is that there's really no other option besides dial-up.
Not to mention that many CS and IT students, who will encounter Unix/Linux for the first time at their university, might be exposed to Solaris and be convinced that it's the best Unix, simply because it's the one that they are most familiar with. (I'll bet this sort-of reasoning plays a bigger role in people's OS preferences than most would care to admit).
I think you underestimate how much that would hurt Google themselves. If Google stops returning IBM-hosted pages how fast do you think they're going to start losing users who care at all about IBM to Bing? "Search neutrality" advocates will, of course, get up in arms over this, if Google was stupid enough to block a major company's sites, but this shouldn't even make it that far, since screwing up it's search results in a way noticeable by an appreciable number of users is bad enough for Google on it's own, even without a public and/or regulatory body outcry.
In your example though, it's proprietary software vs. proprietary software. What your example really seems to suggest is that "fat clients" aren't always better than "thin clients", and that you should've just renewed the license on your original, proprietary software.
Slashdot Mirror
Those gconf xml files remind me an awful lot of the windows registry...
I'd love to be able to transfer files that fast; I can't be the only one who misread the title.
So Microsoft claims 11% less users use the start menu in Windows 7 vs. Vista. I'll believe that; I assume everybody using Vista uses the start menu, so they're only deprecating a feature used by 89% of all users.
The problem with, say Ubuntu, packaging a lot of open source software without contributing upstream is that Ubuntu doesn't just package the software unmodified, they make changes to add desired features, fix bugs, and get different pieces of software to integrate better. But, since they don't contribute many of their changes upstream, the upstream developers will change the software without any regard for whether the downstream Ubuntu patches, so if the Ubuntu people want to pull in a new version of the upstream code, they also have to update their patches. As Ubuntu introduces more and more patches, they do more and more work maintaining their local branch of the software, until it gets to the point where they are expending as much effort as if they'd just wrote things themselves. For Ubuntu, this is most pronounced with GNOME, Canonical was not involved enough in GNOME development, so the GNOME guys went off and did their own thing while Canonical developed Unity. Now you have two frontends to GNOME, but the Ubuntu guys can't get certain upstream changes made, because upstream doesn't care about Unity, only GNOME shell, which means more work for Ubuntu developers. It's true that if you don't need to patch anything, then there's really no incentive to contribute, but when you *are* going to make modifications then you're in the situation Zemlin's talking about; it's almost always in your self-interest to get the changes merged in upstream. It's a little bit of extra work in the short-term that saves you effort in the long run.
13.0.782.107 (Developer Build 0 Linux) doesn't do that, although this is "chromium" not the branded "chrome".
Despite massive code-churn, chrome's UI has been pretty much static, at least for as long as it's had a Linux port. I think they're on to something. Once people get used to using the browser (or any program, for that matter), they don't want to relearn the interface after every update, they just want the damn thing to work.
That's linked in TFA, so apparently it didn't work in this case.
I sincerely doubt XFCE will ever get a major UI overhaul like Gnome and KDE periodically do, for one, I don't think they have enough developers that they'd even want to try.
In my experience, that rate of hardware failure on Apple hardware is pretty close to the rate of failure on non-Apple PC hardware.
I imagine you could probably get someone to give you a pentium-based computer for free, and it may indeed perform sufficiently well to accomplish some basic, low-load server type tasks, but I think most people would prefer to put processors that were designed sometime in the last decade in their servers instead. The mac mini is a great little machine, and it's not even over-priced if you *want* something that small, but it's kind of limited in it's I/O capabilities. You can put two hardrives in the latest revision, as long as you're OK with losing the optical drive, and then you can spend the better part of a day trying to take one out and replace it if it fails. I suppose other people may have different opinions, but if I ran a server for my business, I'd want the hardware maintenance to be dead simple. In fact, I'd want hot-swappable drives, so I don't even have to take the machine down to do the drive replacement. And I'd want at least the *option* to install at least 4 sata/esate drives. The "mini-server" runs $999 currently, for that price, I'm sure you could build or buy yourself a much bigger, but also much more convenient to work on tower, with as powerful a processor, and significantly expanded I/O options, which also probably consumes a bit more power as well as performs slightly better. Then install CentOS and you're good to go.
curl http://linux.slashdot.org/story/11/08/02/1736215/Are-Bad-Economic-Times-Good-for-Free-Software > /dev/null
(B) is un-true for an OEM license of any operating system AFAIK
Indeed, if you choose not to use dropbox, unison is almost certainly the proper choice for the job.
Aren't both iptables/ipchains Linux only? Doesn't NetBSD use pf like OpenBSD?
what kind of latency do you get with AAC? Do you know? (I'm trying to find out now via google)
But, to reply more to the parent than to you: it's not like you're just going to be using this over wireless internet; some people actually have DSL or better connections with less then 40ms of latency; at rates like that a codec latency of 4ms is still 20% of the total latency. At that kind of latency 45ms you could play music with someone without driving yourself crazy because you both sound like your lagging behind the beat (you WILL both appear to be lagging to each other, but 45ms is a small enough amount of latency that it won't completely destroy the performance). In fact, even 100ms of total latency is probably survivable in a mid-tempo song (but will be very noticable), anything you can do at the codec level to chop that down improves the experience.
Wasn't the whole point of IPv6 being essentially independent of IPv4 so that you COULD run dual stacks? Because it would be completely un-reasonable to be able to cut-over from one addressing protocol to another world wide in any reasonable fashion? So ... yes, dual stacks for the next 20 years on main-stream devices, maybe 70-80 years for niche needs sounds reasonable to me.
Then how can they know they don't like them?
The thing is you can't necessarily fix a bad gui, unless you're working with something where you have access to the source and can replace the code; with cli, you can alway's script your way around a problem. Your programs doesn't validate input? Write an input validater and pipe it through that. Obviously, cli is great for batch operations and automation, as well. Even if it's a black box, proprietary system. Even if you can change the code, which is easier to do? Spend 15 minutes or less working in your favorite scripting language or source the application source, patch it, re-compile if necessary, test, then apply the operation? (Especially if this is a one-off operation).
Development is not happenning in the open, only google partners like motorola and samsung have access to honeycomb source.
According to the article, blaze customers can get "up to 10mbs" of bandwidth, though they don't specifiy if that's up/down or split symmetrically. This probably reflects an improvement in the technology over the past decade. As long as the latency isn't horrible, this sounds quite competitive vs. aDSL, although aDSL is also much, much cheaper (at least in areas with a reasonably dense population). Of course, the whole point is that there's really no other option besides dial-up.
Not to mention that many CS and IT students, who will encounter Unix/Linux for the first time at their university, might be exposed to Solaris and be convinced that it's the best Unix, simply because it's the one that they are most familiar with. (I'll bet this sort-of reasoning plays a bigger role in people's OS preferences than most would care to admit).
I think you underestimate how much that would hurt Google themselves. If Google stops returning IBM-hosted pages how fast do you think they're going to start losing users who care at all about IBM to Bing? "Search neutrality" advocates will, of course, get up in arms over this, if Google was stupid enough to block a major company's sites, but this shouldn't even make it that far, since screwing up it's search results in a way noticeable by an appreciable number of users is bad enough for Google on it's own, even without a public and/or regulatory body outcry.
In your example though, it's proprietary software vs. proprietary software. What your example really seems to suggest is that "fat clients" aren't always better than "thin clients", and that you should've just renewed the license on your original, proprietary software.