Fedora Core comes without the African Philosophy software layer, which not to offend our African Philosophy lovers out there, probably makes the software more stable.:)
But seriously, Fedora is heavily tested, backed by large corporations, retains independence from total corporate control, and the distro to watch if you're interested in what might be in the next RedHat release.
If this is really how you feel. I can't think of any major Linux distrobution that doesn't ship will Mozilla. Mabye when Firefox reaches 1.0, then distros will consider including it in their offerings, but right now you're asking for pre-release software in a stable distribution offering.
It's like you're complaining about car models. You tell me that you always drive in the latest make / model, but it's such a pain that they keep coming out with a new car every year.
Really, there's nothing wrong with using the older software. Just keep your patches up to date, and enjoy. Or, upgrade to the newest release, and enjoy the new features. But why complain that you want the latest features, but don't want to change features you just got used to?
Mine isn't reliable enough, and it's not like I'm in a 3rd world country (whatever that means today). I'm in Houston, TX, a not-so-small city that has had no appreciable water shortages in the last 10 years. For example, I've lost water pressure twice this year.
Security by obscurity is flawed, so why assume that obscuring the technical details of water delivery will secure your water cooling system?
"isComputerOn" and "isComputerOnFire" should both return 1 when the event is occuring. If you want the temp, they should have made a "getMotherboardTemp" but they probably ran out of R&D funds.
Funny, they used to say the same thing about computation.
Sure there's zillions of examples of computation being done less efficently in the real world than they're contemplating over at the university, but even the most backward way of doing it still has it's roots in math and academic papers.
Economics is a mix of philosophy and math. Good economists know where those dividing lines exist within each of the respective economic theories, and know how not to mix incompatible philosophies or select inappropriate models. Bad economists pick up on a few key ideas from these models, but expect them to work like physical laws disregarding the motivations behind the statements.
Just look at the supposed "law" of supply and demand. The ideas behind such a model is valid, but the model is inappropriately applied to most real world examples because real world examples have interfering factors like jurisdiction, proximity, controlled markets, etc.
Yes, you are correct in stating that the neurons themselves don't reproduce, but neurogenesis (and it's association with the growth of neurons) leads to the existence and generation of more neurons.
When I used the words "growth" and "death" I was referring to the number of neurons in the tissue, not the division of pre-existing neurons, but rather the creation of new neurons from stem cells. Death however, does relate to the death of both the neuron and the decrease of the number of neurons in the neural tissue.
Re:neurogenesis
on
Flying By Brain
·
· Score: 3, Informative
Well, you need to do a little more research.
Neurons grow and die all the time, and are not as "terminally differentiated" as you think. There's been a number of cases (even in humans) that provide evidence of these occurances, although not every portion of the brain supports neurogenesis.
This behavior has been observed for years. See http://www.smithsonianmag.si.edu/smithsonian/issue s02/jun02/phenomena.html for a popularized article that's over two years old on this matter. Older articles exist referring to the phenomenon, especially in relationship to certain species of birds where a portion of the brain grows and shrinks in relation to the learning / forgetting of that season's birdsong.
Well, then it might be a troll, or it might be a rational statement. The best trolls are, of course, both.
But flamebait would be something more along the lines of TCP/IP only being the choice of backward retards who can't figure out that there's been better solutions around since the mid 90's, and if they'd only get off their fat asses and RTFM, then they'd get a clue and be able to download streaming video of hot one-on-one grit action starring Natalie Portman.
No, an operting system is not needed to control all of these units through a single multifunction input/display unit.
Each of these systems pre-existed without a traditional operating system, whether those systems were mechanical, simple electrical circuits, PLCs or whatever. Why they would do this is the combination of two reasons.
Price drops in hardware that can support an OS significant enough to compete with the cost of the alternative mechanical / electrical solution, and the ability to produce intermeidate versions and upgradable versions of the product which removes costs associated with pre-production glitches in the design.
Needless to say, since the issues won't be heavily scrutinized before the item is produced, there's going to be a much greater chance that the design of these systems will become much more like programming projects instead of traditional manufacturing. With all of the known pressures on programming projects, I'd imagine that the good things in UI design that comes from the manufacturing field will be lost in a maze of widgets, and that project deadline pressures will result in rationalizing the release of less than perfect code, with maybe a "new downloadable" update planned for "when we can get to it in the future"
There's a lot more pressure to get it right when you're mistake is going to be hardcoded into a manufacturing run of a hundred thousand items or so.
They are confused
on
Replacing TCP?
·
· Score: 3, Interesting
They tell you how they solved the solution, but fail to tell you how much impact this solution has overall.
They're basically stating that now they can flood the connection with packets.
But they've also told you that the packets contain your data in an error correcting encoding. What they don't mention is this:
How much overhead is required by the error correcting encoding?
How many errors can the error correcting encoding handle? (drops 1 packet = ok, drops 400 packets = bad)
How much cpu computation is required to encode and decode the payload?
How is the cpu overhead managed? (how much performance will be lost by context switching, etc.)
So they're just playing the game of distracting people with the best part of thier performance measurement without bothering to mention the performance impact of all of the other trade-offs they admitted to making.
The problem that TCP addresses hasn't changed, so the protocol hasn't been replaced.
The problem of what to do when you lose data during a transmission only has a limited number of solutions, and TCP's simplicity (ask again) is it's greatest strength.
Mabye future replacements will reorder the header in such a way that it simplifies the hardware processing required by the routers, but the core solution will last a lifetime because if you are missing a piece of the data (and you need all of it) you'll eventually ask for that piece again.
It's the equivalent to asking someone to repeat that last sentence because you dropped the phone.
Most modern TCP/IP implementations use a sliding window algorithim internally, which caches the out of order packets while it's trying to re-get the missing packet.
So you're really only concerining yourself with ordered delivery when the delay in the natural order is greater than that of the sliding window (the cache of received packets that you're not going to tell the software about just yet)
This takes care of trivial things where packets arrive "just barely" out of order, but in a true packet loss situation, can block the channel for quite some time.
So the strict sequence you refer to is the sequence the packets are presented to the next layer (usually the application in Ethernet), not the sequence the packets are received by the machine.
Who flamebaited this? It's not derogatory, and it's a valid opinion. TCP's shortcomings are going to constantly be mitigated by better router and switch hardware.
The article is little more than an advertisment for their socket management software, so it's no more news than what SCO produces, but from what I can gather...
There's no way to obtain data that was truly lost, so they are using an error correcting encoding of the data (and wasting some of the bandwith in the process) They're not really doing something radical, it's just UDP/IP. They just have some software that silently handles the data loss and unpacking which sits on top of a UDP/IP socket. So they've moved the problem from layer 3 into the application layer (layer 7).
Their entire product places emphasis the amount of network utilization, but little else. I imagine that they're wasting a portion (but who knows how much) of their "utilized" bandwith, and they're certainly wasting a lot of CPU time encoding and decoding the packet payload. Thier sales pitch is basically "TCP/IP bad, UDP/IP better" but they never clearly address how much CPU time this solution requires or how much of the "utillized" bandwith is wasted.
Using UDP/IP with retransmission in software has been done many times. Look at FTP.
And that's the reason he's an Astrophysics professor.
Professors eventually make silly comments about other fields becuase they sometimes forget that they are master of their domain but not always even competent in another's.
A business professor would give you an entirely different reason, probably one having to do with distribution chains, monetary options, supply of raw materials, government support, cheap labor supply, etc.
My favorite "professor" quote came from a history professor who (as an aside) was telling us that there were all kinds of corporations: partnerships, limited-liability practices, and sole-propriatorships. I nearly fell on the floor, as not one of his expamles was a corporation.
Or if your professor was a sly one, mabye he was just trying to get your attention with a subtle joke.
IR is so totally hackable. You'd just make the "Universal Remote" record the IR strobe sequences for each button and then play them back. And that technique works even if they make a different remote for each individual television.
Most people (submitter perhaps withstanding) really wouldn't use this outside of perhaps their home.
This smacks of a novelty item / gag gift, I mean you won't take it to your bar, because if you really wanted that TV off, you'd ask the manager or leave. Only the most die hard axxholes would consider acting out the scenario presented, and few of those would have the stomach to do it twice, or make a regular occurance out of it.
Let's face it, we already know who would abuse this device, they're the same ones that are yelling at the manager / barkeep all the time, but don't have the common sense to stop coming to their "favorite resturant / bar".
A piece of tape will solve the TV problems, and then they'll be back to ridiculous statements of infringement of their personal space / hearing when visiting a public place.
Instead of imposing your ideals on others without their permission / acceptance, why not try patronizing places that don't have annoying TVs blaring all over the place.
It's not like TV free places are hard to find, but if you disagree with the environment, vote with you wallet instead of trying to run someone else's business.
It won't solve all the airport problems, but I can usually find a place out of Tube range.
Also, I can image a number of "circumvention" devices that would render this device pratically useless in a location that has frequent problems with the TV suddenly turning off. Like masking tape.
Slashdot Mirror
Fedora Core comes without the African Philosophy software layer, which not to offend our African Philosophy lovers out there, probably makes the software more stable. :)
But seriously, Fedora is heavily tested, backed by large corporations, retains independence from total corporate control, and the distro to watch if you're interested in what might be in the next RedHat release.
Ubuntu is well... lacking in many of these areas.
Not that it's guranteed to fix all the CD downloading problems you have, but if you're not using wget, you may want to look into it.
If this is really how you feel. I can't think of any major Linux distrobution that doesn't ship will Mozilla. Mabye when Firefox reaches 1.0, then distros will consider including it in their offerings, but right now you're asking for pre-release software in a stable distribution offering.
Uh...
Then don't upgrade.
It's like you're complaining about car models. You tell me that you always drive in the latest make / model, but it's such a pain that they keep coming out with a new car every year.
Really, there's nothing wrong with using the older software. Just keep your patches up to date, and enjoy. Or, upgrade to the newest release, and enjoy the new features. But why complain that you want the latest features, but don't want to change features you just got used to?
Confusing...
You assume that your water system is reliable.
Mine isn't reliable enough, and it's not like I'm in a 3rd world country (whatever that means today). I'm in Houston, TX, a not-so-small city that has had no appreciable water shortages in the last 10 years. For example, I've lost water pressure twice this year.
Security by obscurity is flawed, so why assume that obscuring the technical details of water delivery will secure your water cooling system?
I hate those inconsistent BeOS system libraries.
"isComputerOn" and "isComputerOnFire" should both return 1 when the event is occuring. If you want the temp, they should have made a "getMotherboardTemp" but they probably ran out of R&D funds.
Funny, they used to say the same thing about computation.
Sure there's zillions of examples of computation being done less efficently in the real world than they're contemplating over at the university, but even the most backward way of doing it still has it's roots in math and academic papers.
Economics is a mix of philosophy and math. Good economists know where those dividing lines exist within each of the respective economic theories, and know how not to mix incompatible philosophies or select inappropriate models. Bad economists pick up on a few key ideas from these models, but expect them to work like physical laws disregarding the motivations behind the statements.
Just look at the supposed "law" of supply and demand. The ideas behind such a model is valid, but the model is inappropriately applied to most real world examples because real world examples have interfering factors like jurisdiction, proximity, controlled markets, etc.
Yes, you are correct in stating that the neurons themselves don't reproduce, but neurogenesis (and it's association with the growth of neurons) leads to the existence and generation of more neurons.
When I used the words "growth" and "death" I was referring to the number of neurons in the tissue, not the division of pre-existing neurons, but rather the creation of new neurons from stem cells. Death however, does relate to the death of both the neuron and the decrease of the number of neurons in the neural tissue.
Well, you need to do a little more research.
e s02/jun02/phenomena.html for a popularized article that's over two years old on this matter. Older articles exist referring to the phenomenon, especially in relationship to certain species of birds where a portion of the brain grows and shrinks in relation to the learning / forgetting of that season's birdsong.
Neurons grow and die all the time, and are not as "terminally differentiated" as you think. There's been a number of cases (even in humans) that provide evidence of these occurances, although not every portion of the brain supports neurogenesis.
This behavior has been observed for years. See http://www.smithsonianmag.si.edu/smithsonian/issu
Actually, the car and the computer could arrive at deadlock during a crash scenario, leaving you in limbo, but permanetly buckled in.
It might, but the parental controls are set such that nobody will know till they reach age 150.
Well, then it might be a troll, or it might be a rational statement. The best trolls are, of course, both.
But flamebait would be something more along the lines of TCP/IP only being the choice of backward retards who can't figure out that there's been better solutions around since the mid 90's, and if they'd only get off their fat asses and RTFM, then they'd get a clue and be able to download streaming video of hot one-on-one grit action starring Natalie Portman.
Gosh, that was easier than I thought...
Adds a whole new dimension the the "death" part.
No, an operting system is not needed to control all of these units through a single multifunction input/display unit.
Each of these systems pre-existed without a traditional operating system, whether those systems were mechanical, simple electrical circuits, PLCs or whatever. Why they would do this is the combination of two reasons.
Price drops in hardware that can support an OS significant enough to compete with the cost of the alternative mechanical / electrical solution, and the ability to produce intermeidate versions and upgradable versions of the product which removes costs associated with pre-production glitches in the design.
Needless to say, since the issues won't be heavily scrutinized before the item is produced, there's going to be a much greater chance that the design of these systems will become much more like programming projects instead of traditional manufacturing. With all of the known pressures on programming projects, I'd imagine that the good things in UI design that comes from the manufacturing field will be lost in a maze of widgets, and that project deadline pressures will result in rationalizing the release of less than perfect code, with maybe a "new downloadable" update planned for "when we can get to it in the future"
There's a lot more pressure to get it right when you're mistake is going to be hardcoded into a manufacturing run of a hundred thousand items or so.
They tell you how they solved the solution, but fail to tell you how much impact this solution has overall.
They're basically stating that now they can flood the connection with packets.
But they've also told you that the packets contain your data in an error correcting encoding. What they don't mention is this:
How much overhead is required by the error correcting encoding?
How many errors can the error correcting encoding handle? (drops 1 packet = ok, drops 400 packets = bad)
How much cpu computation is required to encode and decode the payload?
How is the cpu overhead managed? (how much performance will be lost by context switching, etc.)
So they're just playing the game of distracting people with the best part of thier performance measurement without bothering to mention the performance impact of all of the other trade-offs they admitted to making.
The problem that TCP addresses hasn't changed, so the protocol hasn't been replaced.
The problem of what to do when you lose data during a transmission only has a limited number of solutions, and TCP's simplicity (ask again) is it's greatest strength.
Mabye future replacements will reorder the header in such a way that it simplifies the hardware processing required by the routers, but the core solution will last a lifetime because if you are missing a piece of the data (and you need all of it) you'll eventually ask for that piece again.
It's the equivalent to asking someone to repeat that last sentence because you dropped the phone.
I was more thinking along the line of, "Yeah, Really great. Kudos for posting a company's product advertisement as if it were news."
Most modern TCP/IP implementations use a sliding window algorithim internally, which caches the out of order packets while it's trying to re-get the missing packet.
So you're really only concerining yourself with ordered delivery when the delay in the natural order is greater than that of the sliding window (the cache of received packets that you're not going to tell the software about just yet)
This takes care of trivial things where packets arrive "just barely" out of order, but in a true packet loss situation, can block the channel for quite some time.
So the strict sequence you refer to is the sequence the packets are presented to the next layer (usually the application in Ethernet), not the sequence the packets are received by the machine.
Who flamebaited this? It's not derogatory, and it's a valid opinion. TCP's shortcomings are going to constantly be mitigated by better router and switch hardware.
The article is little more than an advertisment for their socket management software, so it's no more news than what SCO produces, but from what I can gather...
There's no way to obtain data that was truly lost, so they are using an error correcting encoding of the data (and wasting some of the bandwith in the process) They're not really doing something radical, it's just UDP/IP. They just have some software that silently handles the data loss and unpacking which sits on top of a UDP/IP socket. So they've moved the problem from layer 3 into the application layer (layer 7).
Their entire product places emphasis the amount of network utilization, but little else. I imagine that they're wasting a portion (but who knows how much) of their "utilized" bandwith, and they're certainly wasting a lot of CPU time encoding and decoding the packet payload. Thier sales pitch is basically "TCP/IP bad, UDP/IP better" but they never clearly address how much CPU time this solution requires or how much of the "utillized" bandwith is wasted.
Using UDP/IP with retransmission in software has been done many times. Look at FTP.
And that's the reason he's an Astrophysics professor.
Professors eventually make silly comments about other fields becuase they sometimes forget that they are master of their domain but not always even competent in another's.
A business professor would give you an entirely different reason, probably one having to do with distribution chains, monetary options, supply of raw materials, government support, cheap labor supply, etc.
My favorite "professor" quote came from a history professor who (as an aside) was telling us that there were all kinds of corporations: partnerships, limited-liability practices, and sole-propriatorships. I nearly fell on the floor, as not one of his expamles was a corporation.
Or if your professor was a sly one, mabye he was just trying to get your attention with a subtle joke.
Well, you can... But then you'd need to be in a different industry!
Not to rain on your DMCA rant but...
IR is so totally hackable. You'd just make the "Universal Remote" record the IR strobe sequences for each button and then play them back. And that technique works even if they make a different remote for each individual television.
Most people (submitter perhaps withstanding) really wouldn't use this outside of perhaps their home.
This smacks of a novelty item / gag gift, I mean you won't take it to your bar, because if you really wanted that TV off, you'd ask the manager or leave. Only the most die hard axxholes would consider acting out the scenario presented, and few of those would have the stomach to do it twice, or make a regular occurance out of it.
Let's face it, we already know who would abuse this device, they're the same ones that are yelling at the manager / barkeep all the time, but don't have the common sense to stop coming to their "favorite resturant / bar".
A piece of tape will solve the TV problems, and then they'll be back to ridiculous statements of infringement of their personal space / hearing when visiting a public place.
I know that the programming on most channels is very bad these days, but come on...
Do you really expect to die from it?
Instead of imposing your ideals on others without their permission / acceptance, why not try patronizing places that don't have annoying TVs blaring all over the place.
It's not like TV free places are hard to find, but if you disagree with the environment, vote with you wallet instead of trying to run someone else's business.
It won't solve all the airport problems, but I can usually find a place out of Tube range.
Also, I can image a number of "circumvention" devices that would render this device pratically useless in a location that has frequent problems with the TV suddenly turning off. Like masking tape.