There is an insurmountable disconnect between those that understand why these things are done and those that don't. It's fundamental to how each thinks. As much as you say you don't understand us, we don't really understand you. There isn't a good/convincing way to explain either position to the other, nor should there really need to be.
In a way, it's like asking someone why they like, say, raw fish, or really any other food one might find unpalatable. It's not a very useful question, because it comes down to individual taste. If the questioner doesn't already understand, they're unlikely to appreciate the merit of any particular response someone might come up with.
* Any object should be able to have an arbitrary number of 'links' to any other object (and we've just implemented an object-oriented database, but that's just outside the scope of this discussion). * Labels are objects.
* Labels can therefore have links to other labels. * Messages are objects.
* Therefore labels can have links to messages (and/or vice-versa, this gets into implementation details that aren't really important here).
* (And messages can have links to other messages, we've just implemented threading, but again, outside the scope of this discussion.) * Therefore, a label can contain links to messages as well as other labels. This can be infinitely nested.
Fully representing this in a standard tree is, of course, impossible (loops), but one could fake it pretty well if the user cooperates (which they presumably would if they were that desperate to keep to their existing UI paradigms for representing folders). There are UI tricks one could implement and make available to the user to make it easier to not screw up (and detecting loops and sticking an "Error" node on the tree explaining what happened is not overly difficult, either).
What this amounts to is that with a proper generalization and UI treatment, it becomes perfectly possible to implement the concept of "folders" in a system that only understands "labels". There is nothing about the concept of labels that precludes this.
Labels are not really "another feature", they're a generalized replacement. You can fully implement all of the functional aspects of folders -- and much more -- with labels.
The fact that gmail doesn't implement the final step (nested, or, more properly generalized, 'linked' labels) is something you could bring up with Google instead of making yourself look silly on slashdot with ignorant whinging.
"The lesson to be learned here isn't that FOSS is bad, but that people using software written by a third party should look at what they are using a little more closely before the public gets to interact with it."
Yes, because as we all know, suppliers of hardware to government agencies like NASA are always focused on driving down prices.
Your argument assumes that it's impossible to create space-worthy parts substantially cheaper than existing vendors of such parts sell them to governments and large corporations (which aren't really any better than governments in efficiency or cleverness). There is no evidence that this is true, and some evidence that it is definitely not (SpaceShipOne cost $25 million to develop; how much do you think NASA would have spent to develop a manned sub-orbital plane from scratch?).
Yours is exactly the attitude I was talking about. Those steeped in the ways of government bloat will not be nearly as successful at space flight for fractions of NASA's budgets because instead of trying, you just assume it's impossible. The orthodoxy is infallible!
The real key isn't to "get the necessary money", it's to "make the project sufficiently cheap", which is something government agencies are notoriously bad at. NASA engineers are technically competent, but they probably don't have the skills necessary to shrink what would normally be a project with a budget in excess of $100million down to a fraction of that.
You might well use ex-NASA people as consultants for something like this, but you don't have them do the design.
And what backwater corporate environment do you work in? We have developers working from home (both full and part time), developers working while on business trips around the country, even developers living and working on entirely different continents. All of these can benefit from the features of distributed version control systems.
If you're employed in tech in the US and not making $400 or more for 2-3 days of work, there's a decent chance you're doing something wrong. $16-$25/hr is not particularly special, it's entry to mid-level pay depending on exactly where you are (in the San Francisco Bay area, it's not even "mid-level").
As for "spare time" having no monetary value, that's pretty absurd. For some people, it may be effectively true (though I'd argue most such people have the financial sense of a rock), but for others, the monetary value of your time is whatever you can get for it.
A second job, side consulting, or even researching investment strategies are all ways to monetize time not spent working at a "primary" job. The question is not "Does my spare time have value?", it's "How do I wish to extract the value of my spare time?". The answer to that question depends on the answer to other questions, like (simplistically) "Is the money I could get from working two extra hours per day worth more to me than time spent relaxing?".
If you prefer to use your spare time to goof off, that's fine. Nobody can make the right decision for you. But thinking that time outside of a 40-hour-a-week job has no value is pretty silly.
VMware's shared folders mechanism has always been a security hole waiting to happen (VMware's own docs pretty much admit that). I don't use them on servers at all, nor on any desktop where security has anything to do with the reason I'm using virtualization.
In the end, I really don't give a damn whether my boss is impressed with me or not. That's not what I'm getting paid for. If they're not impressed by the fact that I do what I'm paid for, and do it well, that's their loss.
I think our CEO technically has an office, but it's usually being used for meetings he's not in.
I believe the only time I've actually seen non-management tech workers get a private office was the result of a fluke. Large company (several thousand employees) buys remains of relatively small company (few hundred) with a long lease on half of a very roomy building with lots of small individual offices, and underutilizes the space. As a result, the only people in the largely-desolate cube farms were temporary workers. Everyone making more than, say, $35k, got an office.
The nature of spaceflight means most danger comes during launch and reentry/landing (and those two periods are when all fatalities have occurred), not on-orbit, making a direct distance or time comparison meaningless. The most direct surface comparison would be starting a car's engine vs. launching, and parking a car vs. reentry/landing, but this is obviously absurd since, statistically, people don't die starting or parking cars.
One would need to come up with a model based on number of launches and landings vs time spent in the most dangerous routine circumstances of driving. Even then, I suspect the numbers would look pretty similar.
There are around 43,000 traffic fatalities per year in the US. If we posit that a mere 60,000,000 people (only 1/5th of the US population) get in a car or cross the street on foot every year, that's a total death rate of about 0.00072%.
There have been 439 astronauts. 19 of them have died in flight. That's 4.5%, meaning you are, given the above incredibly pessimistic estimate, more than 6000 times as likely to die in a spaceship than in the rolling deathtrap called a car. And by the way, 14 of those 19 deaths have happened in the Space Shuttle, the most advanced manned spacecraft to currently fly on a regular basis.
You'll therefore excuse me if I find your risk assessment lacking.
"The operation of transmitters designed to jam or block wireless communications is a violation of the Communications Act of 1934, as amended ("Act"). See 47 U.S.C. Sections 301, 302a, 333. The Act prohibits any person from willfully or maliciously interfering with the radio communications of any station licensed or authorized under the Act or operated by the U.S. government. 47 U.S.C. Section 333. The manufacture, importation, sale or offer for sale, including advertising, of devices designed to block or jam wireless transmissions is prohibited. 47 U.S.C. Section 302a(b). Parties in violation of these provisions may be subject to the penalties set out in 47 U.S.C. Sections 501-510. Fines for a first offense can range as high as $11,000 for each violation or imprisonment for up to one year, and the device used may also be seized and forfeited to the U.S. government."
This applies even on private property, because of the largely uncontrollable nature of signal propagation. For this same reason, it is effectively impossible for any person, entity, or government short of the federal government in the US to make any sort of rules relating to radio transmission, no matter where they try to enforce such rules.
Or you might just have to go look online for a patch or new package that a community member created. Or if you have the requisite skillset, you might even be able to fix it yourself.
This is one of the advantages to FOSS. Yes, you might end up having to wait for the next release like any other package (or you might just prefer to wait, if you lack time or the bug isn't severe enough to motivate you), but you might have other options/choices.
I carry a laptop with me everywhere, I have all my data on its 250GB HDD. I have no need for a USB drive on my keychain. I do need to grab one soon for special purposes, but it's never going to be on my keychain, it's going to be in my backpack with other assorted tools I almost never have need of for rare use at customer sites in environments where network connectivity is limited.
The Apache parent, the OpenSSH sshd parent(s), the postfix master process (postfix! an SMTP server built for the express purpose of security!), xinetd. These are just a few common network daemons that run as root as standard practice with their author's blessing.
Welcome to the real world, it's not so rosy as you seem to think.
This isn't about a root process being able to bypass the firewall, it's about external users being able to bypass the firewall to talk to a process running as root. I happily run such processes behind firewalls without caring much about potential vulnerabilities, because I know only trusted users have access to it, therefore only trusted users, who would already have full access to the box (either physically or by remote sudo/root access) anyway could exploit it and gain root.
A firewall that allows unrestricted connections to any process running as root completely breaks this model, and though one may argue about its theoretical wisdom and purity, it's a model that is incredibly critical to a great many networks in practice.
Amen. I don't know what the hell he's talking about, but every EDGE link I've ever used, best ping was over 700ms. My EVDO card from sprint never breaks 200ms, usually hovers between 120 and 150, emphasis towards the low end. And SSH is actually practical over it!
It can be used as a safety mechanism for testing non-malicious code. It can also be used to setup an environment that uses different versions of key libraries or utilities from the host to run code that might not otherwise work. Linux distributions tend to make use of the chroot facility for installation tasks, as well.
Using chroot on a process is like handing a person a map with an X on the destination. You've shown them where they're supposed to go, you haven't really done anything to prevent them from running off in another direction.
To me, PHP is BASIC for the web. It was written for (and I suspect, initially at least, by) people who really have no grasp of programming. It's not _useless_, but I'm going to avoid it for what I consider "real" apps. I'd use it for prototyping and one-offs except I wouldn't save much time over Perl.
Among the other common web languages, I'm going to pick Perl. It's the only one that lets me do what I want without putting me through a philosophical lecture. It recognizes itself as a practical tool rather than a political instrument, and allows me to get useful work done without chiding me because my solution is not in communion with the orthodoxy. Python, Ruby, etc. all try to preach to me in some way (wildly differing ways, I'll grant you, but they're still preachy), Perl just says "here are your choices, pick the one that works for you". Also, I consider Java a no-no as a standard "language of choice" for the web unless you already have a large Java skillset in-house or particularly specialized requirements.
I'm also going to avoid mod_perl on technical grounds. It hurts portability and introduces security and administrative issues if it's running on shared or multi-purpose servers. I'll go with FastCGI if performance is an issue.
Slashdot Mirror
There is an insurmountable disconnect between those that understand why these things are done and those that don't. It's fundamental to how each thinks. As much as you say you don't understand us, we don't really understand you. There isn't a good/convincing way to explain either position to the other, nor should there really need to be.
In a way, it's like asking someone why they like, say, raw fish, or really any other food one might find unpalatable. It's not a very useful question, because it comes down to individual taste. If the questioner doesn't already understand, they're unlikely to appreciate the merit of any particular response someone might come up with.
Except AIM *DOESN'T* support the same feature set, it's actually inferior to ICQ. No offline delivery of messages.
Actually, let's _really_ generalize it properly.
* Any object should be able to have an arbitrary number of 'links' to any other object (and we've just implemented an object-oriented database, but that's just outside the scope of this discussion).
* Labels are objects.
* Labels can therefore have links to other labels.
* Messages are objects.
* Therefore labels can have links to messages (and/or vice-versa, this gets into implementation details that aren't really important here).
* (And messages can have links to other messages, we've just implemented threading, but again, outside the scope of this discussion.)
* Therefore, a label can contain links to messages as well as other labels. This can be infinitely nested.
Fully representing this in a standard tree is, of course, impossible (loops), but one could fake it pretty well if the user cooperates (which they presumably would if they were that desperate to keep to their existing UI paradigms for representing folders). There are UI tricks one could implement and make available to the user to make it easier to not screw up (and detecting loops and sticking an "Error" node on the tree explaining what happened is not overly difficult, either).
What this amounts to is that with a proper generalization and UI treatment, it becomes perfectly possible to implement the concept of "folders" in a system that only understands "labels". There is nothing about the concept of labels that precludes this.
Labels are not really "another feature", they're a generalized replacement. You can fully implement all of the functional aspects of folders -- and much more -- with labels.
The fact that gmail doesn't implement the final step (nested, or, more properly generalized, 'linked' labels) is something you could bring up with Google instead of making yourself look silly on slashdot with ignorant whinging.
"The lesson to be learned here isn't that FOSS is bad, but that people using software written by a third party should look at what they are using a little more closely before the public gets to interact with it."
Fixed for you.
Yes, because as we all know, suppliers of hardware to government agencies like NASA are always focused on driving down prices.
Your argument assumes that it's impossible to create space-worthy parts substantially cheaper than existing vendors of such parts sell them to governments and large corporations (which aren't really any better than governments in efficiency or cleverness). There is no evidence that this is true, and some evidence that it is definitely not (SpaceShipOne cost $25 million to develop; how much do you think NASA would have spent to develop a manned sub-orbital plane from scratch?).
Yours is exactly the attitude I was talking about. Those steeped in the ways of government bloat will not be nearly as successful at space flight for fractions of NASA's budgets because instead of trying, you just assume it's impossible. The orthodoxy is infallible!
The real key isn't to "get the necessary money", it's to "make the project sufficiently cheap", which is something government agencies are notoriously bad at. NASA engineers are technically competent, but they probably don't have the skills necessary to shrink what would normally be a project with a budget in excess of $100million down to a fraction of that.
You might well use ex-NASA people as consultants for something like this, but you don't have them do the design.
And what backwater corporate environment do you work in? We have developers working from home (both full and part time), developers working while on business trips around the country, even developers living and working on entirely different continents. All of these can benefit from the features of distributed version control systems.
Democrats aren't the ones who scream that supply-side economics are the solution to all the world's problems.
Where do you live?
If you're employed in tech in the US and not making $400 or more for 2-3 days of work, there's a decent chance you're doing something wrong. $16-$25/hr is not particularly special, it's entry to mid-level pay depending on exactly where you are (in the San Francisco Bay area, it's not even "mid-level").
As for "spare time" having no monetary value, that's pretty absurd. For some people, it may be effectively true (though I'd argue most such people have the financial sense of a rock), but for others, the monetary value of your time is whatever you can get for it.
A second job, side consulting, or even researching investment strategies are all ways to monetize time not spent working at a "primary" job. The question is not "Does my spare time have value?", it's "How do I wish to extract the value of my spare time?". The answer to that question depends on the answer to other questions, like (simplistically) "Is the money I could get from working two extra hours per day worth more to me than time spent relaxing?".
If you prefer to use your spare time to goof off, that's fine. Nobody can make the right decision for you. But thinking that time outside of a 40-hour-a-week job has no value is pretty silly.
VMware's shared folders mechanism has always been a security hole waiting to happen (VMware's own docs pretty much admit that). I don't use them on servers at all, nor on any desktop where security has anything to do with the reason I'm using virtualization.
In the end, I really don't give a damn whether my boss is impressed with me or not. That's not what I'm getting paid for. If they're not impressed by the fact that I do what I'm paid for, and do it well, that's their loss.
I think our CEO technically has an office, but it's usually being used for meetings he's not in.
I believe the only time I've actually seen non-management tech workers get a private office was the result of a fluke. Large company (several thousand employees) buys remains of relatively small company (few hundred) with a long lease on half of a very roomy building with lots of small individual offices, and underutilizes the space. As a result, the only people in the largely-desolate cube farms were temporary workers. Everyone making more than, say, $35k, got an office.
The nature of spaceflight means most danger comes during launch and reentry/landing (and those two periods are when all fatalities have occurred), not on-orbit, making a direct distance or time comparison meaningless. The most direct surface comparison would be starting a car's engine vs. launching, and parking a car vs. reentry/landing, but this is obviously absurd since, statistically, people don't die starting or parking cars.
One would need to come up with a model based on number of launches and landings vs time spent in the most dangerous routine circumstances of driving. Even then, I suspect the numbers would look pretty similar.
There are around 43,000 traffic fatalities per year in the US. If we posit that a mere 60,000,000 people (only 1/5th of the US population) get in a car or cross the street on foot every year, that's a total death rate of about 0.00072%.
There have been 439 astronauts. 19 of them have died in flight. That's 4.5%, meaning you are, given the above incredibly pessimistic estimate, more than 6000 times as likely to die in a spaceship than in the rolling deathtrap called a car. And by the way, 14 of those 19 deaths have happened in the Space Shuttle, the most advanced manned spacecraft to currently fly on a regular basis.
You'll therefore excuse me if I find your risk assessment lacking.
* File a police report detailing how your drive was stolen from you.
* Complain to your state attorney general.
* Complain to the BBB.
* Make sure the Apple Store manager and Apple HQ gets copies of all of the above.
I'll bet you have your drive back in a few days.
http://wireless.fcc.gov/services/index.htm?job=operations_2&id=cellular
"The operation of transmitters designed to jam or block wireless communications is a violation of the Communications Act of 1934, as amended ("Act"). See 47 U.S.C. Sections 301, 302a, 333. The Act prohibits any person from willfully or maliciously interfering with the radio communications of any station licensed or authorized under the Act or operated by the U.S. government. 47 U.S.C. Section 333. The manufacture, importation, sale or offer for sale, including advertising, of devices designed to block or jam wireless transmissions is prohibited. 47 U.S.C. Section 302a(b). Parties in violation of these provisions may be subject to the penalties set out in 47 U.S.C. Sections 501-510. Fines for a first offense can range as high as $11,000 for each violation or imprisonment for up to one year, and the device used may also be seized and forfeited to the U.S. government."
This applies even on private property, because of the largely uncontrollable nature of signal propagation. For this same reason, it is effectively impossible for any person, entity, or government short of the federal government in the US to make any sort of rules relating to radio transmission, no matter where they try to enforce such rules.
Which would be a violation of federal law.
Or you might just have to go look online for a patch or new package that a community member created. Or if you have the requisite skillset, you might even be able to fix it yourself.
This is one of the advantages to FOSS. Yes, you might end up having to wait for the next release like any other package (or you might just prefer to wait, if you lack time or the bug isn't severe enough to motivate you), but you might have other options/choices.
I carry a laptop with me everywhere, I have all my data on its 250GB HDD. I have no need for a USB drive on my keychain. I do need to grab one soon for special purposes, but it's never going to be on my keychain, it's going to be in my backpack with other assorted tools I almost never have need of for rare use at customer sites in environments where network connectivity is limited.
The Apache parent, the OpenSSH sshd parent(s), the postfix master process (postfix! an SMTP server built for the express purpose of security!), xinetd. These are just a few common network daemons that run as root as standard practice with their author's blessing.
Welcome to the real world, it's not so rosy as you seem to think.
This isn't about a root process being able to bypass the firewall, it's about external users being able to bypass the firewall to talk to a process running as root. I happily run such processes behind firewalls without caring much about potential vulnerabilities, because I know only trusted users have access to it, therefore only trusted users, who would already have full access to the box (either physically or by remote sudo/root access) anyway could exploit it and gain root.
A firewall that allows unrestricted connections to any process running as root completely breaks this model, and though one may argue about its theoretical wisdom and purity, it's a model that is incredibly critical to a great many networks in practice.
Amen. I don't know what the hell he's talking about, but every EDGE link I've ever used, best ping was over 700ms. My EVDO card from sprint never breaks 200ms, usually hovers between 120 and 150, emphasis towards the low end. And SSH is actually practical over it!
It can be used as a safety mechanism for testing non-malicious code. It can also be used to setup an environment that uses different versions of key libraries or utilities from the host to run code that might not otherwise work. Linux distributions tend to make use of the chroot facility for installation tasks, as well.
Using chroot on a process is like handing a person a map with an X on the destination. You've shown them where they're supposed to go, you haven't really done anything to prevent them from running off in another direction.
To me, PHP is BASIC for the web. It was written for (and I suspect, initially at least, by) people who really have no grasp of programming. It's not _useless_, but I'm going to avoid it for what I consider "real" apps. I'd use it for prototyping and one-offs except I wouldn't save much time over Perl.
Among the other common web languages, I'm going to pick Perl. It's the only one that lets me do what I want without putting me through a philosophical lecture. It recognizes itself as a practical tool rather than a political instrument, and allows me to get useful work done without chiding me because my solution is not in communion with the orthodoxy. Python, Ruby, etc. all try to preach to me in some way (wildly differing ways, I'll grant you, but they're still preachy), Perl just says "here are your choices, pick the one that works for you". Also, I consider Java a no-no as a standard "language of choice" for the web unless you already have a large Java skillset in-house or particularly specialized requirements.
I'm also going to avoid mod_perl on technical grounds. It hurts portability and introduces security and administrative issues if it's running on shared or multi-purpose servers. I'll go with FastCGI if performance is an issue.