"I think, if you reflect, you'll find that you've missed the point. neither I nor the article mentioned having all the distributions use the same packaging system."
Sorry, my mistake.
The "'unified' method" issue is a valid one. Yum (an others like it) have made some progress to this end (yum talks redhat/mandrake rpms as well as debian pkg -- it also goes a long way to resolve dependancies and conflicts automatically). Wrapping yum in a gui would be nice. I would say that the problem is not with "installing programs", but with package management (packages may or may not contain "programs").
I think, however, that many people get the terms "Linux" and "Distribution" confused (as well as "Desktop Environment", I suppose), and when someone says "Linux as a Desktop OS", they are really referring to a "Desktop Linux Distribution". Even if Windows and MacOS used the same kernel, you wouldn't (necessarily) expect the user experience to be the same. I suppose (which is your point) running the GNOME Desktop should have a unified interface to system-level configurations (including package management) across distributions, but that (hopefully) is what GNOME System Tools is all about.
"The answer could be an installation application that can speak to all of the popular distributions. It could be built in such a modular way as to allow new backends and functionality. Alternatively, a standard application installation procedure could be created that is supported by the majority of distributions (perhaps in addition to the native methodology)."
At some point a new user has to be introduced to totally new concepts -- Package management (a la RPM, dpkg, etc.) for instance. Also, the concept of what a distribution really is seems to be new -- The distribution is an attempt to standardize application installation and management (along with *alot* of other things). The reason one chooses one distribution over another is the overall structure and approach of the packagers (thus different distros like Debian, Redhat, and Gentoo). No one knows what works best, and it probably depends on who you are. Trying to "unify" all the different distos so that they all can use each other's packages is missing the point. That is addressed by the GNU build tools (gcc, make, autoconf, automake, etc). In most cases, all the distros rely on the GNU toolset to generate packages.
The same could be said about the Apple Newton Message Pad 2100. Not exactly a market sucess, but try to by one used and you'll still shell out more than $200 ($100 if it is broken)!
The problem with the cube was its position relative to the current line of Macs, and its relatively steep price ($1800 for the 450MHz version, $2300 for the 500MHz one - not including monitor).
That said, my last check on ebay showed these things still going for $500-$600. Not too bad for a silent, small form factor PC. I think the Hoojum Cubit3, packed with a GHz Via C3 (about equivalent to a Celeron 600MHz) would cost you about $1000, without much more performance.
I'd really have to agree with the parent (an all the others saying this). A simple application that does one thing well, makes my life easier, and can (eventually) interface to my other simple applications. Isn't that the Unix Way?
I've been trying to orgainize my personal files at home (it boggles the mind how much paper we tend to collect), and gLabels makes this *very* easy to do.
Because this is supposed to happen in the "near field", a canceler of this type would just have to take into consideration the sound pressure field at the radiator's aperture (for a horn radiator), this is much more difficult if the radiator is omni-directional. That said, it's still not clear to me which paradigm these ANC systems are supposed to operate under.
I recall one theory regarding ANC that looked at the canceling source as a type of acoustic impedance modifier. Pointing the canceling source directly at the sound source would cause a standing wave between the two, but would transform the acoustic impedance into the rest of the room such as to make the combined source inefficient in radiating (preventing the sound pressure wave from propagating past the impedance transition presented by the active source). The "active damper" model.
It's never been clear to me how this is supposed to work from the standpoint of conservation of energy (I've read several dissertations on the subject). Is the canceling source (the anti-source) supposed to dissipate the energy in the traveling sound pressure wave (a-la active damper), thereby stopping the sound from propagating, or does the source provide short-term energy storage to reshape the spacial sound pressure field distribution, or is there some non-linear effect that redistributes the sound spectrally (translating peaked spectra to lower-level flat spectra -- a sound whitener)?
I just wish something just like apt-get existed for the rpm world that made it just as easy to update. However, I've read of projects in the works just for that so I'm sure "rpm hell" will be over a lot sooner than "dll hell" lasted.
I believe the apt system also handles rpms now. Also, checkout YUM (from the ppc distro), which uses apt-get to manage rpm dependencies.
I believe that the OED refers to "irregardless" as the combination of irrespective and regardless, which doesn't mean it really means anything. Strictly speaking, it is either "regardless", or "irrespective", but not both.
The page cannot be found The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
Please try the following:
* If you typed the page address in the Address bar, make sure that it is spelled correctly.
* Open the www.bargainpda.com home page, and then look for links to the information you want.
* Click the Back button to try another link.
HTTP 404 - File not found Internet Information Services
Technical Information (for support personnel)
* More information:
Microsoft Support
Re:Maybe silent isn't the best solution anyway.
on
A Silent PC Solution?
·
· Score: 1
I recall a This Old House project (in Georgia) that had a sort-of coupala structure with a ring of gas burners inside it. The flames heat the air in the coupala, causing it to rise out of the house and drawing cooler air into the house.
You mean that we'll need floppies for old computers. There's absolutely no reason to have a floppy drive in a new computer. If you need to read a floppy from a legacy system, get a USB floppy drive (an only plug it in once every 3 years).
I still can't believe it when I see someone with a new, high end laptop with a built-in floppy drive (not even a removable media bay drive)!
I don't have any problem using yum (or see this for some helpful info) these days. It uses apt-get to resolve rpm dependencies fine on both my YellowDogLinux machine as well as my Redhat9 machine. The trick is having the right repository (freshrpms works great for me).
I imagine the problem is upgrading all those servers, or coming up with a transitionary system that allows both to exist (via trusted gateways?).
Ultimately the real solution as suggested here is on the server/protocol side (not anything on the email client side, as the author of the article suggests). I'd have to agree that the biggest problem about SPAM is (un)traceability and spoofed addresses. If my mail server would reject anything with a spoofed address, I'm sure most of my SPAM problem would go away.
Sort-of. You may be thinking of the Nyquist criterion, but this is related in a way. Shannon was the first to quantify the concept of information via "entropy", which leads to the concept of "mutual" or shared information (i.e. between inputs and outputs of a channel). Distortion (additive noise or some other form) limits the amount of mutual information shared between the input an output of a channel, and is independent of the nature of the data source. Thus, he proved that communication channels have a theoretical limit to the amount of data that can be reliably (error free) transmitted through them. He also suggested coding as a method to achieve this theoretical limit, which turbo codes approach for certain classes of channels (additive gaussian noise channel, for instance).
The term "turbo" is applied here in analogy because of the "turbo principle" in the decoder. The outputs of two decoders are compared and then fed back to improve the original estimate (almost like feeding the exhaust energy back into the input stream to improve output).
If he's got a plasma screen, he's not going to want to give up any video quality, so recompression really isn't an option.
From my experience, MPEG4 (ffmpeg 2-pass encoder + AAC audio) has comparable quality at almost 1/2 the original file size (YMMV). Plus, my aging 400MHz G3 is able to play these back in real time (can't quite make it with MPEG2). $0.02.
This article seems to be about commercial tools for embedded linux, and how the market is soft for such software products. A few of the posters here seem to think he is putting down Linux, but rather states that, in order to make money in software tools, developers need to go somewhere else. From the article:
Because most embedded Linux users roll-their-own, that leaves less than half of the market to the six-or-so major commercial distributions. Since none of them is dominant, no specific integration is able to address more than 10 percent of the market.
The author's concern is exactly what kind of market exists for commercial sofware development tools for embedded Linux, not whether Linux is a good OS for embedded applications. He does take a few swipes at Linux, but they are in support of his thesis that, while embedded Linux-based system developers will need support (for a host of reasons the author presents, be them good or bad), but will not want to pay for them:
The obvious refuge for embedded Linux users is to seek support from a commercial supplier. Unfortunately, most embedded Linux users are not willing to consider commercial vendors.
The author concludes that, because there will not be a strong market for Linux-embedded support, there will be few vendors able to support Linux-embedded (and still make money) applications/development, and therefore the will be no market for anyone selling Linux-embedded development tools (emphasis mine):
As manufacturers recognize the real impact of embedded Linux, the tools market will dissipate. Those inclined to buy tools will abandon Linux. Those who stick with embedded Linux will have no interest in tools.
The author does not, however mention what percentage of developers are those that are "inclined to buy tools".
... with a clear conflict of interest, as well as a biased point of view. Even if what he says makes sense, selective presentation of facts can be used to support any conclusion.
I guess it's not clear to me exactly how a calculator is supposed to help me do/learn calculus at all(?). Unless the calculator is running something like Maple, how is it going to help me calculate limits, indefinite integrals, partial derivatives, and infinite sums? The only thing we need to do numerically in calculus is approximate, which is also better taught without computers.
Even in engineering, learning rarely requires a computer. Doing (that is, designing and testing), on the other hand is made much simpler with computers.
Slashdot Mirror
"I think, if you reflect, you'll find that you've missed the point. neither I nor the article mentioned having all the distributions use the same packaging system."
Sorry, my mistake.
The "'unified' method" issue is a valid one. Yum (an others like it) have made some progress to this end (yum talks redhat/mandrake rpms as well as debian pkg -- it also goes a long way to resolve dependancies and conflicts automatically). Wrapping yum in a gui would be nice. I would say that the problem is not with "installing programs", but with package management (packages may or may not contain "programs").
I think, however, that many people get the terms "Linux" and "Distribution" confused (as well as "Desktop Environment", I suppose), and when someone says "Linux as a Desktop OS", they are really referring to a "Desktop Linux Distribution". Even if Windows and MacOS used the same kernel, you wouldn't (necessarily) expect the user experience to be the same. I suppose (which is your point) running the GNOME Desktop should have a unified interface to system-level configurations (including package management) across distributions, but that (hopefully) is what GNOME System Tools is all about.
"The answer could be an installation application that can speak to all of the popular distributions. It could be built in such a modular way as to allow new backends and functionality. Alternatively, a standard application installation procedure could be created that is supported by the majority of distributions (perhaps in addition to the native methodology)."
At some point a new user has to be introduced to totally new concepts -- Package management (a la RPM, dpkg, etc.) for instance. Also, the concept of what a distribution really is seems to be new -- The distribution is an attempt to standardize application installation and management (along with *alot* of other things). The reason one chooses one distribution over another is the overall structure and approach of the packagers (thus different distros like Debian, Redhat, and Gentoo). No one knows what works best, and it probably depends on who you are. Trying to "unify" all the different distos so that they all can use each other's packages is missing the point. That is addressed by the GNU build tools (gcc, make, autoconf, automake, etc). In most cases, all the distros rely on the GNU toolset to generate packages.
The same could be said about the Apple Newton Message Pad 2100. Not exactly a market sucess, but try to by one used and you'll still shell out more than $200 ($100 if it is broken)!
The problem with the cube was its position relative to the current line of Macs, and its relatively steep price ($1800 for the 450MHz version, $2300 for the 500MHz one - not including monitor).
That said, my last check on ebay showed these things still going for $500-$600. Not too bad for a silent, small form factor PC. I think the Hoojum Cubit3, packed with a GHz Via C3 (about equivalent to a Celeron 600MHz) would cost you about $1000, without much more performance.
I'd really have to agree with the parent (an all the others saying this). A simple application that does one thing well, makes my life easier, and can (eventually) interface to my other simple applications. Isn't that the Unix Way?
I've been trying to orgainize my personal files at home (it boggles the mind how much paper we tend to collect), and gLabels makes this *very* easy to do.
$0.02
Because this is supposed to happen in the "near field", a canceler of this type would just have to take into consideration the sound pressure field at the radiator's aperture (for a horn radiator), this is much more difficult if the radiator is omni-directional. That said, it's still not clear to me which paradigm these ANC systems are supposed to operate under.
I recall one theory regarding ANC that looked at the canceling source as a type of acoustic impedance modifier. Pointing the canceling source directly at the sound source would cause a standing wave between the two, but would transform the acoustic impedance into the rest of the room such as to make the combined source inefficient in radiating (preventing the sound pressure wave from propagating past the impedance transition presented by the active source). The "active damper" model.
It's never been clear to me how this is supposed to work from the standpoint of conservation of energy (I've read several dissertations on the subject). Is the canceling source (the anti-source) supposed to dissipate the energy in the traveling sound pressure wave (a-la active damper), thereby stopping the sound from propagating, or does the source provide short-term energy storage to reshape the spacial sound pressure field distribution, or is there some non-linear effect that redistributes the sound spectrally (translating peaked spectra to lower-level flat spectra -- a sound whitener)?
Nibbler
Does this mean that there's a little creature with a voracious appetite pooping in space?
I just wish something just like apt-get existed for the rpm world that made it just as easy to update. However, I've read of projects in the works just for that so I'm sure "rpm hell" will be over a lot sooner than "dll hell" lasted.
I believe the apt system also handles rpms now. Also, checkout YUM (from the ppc distro), which uses apt-get to manage rpm dependencies.
Fedora uses yum as well
I believe that the OED refers to "irregardless" as the combination of irrespective and regardless, which doesn't mean it really means anything. Strictly speaking, it is either "regardless", or "irrespective", but not both.
$0.02 (offtopic...)
Funny, my page loaded quite quickly:
The page cannot be found
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
Please try the following:
* If you typed the page address in the Address bar, make sure that it is spelled correctly.
* Open the www.bargainpda.com home page, and then look for links to the information you want.
* Click the Back button to try another link.
HTTP 404 - File not found
Internet Information Services
Technical Information (for support personnel)
* More information:
Microsoft Support
I recall a This Old House project (in Georgia) that had a sort-of coupala structure with a ring of gas burners inside it. The flames heat the air in the coupala, causing it to rise out of the house and drawing cooler air into the house.
You mean that we'll need floppies for old computers. There's absolutely no reason to have a floppy drive in a new computer. If you need to read a floppy from a legacy system, get a USB floppy drive (an only plug it in once every 3 years).
I still can't believe it when I see someone with a new, high end laptop with a built-in floppy drive (not even a removable media bay drive)!
I don't have any problem using yum (or see this for some helpful info) these days. It uses apt-get to resolve rpm dependencies fine on both my YellowDogLinux machine as well as my Redhat9 machine. The trick is having the right repository (freshrpms works great for me).
I imagine the problem is upgrading all those servers, or coming up with a transitionary system that allows both to exist (via trusted gateways?).
Ultimately the real solution as suggested here is on the server/protocol side (not anything on the email client side, as the author of the article suggests). I'd have to agree that the biggest problem about SPAM is (un)traceability and spoofed addresses. If my mail server would reject anything with a spoofed address, I'm sure most of my SPAM problem would go away.
or even yum, which uses apt-get for updating .rpms (for those RedHat derivative distros)
Sort-of. You may be thinking of the Nyquist criterion, but this is related in a way. Shannon was the first to quantify the concept of information via "entropy", which leads to the concept of "mutual" or shared information (i.e. between inputs and outputs of a channel). Distortion (additive noise or some other form) limits the amount of mutual information shared between the input an output of a channel, and is independent of the nature of the data source. Thus, he proved that communication channels have a theoretical limit to the amount of data that can be reliably (error free) transmitted through them. He also suggested coding as a method to achieve this theoretical limit, which turbo codes approach for certain classes of channels (additive gaussian noise channel, for instance).
The term "turbo" is applied here in analogy because of the "turbo principle" in the decoder. The outputs of two decoders are compared and then fed back to improve the original estimate (almost like feeding the exhaust energy back into the input stream to improve output).
From the Gimp-Print Project page forums, the following question was (as of 2/4/04) asked:which had the reply:Can you actually print from GIMP 2.0?
Will this release have a compatible gimp-print plugin?
$0.02.
From the article: The author's concern is exactly what kind of market exists for commercial sofware development tools for embedded Linux, not whether Linux is a good OS for embedded applications. He does take a few swipes at Linux, but they are in support of his thesis that, while embedded Linux-based system developers will need support (for a host of reasons the author presents, be them good or bad), but will not want to pay for them: The author concludes that, because there will not be a strong market for Linux-embedded support, there will be few vendors able to support Linux-embedded (and still make money) applications/development, and therefore the will be no market for anyone selling Linux-embedded development tools (emphasis mine): The author does not, however mention what percentage of developers are those that are "inclined to buy tools".
... with a clear conflict of interest, as well as a biased point of view. Even if what he says makes sense, selective presentation of facts can be used to support any conclusion.
I guess it's not clear to me exactly how a calculator is supposed to help me do/learn calculus at all(?). Unless the calculator is running something like Maple, how is it going to help me calculate limits, indefinite integrals, partial derivatives, and infinite sums? The only thing we need to do numerically in calculus is approximate, which is also better taught without computers.
Even in engineering, learning rarely requires a computer. Doing (that is, designing and testing), on the other hand is made much simpler with computers.