Does anyone have an example of a potentially dangerous security flaw that was detected and fixed by a software system with no human interaction? I've never heard of it, although I'll gladly have a slice of humble pie if I'm just ignorant.
If I'm right, I suspect an antivirus network like this is extremely likely to zombie-fy the honeypots, and then use them to propagate a back door to every system relying on the antivirus network.
I disagree. If you limit the set of businesses in question to large businesses only, you will find unethical practices. As soon as a business grows large enough, there becomes too much of a separation between the important management decisions and the actual product that the business provides. The shareholder-centered paradigm of any big business contradicts and supersedes almost any initiative to maintain corporate integrity, where Google and a few others are the shining exception. And do note that Google, until recently, was privately owned, even though it was, and still is, a big business, which makes it exceptional for the original "Big Business? Ethical?" question for more than one reason. The phrase, "maximize shareholder profit" is the culprit in almost every big business abandonment of ethical decision-making.
(continuing the shipping analogy kick) what BS is attempting to do is make it legal for certain shipping companies to violate traffic laws to arrive at destinations faster than the competition. Imagine the Fedex truck running the UPS truck off the road, cutting it off in heavy traffic, speeding, and getting pushed to the front of every line at a toll booth or stoplight, while the cops stand by and make sure that the UPS truck bends over and takes every disadvantage right up the tailpipe. This is what BellSouth is suggesting. It probably won't make much of a difference on roads that are wide and have speed limits that are near the maximum speed that the shipping trucks can travel at, but it makes a huge difference on crowded streets or sections of road with low speed limits.
Unfortunately, kiloscads (to borrow and bastardize a term) of other non-ethical big businesses make your anecdotal evidence the exception rather than the rule.
Agreed. But most residential users have Dynamic IP. Your personal IP probably changes every time you boot up your machine. So, those IP addresses you are seeing for anonymous users are pretty much useless.
Not quite true. When I did network administration, we had "dynamic ip" (or DHCP for people who know what they're talking about), and I could still track down, to the physical hardware, any IP address. There are two key things in play here that any ISP that intends to cover its ass(ets) should be maintaining:
Audit trails: logs, logs, and more logs! A decent DHCP server is going to log out something like
2005-10-1 22:23:15 MAC Address xx:xx:xx:xx:xx:xx:xx:xx received a two-day lease for network address xxx.xxx.xxx.xxx
This links a hardware (MAC) address to a network address at a particular point in time.
Network address ranges correlating to physical locations, e.g. neighborhood, shopping center, etc.
With these two things, a decent ISP should be able to, with little effort, examine their logs if a legal issue arises, and say where the physical hardware was located (down to the neighborhood, roughly), and determine if the same MAC address is still on their network somewhere. It's not pinpoint accuracy, but it's better than the usual "We haven't got a bloody clue, and we're not liable" story that most ISPs in this situation have given.
A good client does not have a giant SUBMIT button (Everybody knows enter/return sends).
A good client has tabs (Nobody wants a dozen chat windows).
I find these two rather contradictory. I hate, HATE tabbed IM windows, although I love my tabbed browser. Why? Because my browser has tabs based on actions *I* take, whereas new tabs show up in tabbed IM windows based on actions *someone else* takes (potentially). Therefore, if a person initiates a conversation with me, I want to know about it in another way than having to constantly keep checking that particular window for changes, and without bugging my co-workers with the usual cutesy, annoying A-New-Conversation-Has-Begun noise. This is why separate windows are key. Furthermore, while I'm using my multiple-desktop WM, I tend to segregate tasks into different desktops, each with a number of associated IM conversations. How much would it suck to be required to undock a tab from a particular window, only to re-dock it with another window on another desktop just to get it to do what I want it to do? Therefore, the omission of a giant SUBMIT button is contradictory to the idea of tabbed IM windows, since the aforementioned omission is in the interests of keyboard-only operation of the client, whereas tabs almost always force you to use the mouse extensively.
Furthermore, on any number of these tabbed IM windows, any number of messages from any number of users can be received, requiring you to cycle through the windows in the WM, only to cycle through the tabs in the client. I'd rather let my WM be the indicator of the set of conversations that need attention, rather than having a 'two-stage' process that is associated with the use of tabs. So, in response to these two particular items in your list, I say leave the submit button, but make it discreet and non-obnoxious. Heck, you could even let the IM window be skinnable, so that the submit button could be as big, small, or (non)existent as any self-motivated user wants to make it be. And let the 'tabual orientation' of the client be configurable, and OFF by default.
Do you believe that the scope of the research project was intentionally engineered to favor Microsoft Windows? If so, did you make any attempts to expand the scope to be more neutral? What were the results?
How appropriate, "Nothing to see here, please move along." This would be the caption for my mental associations with sony whenever I'm out shopping for Christmas gifts. Sony producing new technology isn't terribly interesting to me if I know they might be installing rootkits on my boxen.
I, for one, believe this to be absolute B.S. If fear of the consequences is the only thing that keeps us in line, we're all screwed. Yes, consequences of bad behavior is a deterrent, but it should be a learning mechanism, not a restraint. Our sense of morality should be the ultimate determining factor in our behavior. If not, we're nothing but rats in cages, responding to stimuli. Most of the moral decisions that I make have nothing to do with perceived consequences; I choose to act a certain way because my moral convictions dictate that I should do so.
The United Sates has more than twice the per capita PhDs.
But when you consider the Asian per capita income (which, I suspect, would be much less than half the corresponding figure in the US), comparatively, we're producing fewer Ph.D.s than Asia in terms of resource distribution over the entire population. This means the U.S. Ph.D. programs have some combination of the following traits:
You could use XML to marshall the objects. It lends itself rather well (if you're careful with how you construct your schema) to dealing with some of the interesting challenges with virtual member functions and variables. It may be overkill in certain situations, but it's probably a simpler way to deal with marshalling than re-working a large object hierarchy so that it contains no virtual functions/variables; i.e. don't reinvent the wheel.
I understand what you're saying, but, IMHO, a hardware vendor has two options regarding software if they want to adopt an open-source model:
Release the hardware specs and let the open-source community maintain the drivers.
Keep all proprietary don't-want-this-publically-visible code on-board the hardware as firmware (which could possibly overlap with 1. - a developer probably wouldn't know if they're interfacing with direct silicon programming or firmware anyway). I don't have a problem with hardware vendors keeping secrets, as long as they're still friendly to the open-source community while doing so. If the hardware vendor's best features are written in code and not in silicon, I don't believe that the open-source community should steal those features from them. Again, I would expect that hardware vendors would keep certain circuit designs and code proprietary, because that is intellectual property that they are attempting to make money from.
In spite of the usual corporate mindset that is driven by time-to-market, I believe that hardware vendors would benefit from a more open-source-friendly marketing strategy. It would increase the stability and robustness of the system as a whole, and train both Linux developers as well as hardware manufacturers to effectively and consistently hit the moving target of evolving hardware.
In response to your particular scenario, one of two things would be true of each bug in the 1.1 version of the hardware: either the new hardware breaks the spec and the old did not, or the old broke the spec and the new does not (in which case the driver was written according to the broken hardware, and not to spec). It is the hardware vendors' responsibility to provide specs for interfacing with the hardware, and it is the software developers' responsibility to write drivers according to that spec. So, the solution to your particular scenario would be that the 1.1 version of the hardware would need a new specification with it (more than likely, since it's a minor version change, presented as a delta from the original spec). If the spec is right, the Linux developers are going to have a good chance (and probably a better chance than most closed-source shops) of creating a robust driver that operates the hardware at the best performance possible.
As for your comments about effort vs. return, this is where understanding the benefit of an open-source-friendly is key. Yes, you're only reaching 5% of the market, but by spending the extra effort for doing so, how much money are you saving over 5 years by having a more successful (read: less buggy) software development model? How much will that 5% section of the market grow in 5 years because you adopted an open-source model? Your assessment of effort vs. return is a bit shallow and short-sighted.
As it exists now, the manufacturers are expecting the Linux community to jump through all the hoops. They expect Linux to define an ABI (which includes mystically divining all the hooks that it will need when new hardware types show up), and support that ABI thick-and-thin, no-matter-what. Part of the open-source model is the flexibility it provides when there is a need to abandon the mistakes of the past regarding interfaces. See above for tons of comments regarding forced backwards compatibility because of binary drivers and their compliance to an ABI (which equates to backwards compatibility of bugs - if an interface had no bugs, it wouldn't ever need to be changed).
Saying that everyone should opensource their drivers is like saying food should be free.
Actually, no, saying that everyone should opensource their drivers is like saying that recipes should be free (as in speech).
We're not expecting vendors to give away their hardware, we just want them to give away the interface to that hardware. Does that open things up for reverse engineering? Possibly, but a reverse-engineered video card probably isn't going to perform as well as the original. It'd definitely be better for the card manufacturer in the long term (which means we need to convince manufacturers that long-term thinking is good), since they would have less load on them for software development, and it'd be better for the Linux community, because we have the hardware specs straight from the horse's mouth, which means we can operate the hardware exactly as the manufacturer intended.
Yes, changing to an open-source model for drivers is a big step, and will cost manufacturers in the short-term, but the long-term benefits are worth it.
As funny as the parent is, it's a sad truth. Most people who look at the open source community don't understand that open-source programming pays the bills for some people. If Neuros wants open-source components for their media player, and want it under a specific timeline, they have a few choices (notice that their current behavior is not listed):
Write it themselves, and open-source it.
Pay someone to write it, and open-source it.
Hope that someone in the software community writes a near-enough piece of software that can be made to work with their media player inside the time frame that they're looking for....(wait for it)
and open-sources it.
For some reason, some people still seem to have the idea that open-source development is free.
Everyone, repeat after me: Open-Source Software does not cost money.
Open-Source Software development does cost money.
Let us not forget, we are NOT COMPRESSING ANYTHING.
We are simply addressing it. By your definition, a filesystem path (e.g./usr/home/SamSim/foo.txt) is compressing the contents of foo.txt to the length of the path.
The better solution is just to disallow any single IP from creating more than, say, 10 URLs in an hour. This would make such a filesystem implementation useless without overly restricting legitimate users.
What about set-ups where a large number of users (say > 1000) are masqueraded behind one IP address?
I don't know if this applies to your boss, but my experience in multiple realms has been this:
The decision-makers regarding raises are non-technical people
All but the lowest tier of management (if you're lucky) are non-technical people
Non-technical management takes no time and expends no effort understanding
the principles of managing technical people and projects
Managers make disgusting mistakes based upon the above ignorances
Rinse and repeat...
The IT department is barely getting by, while IT workers are overworked, and the decision-makers do not believe that they deserve raises for the extra hours of a$$-busting work that
they put in cleaning up their bosses' mistakes, when the entire time, the bosses, and not the IT workers, were the ones causing the screwups
Slashdot Mirror
My lisp is gone!
Does anyone have an example of a potentially dangerous security flaw that was detected and fixed by a software system with no human interaction? I've never heard of it, although I'll gladly have a slice of humble pie if I'm just ignorant.
If I'm right, I suspect an antivirus network like this is extremely likely to zombie-fy the honeypots, and then use them to propagate a back door to every system relying on the antivirus network.
I disagree. If you limit the set of businesses in question to large businesses only, you will find unethical practices. As soon as a business grows large enough, there becomes too much of a separation between the important management decisions and the actual product that the business provides. The shareholder-centered paradigm of any big business contradicts and supersedes almost any initiative to maintain corporate integrity, where Google and a few others are the shining exception. And do note that Google, until recently, was privately owned, even though it was, and still is, a big business, which makes it exceptional for the original "Big Business? Ethical?" question for more than one reason. The phrase, "maximize shareholder profit" is the culprit in almost every big business abandonment of ethical decision-making.
(continuing the shipping analogy kick) what BS is attempting to do is make it legal for certain shipping companies to violate traffic laws to arrive at destinations faster than the competition. Imagine the Fedex truck running the UPS truck off the road, cutting it off in heavy traffic, speeding, and getting pushed to the front of every line at a toll booth or stoplight, while the cops stand by and make sure that the UPS truck bends over and takes every disadvantage right up the tailpipe. This is what BellSouth is suggesting. It probably won't make much of a difference on roads that are wide and have speed limits that are near the maximum speed that the shipping trucks can travel at, but it makes a huge difference on crowded streets or sections of road with low speed limits.
Unfortunately, kiloscads (to borrow and bastardize a term) of other non-ethical big businesses make your anecdotal evidence the exception rather than the rule.
Not quite true. When I did network administration, we had "dynamic ip" (or DHCP for people who know what they're talking about), and I could still track down, to the physical hardware, any IP address. There are two key things in play here that any ISP that intends to cover its ass(ets) should be maintaining:
With these two things, a decent ISP should be able to, with little effort, examine their logs if a legal issue arises, and say where the physical hardware was located (down to the neighborhood, roughly), and determine if the same MAC address is still on their network somewhere. It's not pinpoint accuracy, but it's better than the usual "We haven't got a bloody clue, and we're not liable" story that most ISPs in this situation have given.
A good client does not have a giant SUBMIT button (Everybody knows enter/return sends).
A good client has tabs (Nobody wants a dozen chat windows).
I find these two rather contradictory. I hate, HATE tabbed IM windows, although I love my tabbed browser. Why? Because my browser has tabs based on actions *I* take, whereas new tabs show up in tabbed IM windows based on actions *someone else* takes (potentially). Therefore, if a person initiates a conversation with me, I want to know about it in another way than having to constantly keep checking that particular window for changes, and without bugging my co-workers with the usual cutesy, annoying A-New-Conversation-Has-Begun noise. This is why separate windows are key. Furthermore, while I'm using my multiple-desktop WM, I tend to segregate tasks into different desktops, each with a number of associated IM conversations. How much would it suck to be required to undock a tab from a particular window, only to re-dock it with another window on another desktop just to get it to do what I want it to do? Therefore, the omission of a giant SUBMIT button is contradictory to the idea of tabbed IM windows, since the aforementioned omission is in the interests of keyboard-only operation of the client, whereas tabs almost always force you to use the mouse extensively.
Furthermore, on any number of these tabbed IM windows, any number of messages from any number of users can be received, requiring you to cycle through the windows in the WM, only to cycle through the tabs in the client. I'd rather let my WM be the indicator of the set of conversations that need attention, rather than having a 'two-stage' process that is associated with the use of tabs. So, in response to these two particular items in your list, I say leave the submit button, but make it discreet and non-obnoxious. Heck, you could even let the IM window be skinnable, so that the submit button could be as big, small, or (non)existent as any self-motivated user wants to make it be. And let the 'tabual orientation' of the client be configurable, and OFF by default.
Do you believe that the scope of the research project was intentionally engineered to favor Microsoft Windows? If so, did you make any attempts to expand the scope to be more neutral? What were the results?
How appropriate, "Nothing to see here, please move along." This would be the caption for my mental associations with sony whenever I'm out shopping for Christmas gifts. Sony producing new technology isn't terribly interesting to me if I know they might be installing rootkits on my boxen.
I, for one, believe this to be absolute B.S. If fear of the consequences is the only thing that keeps us in line, we're all screwed. Yes, consequences of bad behavior is a deterrent, but it should be a learning mechanism, not a restraint. Our sense of morality should be the ultimate determining factor in our behavior. If not, we're nothing but rats in cages, responding to stimuli. Most of the moral decisions that I make have nothing to do with perceived consequences; I choose to act a certain way because my moral convictions dictate that I should do so.
But when you consider the Asian per capita income (which, I suspect, would be much less than half the corresponding figure in the US), comparatively, we're producing fewer Ph.D.s than Asia in terms of resource distribution over the entire population. This means the U.S. Ph.D. programs have some combination of the following traits:
Are you suggesting that Asian goods are inferior qulaity to American?
It depends on whether or not you typed that on an Asian keyboard....
8) The user is the one true god and thou shall hold no gods before the user
9) The user is a friggin idiot
And people wonder why programmers are such an "eccentric" bunch....
You could use XML to marshall the objects. It lends itself rather well (if you're careful with how you construct your schema) to dealing with some of the interesting challenges with virtual member functions and variables. It may be overkill in certain situations, but it's probably a simpler way to deal with marshalling than re-working a large object hierarchy so that it contains no virtual functions/variables; i.e. don't reinvent the wheel.
C3PO is the gay one.
Which means R2D2's gaydar is always in tip-top shape, since there's a calibration tool always nearby.
...until the two games are merged such that CoV and CoH are actually *in* the same city.
- Release the hardware specs and let the open-source community maintain the drivers.
- Keep all proprietary don't-want-this-publically-visible code on-board the hardware as firmware (which could possibly overlap with 1. - a developer probably wouldn't know if they're interfacing with direct silicon programming or firmware anyway). I don't have a problem with hardware vendors keeping secrets, as long as they're still friendly to the open-source community while doing so. If the hardware vendor's best features are written in code and not in silicon, I don't believe that the open-source community should steal those features from them. Again, I would expect that hardware vendors would keep certain circuit designs and code proprietary, because that is intellectual property that they are attempting to make money from.
In spite of the usual corporate mindset that is driven by time-to-market, I believe that hardware vendors would benefit from a more open-source-friendly marketing strategy. It would increase the stability and robustness of the system as a whole, and train both Linux developers as well as hardware manufacturers to effectively and consistently hit the moving target of evolving hardware.In response to your particular scenario, one of two things would be true of each bug in the 1.1 version of the hardware: either the new hardware breaks the spec and the old did not, or the old broke the spec and the new does not (in which case the driver was written according to the broken hardware, and not to spec). It is the hardware vendors' responsibility to provide specs for interfacing with the hardware, and it is the software developers' responsibility to write drivers according to that spec. So, the solution to your particular scenario would be that the 1.1 version of the hardware would need a new specification with it (more than likely, since it's a minor version change, presented as a delta from the original spec). If the spec is right, the Linux developers are going to have a good chance (and probably a better chance than most closed-source shops) of creating a robust driver that operates the hardware at the best performance possible.
As for your comments about effort vs. return, this is where understanding the benefit of an open-source-friendly is key. Yes, you're only reaching 5% of the market, but by spending the extra effort for doing so, how much money are you saving over 5 years by having a more successful (read: less buggy) software development model? How much will that 5% section of the market grow in 5 years because you adopted an open-source model? Your assessment of effort vs. return is a bit shallow and short-sighted.
The answer to your "why?" question is this:
As it exists now, the manufacturers are expecting the Linux community to jump through all the hoops. They expect Linux to define an ABI (which includes mystically divining all the hooks that it will need when new hardware types show up), and support that ABI thick-and-thin, no-matter-what. Part of the open-source model is the flexibility it provides when there is a need to abandon the mistakes of the past regarding interfaces. See above for tons of comments regarding forced backwards compatibility because of binary drivers and their compliance to an ABI (which equates to backwards compatibility of bugs - if an interface had no bugs, it wouldn't ever need to be changed).
Saying that everyone should opensource their drivers is like saying food should be free.
Actually, no, saying that everyone should opensource their drivers is like saying that recipes should be free (as in speech).
We're not expecting vendors to give away their hardware, we just want them to give away the interface to that hardware. Does that open things up for reverse engineering? Possibly, but a reverse-engineered video card probably isn't going to perform as well as the original. It'd definitely be better for the card manufacturer in the long term (which means we need to convince manufacturers that long-term thinking is good), since they would have less load on them for software development, and it'd be better for the Linux community, because we have the hardware specs straight from the horse's mouth, which means we can operate the hardware exactly as the manufacturer intended.
Yes, changing to an open-source model for drivers is a big step, and will cost manufacturers in the short-term, but the long-term benefits are worth it.
I'm glad that the Wired article uses the term "hacker" appropriately...
- Write it themselves, and open-source it.
- Pay someone to write it, and open-source it.
- Hope that someone in the software community writes a near-enough piece of software that can be made to work with their media player inside the time frame that they're looking for....(wait for it)
For some reason, some people still seem to have the idea that open-source development is free.and open-sources it.
Everyone, repeat after me:
Open-Source Software does not cost money.
Open-Source Software development does cost money.
I know there are going to be a lot of FreeBSD zealots who will miss Beastie...
Let us not forget, we are NOT COMPRESSING ANYTHING.
/usr/home/SamSim/foo.txt) is compressing the contents of foo.txt to the length of the path.
We are simply addressing it. By your definition, a filesystem path (e.g.
The better solution is just to disallow any single IP from creating more than, say, 10 URLs in an hour. This would make such a filesystem implementation useless without overly restricting legitimate users.
What about set-ups where a large number of users (say > 1000) are masqueraded behind one IP address?