I'm sorry, but if you do a blind emerge world on a prodcution server, you're fired. Just drop your stuff and go. A home box is one thing, a mission critical server is quite another.
I don't disagree with your comments. I just personally felt that he was using the term "opensource" liberally, and to mean all software which may be considered opensource. He may think he is in a position to speak for opensource, and that's fine. The author though sppears to attempt to speak for free software as well, all though he fails to mention it specifically.
Some in the free software camp will take offense to the fact that this author attempts to speak for all, when he is in no position to do so. I don;t mean to nitpick, but the title of the article is in reference to OSS specifically, but the commentary includes things which are specifically free software. He has overstepped his bounds.
I think many people (including me) would take offense to this guy packaging Opensource in with Free Software. He also takes the libery to call witness to the greatness of the opensouce development model.
I realize that to many people, OSS and Free Software are synonymous. To those who fall squarely within either camp, the differences are meaningful enough to warrant the existence of two separate groups. This guy seems to fall into the OSS camp, which is fine and well, but one can't have their cake and eat someone else's.
While the judge can show disdain towards the FCC's approach, what struck me was this:
If the appeals panel decides that the consumers groups can't contest the FCC requirements, it would dismiss the case regardless of any concerns about the anti-piracy technology. A decision by the court could happen within months.
What this means to me if I interpret correctly is:
Although the judge knows well what the FCC is trying to accomplish, and doesn't like it, that does not mean that this will not pass. There are recognized examples of where this regulation would hamper currently legal uses, however, the regulation by nature is not a block to those groups only, but to the broader public. I get the sense that it may be passed, on the stipulation that the FCC have contingengies to address known exceptions to the rules, such as libraries and such.
More disturning is the possibility of it getting passed, while the judges are aware that challenges from groups recognized to be exempt may be deemed moot. This would mean that if it passes, it would be with the understanding that libraries and schools (not to mention everyday joes through fair use) would have existing rights stripped.
I don't live in the US, but I really hope that my American friends don't have to swalow this garbage. I can picture the judge's grim face when he made those statements. Hopefuly is fails.
If this passes, I seriously believe that America (as I believe American's view America) is lost.
You could try to stop time, progress and technical evolution. That way, your shiny new equipment will never become obsolete.
Sorry, that's a small jab. We can't predict what the future will bring. I can tell you this though...
If you want to be able to do things with bits that the powers that be try to stop you from doing, your best bet will always be had in the hobyist (read free software / oss) areas. This is because companies who want to compete and cooperate to get your money will b forced to play by the rules imposed by those would deny digital rights. Individuals will not bend to this, so the free stuff, while admitedly slower on the curve, will be your best bet, if freedom is your motivation. This means invest in your PC.
If you want digital input to your TV, go over DVI, but be sure that any set you look at will play non DRM encoded stuff. I believe the MPAA is attempting to mandate the broadcast of digital signals in a format which will limit rights. There are two types of digital interface on a television. My memory is sketchy here, I bought my set over 18 moonths ago. I do know though that there are a couple of different interface/protocol types, some of which use only the protocol which the MPAA is trying to define (in their favour). Be careful of that.
I have news for you. After 15 years in IT, I have only ever met 1 (count, one) developer who knew what the hell they were doing, and that I would trust to touch production services.
I have implemented and managed Linux and UNIX development environments, build processes etc. for 8 years, and believe me, allowing developers free reign is a recipe for disaster.
Some unfortunately develop prima-dona-itis, as the parent seems to have. I know sysadmins who also develop prima-donna-itis. No matter the job you perform, if you develop this wicked sickness, you are a cancer on your work environment, and should be the first to go. In fact, most people other than the prima-donna know who the prima-donnas are, and cost cutting time is a great time to get rid of the cancer.
One GUI email reader is XFMail and derivatives. I happend to need to sort, filter and process thousands of emails a week, so for me, speed and efficiency is everything. It's not pretty, although I believe one of the derivitives uses GTK, and another emulates the Next mailapp. I haven't tried these derivatives. XFMail can run a dozen filters against 5000 messages in about 5 seconds, and that's over NFS!
I'm sorry for your mistake. The Mitsubishi line of SUVs are the most decrepit, unsafe vehicles on the road.
In a Consumer Reports frontal impact aversion test, the Montero repeatedly tried to flip over at very low speeds, well under the lowest flip level of any other SUV EVER tested. They put training wheels on it. It was so bad in fact, that they refused to give the vehicle a safety score at all, and instead listed the Montero as an unsafe vehicle in a special warning report.
I also hve a personal friend who has had no end of trouble getting warranty work done on this Rodeo. The Mitsubishi SUVs are so ill reputed in fact, that several dealers refused to accept it as a trade in once he finally broke down and decided to replace it.
You misunderstand the parent's point. You cannot compare a userland tool to a package format. Repeat that to yourself. If it is still unclear, or you don't understand, then continue your cluless zealotry. Poeple who know, will know that you're talking out of your ass, just like the patent does.
I wrote a post some time ago about how I thought VoIP was not ready for primetime. I was subequently trashed by a self-affirming moron and rated down. Whatever.
Voice communication relies on time sensitive delivery of very small bits of information.
IP networks are designed to deliver large gulps of information in a non so timely fashion. Wht I mean by this is that in an IP network, equipment will deliver information as quickly as it can, but there's nothing the 802.x quite of protocols which inherantly facilitates predictably timely delivery of data. Timely delivery is governed by network and infrasturcture "health". Sure, there's QoS, but that ultimately gives very little benefit unless the network is under heavy load anyways, in which case, VoIP is a bust regardless.
Conversations can seem decoupled. Calling someone 1/2 mile away can introduce the latency that can be expected when calling overseas. It doesn't feel "like a phone" to many end users.
Jitter, latency (huge), and the general difficulty of "simulating a telephone" over IP services is what will prevent VoIP for taking hold until several generations of technology and a generation or two of home connectivity methods is introduced.
Contrast ATM networks, which are designed specifically to deliver small bits of information very quickly. These networks are ideal of VoIP.
Poeple don't have ATM to their houses, they have DSL or cable services which offer NOWHERE near the reliability of a typical voice network.
Someone can fairly realistically expect 1/2 of a building to be blown to pieces, while a phone in the other half will work. This is how reliable voice networks have been.
Within a company on a controlled LAN, VoIP can work because you have some control over the quality of the service. To the home, we are not close to being ready.
I've implemented VoIP switches since their initial introduction, I have spoken at international conferences on the merits and pitfalls of VoIP. I'm not trying to toot my own horn, I'm just saying.... I've used and abused these switches, phones and protocols, and I find them lacking outside tightly controlled environments. Across a vendor's backbone? Sure, no problem. Will I use it exclusively in my home? No freaking way.
IPv6 makes for nice project work, but I don't believe that it will ever be implemented in any meaningful way, at least for a good long while.
Eggheads play with it, manufacturers move to support it, but nobody uses it. When I say this, I mean, nobody is forced to use it, so nobody will make the change.
The LSB Package file format specification describes how a package file is formatted.
File header, payload section alignment, header section alignment and how the header is defined, metadata. How to navigate, read, extract and create package files according to set specifications.
The standard defines convention for a package "file format", it does not dictate which tools must be used to interact with them.
Adding the bells and whistles is up to the distributor. If someone's reasoning for Apt being better is simply that "It can recursively update packages which are required by the one I am requesting", then that is fine, but don't confuse your opinion of a better userland tool for a better package file format. The tool may suit your fancy better, this does not reflect on the package file format specification.
Automatic fetches, catalog indexing, dependancies etc can be handled outside of the package file itself. I would say that this functionality is best left outside of the package file format specification.
Ironic that George Lucas would make a movie where consumerism is a sickness in society. This coming from the guy who is an uber IP controls advocate, and an uber market-the-garbage-to-death-and-they-will-buy guy.
Although what you say is technically correct, I don't trust RMON. Different equipment vendors have different implementations and levels of conformance. Beyond this, there are also limiting factos which fall outside of RMON itself.
Process priorities for example. If a switch is under load, will the switch begin dropping packets to the agent process in order to better service the network? How much overhead does the agent create if actively monitoring? Will it effect switch engine perfomance?
There are other reasons, like horrible conformance to spec of equipment manufacturers. You'll get as many quirky implementations as there are manufacturers, and in some cases models and revisions of a different switch.
Not to discredit your points, they are valid, so long as you know that it is in fact functioning as you believe it is...
Wow, I think this thread, and more specifically the parent post, illustrates beautifully why in nearly twelve years of Linux use, I have never found Debian palatable.
Elitism unleashed. Everything but everything boils down to philosophical self affirming debate.
The ball is blue.
T'isn't.
Yes, it is. I'm looking right at it.
That, of course, would depend on your ability to perceive reality in your current state. It appears as though, perhaps, because of your lack of understanding of my point of view (which is correct), that you are not capable of perceiving the colour of the ball, because your beliefs regarding "colour" are incorrect. You believe that the ball is blue, but it is green. You cannot identify the colour correctly because you have never learned green from blue. This axiom has limited your ability to perceive colour as it should be perceived, according to the Debian philosophy.
Uh oh, another Debian converted! Break out the granola!
I'm sorry but I have to say this...
After 11 years using, developing for, and administering Linux (almost exclusively) in my profession, my view is that the "Debian Way" has a very snooty view of anyone else.
I see it as the stereotypical "Linux view" of the *BSD crowd's superiority complex. It's like academia unleashed.
Mod me down, I don't care. I'm a fair and level guy, and I don't believe that there is total untruth in my opinion here.
IMO Microsoft made a grave design error when they decided to place GUI components in kernel space.
The result is that a simple app can bring Windows to its knees as a non-priviledged user.
A kernel should be nothing but a hardware cop. Tightly controlled multi-user access to local hardware resources. Everythnig else belongs in user space.
Mozilla does it both ways. Look at Firefox, Phoenix and the like. Getting Microsoft to decouple programs and dependencies requires DOJ intervention, if they do it at all.
You don't understand the UNIX philosophy. If you did, you would not not have made that grossly ignorant statement.
Slashdot Mirror
I'm sorry, but if you do a blind emerge world on a prodcution server, you're fired. Just drop your stuff and go. A home box is one thing, a mission critical server is quite another.
I don't disagree with your comments. I just personally felt that he was using the term "opensource" liberally, and to mean all software which may be considered opensource. He may think he is in a position to speak for opensource, and that's fine. The author though sppears to attempt to speak for free software as well, all though he fails to mention it specifically.
Some in the free software camp will take offense to the fact that this author attempts to speak for all, when he is in no position to do so. I don;t mean to nitpick, but the title of the article is in reference to OSS specifically, but the commentary includes things which are specifically free software. He has overstepped his bounds.
I think many people (including me) would take offense to this guy packaging Opensource in with Free Software. He also takes the libery to call witness to the greatness of the opensouce development model.
I realize that to many people, OSS and Free Software are synonymous. To those who fall squarely within either camp, the differences are meaningful enough to warrant the existence of two separate groups. This guy seems to fall into the OSS camp, which is fine and well, but one can't have their cake and eat someone else's.
There are fundamental differences.
worms, adware, spyware, malware, adn a frenzy of activity. Talk about these things effecting "computers". Bullshit.
I am dead serious whaen I say that from now on I am going to call all of the above by one name:
dontuserfuckingwindowsyoufoolware
How about we simply call it: dontfuckingrunwindowsyouidiotware
If the appeals panel decides that the consumers groups can't contest the FCC requirements, it would dismiss the case regardless of any concerns about the anti-piracy technology. A decision by the court could happen within months.
What this means to me if I interpret correctly is:
Although the judge knows well what the FCC is trying to accomplish, and doesn't like it, that does not mean that this will not pass. There are recognized examples of where this regulation would hamper currently legal uses, however, the regulation by nature is not a block to those groups only, but to the broader public. I get the sense that it may be passed, on the stipulation that the FCC have contingengies to address known exceptions to the rules, such as libraries and such.
More disturning is the possibility of it getting passed, while the judges are aware that challenges from groups recognized to be exempt may be deemed moot. This would mean that if it passes, it would be with the understanding that libraries and schools (not to mention everyday joes through fair use) would have existing rights stripped.
I don't live in the US, but I really hope that my American friends don't have to swalow this garbage. I can picture the judge's grim face when he made those statements. Hopefuly is fails.
If this passes, I seriously believe that America (as I believe American's view America) is lost.
You could try to stop time, progress and technical evolution. That way, your shiny new equipment will never become obsolete.
Sorry, that's a small jab. We can't predict what the future will bring. I can tell you this though...
If you want to be able to do things with bits that the powers that be try to stop you from doing, your best bet will always be had in the hobyist (read free software / oss) areas. This is because companies who want to compete and cooperate to get your money will b forced to play by the rules imposed by those would deny digital rights. Individuals will not bend to this, so the free stuff, while admitedly slower on the curve, will be your best bet, if freedom is your motivation. This means invest in your PC.
If you want digital input to your TV, go over DVI, but be sure that any set you look at will play non DRM encoded stuff. I believe the MPAA is attempting to mandate the broadcast of digital signals in a format which will limit rights. There are two types of digital interface on a television. My memory is sketchy here, I bought my set over 18 moonths ago. I do know though that there are a couple of different interface/protocol types, some of which use only the protocol which the MPAA is trying to define (in their favour). Be careful of that.
Wow, are you a prima-donna code monkey or what?
I have news for you. After 15 years in IT, I have only ever met 1 (count, one) developer who knew what the hell they were doing, and that I would trust to touch production services.
I have implemented and managed Linux and UNIX development environments, build processes etc. for 8 years, and believe me, allowing developers free reign is a recipe for disaster.
Some unfortunately develop prima-dona-itis, as the parent seems to have. I know sysadmins who also develop prima-donna-itis. No matter the job you perform, if you develop this wicked sickness, you are a cancer on your work environment, and should be the first to go. In fact, most people other than the prima-donna know who the prima-donnas are, and cost cutting time is a great time to get rid of the cancer.
Amen, brother.
One GUI email reader is XFMail and derivatives. I happend to need to sort, filter and process thousands of emails a week, so for me, speed and efficiency is everything. It's not pretty, although I believe one of the derivitives uses GTK, and another emulates the Next mailapp. I haven't tried these derivatives. XFMail can run a dozen filters against 5000 messages in about 5 seconds, and that's over NFS!
I'm sorry for your mistake. The Mitsubishi line of SUVs are the most decrepit, unsafe vehicles on the road.
In a Consumer Reports frontal impact aversion test, the Montero repeatedly tried to flip over at very low speeds, well under the lowest flip level of any other SUV EVER tested. They put training wheels on it. It was so bad in fact, that they refused to give the vehicle a safety score at all, and instead listed the Montero as an unsafe vehicle in a special warning report.
I also hve a personal friend who has had no end of trouble getting warranty work done on this Rodeo. The Mitsubishi SUVs are so ill reputed in fact, that several dealers refused to accept it as a trade in once he finally broke down and decided to replace it.
You misunderstand the parent's point. You cannot compare a userland tool to a package format. Repeat that to yourself. If it is still unclear, or you don't understand, then continue your cluless zealotry. Poeple who know, will know that you're talking out of your ass, just like the patent does.
I wrote a post some time ago about how I thought VoIP was not ready for primetime. I was subequently trashed by a self-affirming moron and rated down. Whatever.
Voice communication relies on time sensitive delivery of very small bits of information.
IP networks are designed to deliver large gulps of information in a non so timely fashion. Wht I mean by this is that in an IP network, equipment will deliver information as quickly as it can, but there's nothing the 802.x quite of protocols which inherantly facilitates predictably timely delivery of data. Timely delivery is governed by network and infrasturcture "health". Sure, there's QoS, but that ultimately gives very little benefit unless the network is under heavy load anyways, in which case, VoIP is a bust regardless.
Conversations can seem decoupled. Calling someone 1/2 mile away can introduce the latency that can be expected when calling overseas. It doesn't feel "like a phone" to many end users.
Jitter, latency (huge), and the general difficulty of "simulating a telephone" over IP services is what will prevent VoIP for taking hold until several generations of technology and a generation or two of home connectivity methods is introduced.
Contrast ATM networks, which are designed specifically to deliver small bits of information very quickly. These networks are ideal of VoIP.
Poeple don't have ATM to their houses, they have DSL or cable services which offer NOWHERE near the reliability of a typical voice network.
Someone can fairly realistically expect 1/2 of a building to be blown to pieces, while a phone in the other half will work. This is how reliable voice networks have been.
Within a company on a controlled LAN, VoIP can work because you have some control over the quality of the service. To the home, we are not close to being ready.
I've implemented VoIP switches since their initial introduction, I have spoken at international conferences on the merits and pitfalls of VoIP. I'm not trying to toot my own horn, I'm just saying.... I've used and abused these switches, phones and protocols, and I find them lacking outside tightly controlled environments. Across a vendor's backbone? Sure, no problem. Will I use it exclusively in my home? No freaking way.
IPv6 makes for nice project work, but I don't believe that it will ever be implemented in any meaningful way, at least for a good long while.
Eggheads play with it, manufacturers move to support it, but nobody uses it. When I say this, I mean, nobody is forced to use it, so nobody will make the change.
If anything should be replaced it's TCP.
The LSB Package file format specification describes how a package file is formatted.
File header, payload section alignment, header section alignment and how the header is defined, metadata. How to navigate, read, extract and create package files according to set specifications.
The standard defines convention for a package "file format", it does not dictate which tools must be used to interact with them.
Adding the bells and whistles is up to the distributor. If someone's reasoning for Apt being better is simply that "It can recursively update packages which are required by the one I am requesting", then that is fine, but don't confuse your opinion of a better userland tool for a better package file format. The tool may suit your fancy better, this does not reflect on the package file format specification.
Automatic fetches, catalog indexing, dependancies etc can be handled outside of the package file itself. I would say that this functionality is best left outside of the package file format specification.
Ironic that George Lucas would make a movie where consumerism is a sickness in society. This coming from the guy who is an uber IP controls advocate, and an uber market-the-garbage-to-death-and-they-will-buy guy.
Although what you say is technically correct, I don't trust RMON. Different equipment vendors have different implementations and levels of conformance. Beyond this, there are also limiting factos which fall outside of RMON itself.
Process priorities for example. If a switch is under load, will the switch begin dropping packets to the agent process in order to better service the network? How much overhead does the agent create if actively monitoring? Will it effect switch engine perfomance?
There are other reasons, like horrible conformance to spec of equipment manufacturers. You'll get as many quirky implementations as there are manufacturers, and in some cases models and revisions of a different switch.
Not to discredit your points, they are valid, so long as you know that it is in fact functioning as you believe it is...
2 days off (building shut down), Barbecues with the neighbours in the yard, and watching DVDs in the van. :)
Again! Again!
Wow, I think this thread, and more specifically the parent post, illustrates beautifully why in nearly twelve years of Linux use, I have never found Debian palatable.
Elitism unleashed. Everything but everything boils down to philosophical self affirming debate.
The ball is blue.
T'isn't.
Yes, it is. I'm looking right at it.
That, of course, would depend on your ability to perceive reality in your current state. It appears as though, perhaps, because of your lack of understanding of my point of view (which is correct), that you are not capable of perceiving the colour of the ball, because your beliefs regarding "colour" are incorrect. You believe that the ball is blue, but it is green. You cannot identify the colour correctly because you have never learned green from blue. This axiom has limited your ability to perceive colour as it should be perceived, according to the Debian philosophy.
OK, never mind.
Will you be furnishing more examples?
Uh oh, another Debian converted! Break out the granola!
I'm sorry but I have to say this...
After 11 years using, developing for, and administering Linux (almost exclusively) in my profession, my view is that the "Debian Way" has a very snooty view of anyone else.
I see it as the stereotypical "Linux view" of the *BSD crowd's superiority complex. It's like academia unleashed.
Mod me down, I don't care. I'm a fair and level guy, and I don't believe that there is total untruth in my opinion here.
IMO Microsoft made a grave design error when they decided to place GUI components in kernel space.
The result is that a simple app can bring Windows to its knees as a non-priviledged user.
A kernel should be nothing but a hardware cop. Tightly controlled multi-user access to local hardware resources. Everythnig else belongs in user space.
Give your head a shake.
Mozilla does it both ways. Look at Firefox, Phoenix and the like. Getting Microsoft to decouple programs and dependencies requires DOJ intervention, if they do it at all.
You don't understand the UNIX philosophy. If you did, you would not not have made that grossly ignorant statement.
Maybe this guy should have his letters spell checked. The grammar is terrible too!
Maybe I'm taking the wrong view, but an official letter posted on a company site should be more professionally presented.
Very useful, and entertaining hack!
I plan on incorporating this into my home automation project work!
Coming soon to a theater near you!
In a word: never