Think about it this way. Which would you rather have fired at you, a solid kinetic penetrator or a nuclear warhead? Any argument about the difficulty of getting the nuke close to the target also applies to any other weapon. If I can't get that nuke within 1 Km of you, or 10 km or 50 km or whatever the kill radius is for a given sized warhead, then I'm sure not going to get a kinetic kill device to make a dead on hit.
I would expect space warfare to be a lot like naval warfare or modern air war. The main trick is not being detected and seeing the enemy first. Then you attack him with relatively stealthy weapons. Those could be heavily cloaked guided weapons with probably nuclear warheads or energy weapons (which are stealthy simply because they hit you before you could possibly detect them).
Unfortunately there are some pretty hard limits on energy weapons. Lasers CAN be effective but besides just the beam divergence caused by diffraction and other limits on columnation there are also internal effects in a high energy density beam which tend to cause the photons to spread. Ranges might be considered fairly limited depending on how good sensor technology is vs stealth. A missile on the other hand can deliver its payload over a virtually unlimited distance.
The other fundamental limit with directed energy weapons is simply the speed of light. You can't easily hit something that can maneuver fast enough to shift its position on average by half the distance of its shortest profile length during the flight time of your weapon. In fact hitting becomes pure luck, its easy to randomize your dodging as a target. The more likely long range use would be you see someone, he doesn't see you, you set up the shot, bam he's dead. Same tactics work potentially for a missile but again it depends on sensor tech.
Dumb kinetic devices have the same problem, except vs an energy weapon its much worse because they're much slower so you have a lot more time to dodge and you might well detect the incoming weapon long before it hits you.
Basically I think the whole thing would be massive amounts of electronic warfare. Both sides would deploy all sorts of decoys, jamming technology, stealth, etc. 99% of battles would amount to one side got the jump on the other and just plain killed them cold. If the enemy tries to defend a fixed location, too bad for him, you don't need to get close at all, just rain bombs on him from a million miles away, nothing he can do about it and sooner or later you get lucky and get a hit or else his perimeter defenses are so good you can't. Then it might devolve down to feints, deception, sabotage, etc.
Anyway straight up pow pow battles with both sides shooting at each other with big firepower seems unlikely. The real thing would be much less romantic and more like 12 years of boredom followed by.396 milliseconds of sheer terror.
And then the value of carbon credits almost immediately collapsed and then collapsed further a couple of years ago. They're worth more as toilet paper than as financial instruments. Besides there is no workable verification or enforcement regime associated with Kyoto. Don't like the cost of carbon credits, just ignore them. Its a truly worthless system and you cannot make any comparison between a carbon credit and a barrel of oil.
Besides. The game is like this. First you're given a carbon credit as an offset for not pumping a barrel of oil out of the ground effectively. 5 years from now when the price of oil is sky high you go ahead and pump it out anyway. Indeed its a win-win situation for the Russians, as long as there's no concerted move to actually stop using oil.
The real basic equation though. I sell oil, therefore I don't like decarbonization, its not in my business interests. Why, besides this, pray tell are all the oil producers and the oil companies the beating heart of denialism? Its pure blind economic self interest and anything those people say is the most highly suspect information there is. Of course the deniers won't take back anything they say based on this when its all proven to be a bunch of Russian lies. No no, they're still pounding on the hockey stick and making defective claims that Darwin Australia's weather station data was monkeyed with even though both claims are trivial and thoroughly disproven.
I really do understand why the guys doing climate science don't want to hear the BS anymore. NO evidence is ever going to convince people who don't want to be convinced. Deniers simply don't want to hear the truth and big oil is happy to cater to them.
Hey, I mean they have an open society where anyone can say what's on their mind right? I mean Glasnost and all, eh?
Or maybe they have a shitload of oil and gas reserves that they'd really rather not have devalued by anyone actually deciding burning more fossil fuels would be suicidally stupid. Oh, was that the sound of one of Vlad's enforcers putting a bullet in the back of someone's head?
Get real people. Now the deniers are the Russians and the Saudis. Laughable what kind of crimes people will do for a buck.
Actually you could use a simpler wiki if you want, I just happen to have started with TWiki way back and its easy for me to maintain, plus it does have a lot of useful plugins. I do a lot of different little software development projects, integration, maintaining various business processes, interfacing with vendors, contractors, and customers, etc.
More formalized ticketing and bug tracking systems are fine when you have a really stable group of people working on software projects, but for a single person managing their own time and projects where every little project is different than every other one and you're just mostly interested in collecting information in one place, keeping track of documentation, making lists, etc. its much easier IMHO to do it in a free-form way with one tool. If for some reason I need some outside visibility into a project or whatever it is possible to set it up. Basically though its a matter of flexibility over power.
I can use it like a notebook, a simple document management system, a to-do list, etc and if a specific activity can benefit from a bit more structure then I can make forms, use various plugins, etc. Its an informal approach but I find that the more structured tools are a bit too rigid. They would probably work better for larger groups but I don't need something that works for a group, I need something that on any given day when I have some slightly oddball little lump of work to deal with I can organize it ad-hoc in the most appropriate way.
I get the feeling the OP is rather in the same boat.
Horavec's formulation works for certain (perfectly spherical) cases of the stress-energy tensor, not in other cases. In fact it produces some wildly inaccurate results in more realistic cases. Nor is he the first to try this kind of thing. Still, it sounds interesting and further refinements could produce a fully consistent theory which can match observation. When and if that happens then it will be a really major advance. It certainly seems like we're edging closer to something.
Well, neither of us can claim to speak for a whole community and I'm sure we can't prove anything one way or another so its just a case of reading the general response. Certainly nothing worth arguing one way or the other.
I'll stick to my stance that its unwise to relax the historical separation between user and admin roles. This is the root reason why Windows has never been terribly secure, they simply cannot disentangle their roles properly. I'm FAR from convinced Linux distros want to march down that path even a tiny bit of the way.
What I mean by my C compiler example is that there are applications that can degrade the security of a machine. C compiler is a common example. Many exploits rely on having a C compiler (its less common these days, but historically it certainly has been true). It has been common practice not to install gcc on things like web servers forever. It shouldn't be installed on desktops unless required either. While it may be true that Fedora DOES install it on all machines that doesn't impact the general argument that a more secure system can be had by not installing many binaries and thus it makes better sense to disallow ad-hoc installation on most systems used for routine work.
Again with DNS resolvers I'm not at all suggesting that the DNS resolver shouldn't be installed. You may have missed the point. I'm stating that there is no one single possible configuration of this component (or MANY other network components) which can be said to be secure or insecure in absence of some security posture to compare it to. Thus you cannot say that the software contained in the FC repos IS properly configured. No proper configuration can exist in a vacuum. Thus I DO NOT want ordinary users installing or upgrading OS components as a general rule. Some of them may not be configured by default in ways that make them adequately secure in the context of my deployment.
I can appreciate too that there is pressure on distributions to make things easy for the single user home desktop system owners, but I think in the long run better security serves them better than letting them avoid a one-time popup.
Ah, yes, well, why not just mention Hitler and lets have the end of the whole discussion.
Actually some of us KNOW a few things about security. In a serious way. I think I'm qualified to have an opinion.
Default Deny has been proven over the years to be the wise postion to take WRT to security settings OOTB. Anyone claiming knowledge of real-world IT security who raises an objection to that position is IMHO not someone who should be in the business of deciding security policies or implementing them. You can scream Nazi all you want, but it isn't a rational way to discuss anything. I'll not only stand behind what I said in my post, I am vindicated by the overwhelming number of people who agree. It appears that in the Linux community there are still a lot of sensible people.
So please, either make an actual argument or just go away.
No, I understand the scope of the issue. I think it could be a potentially more significant problem than your analysis indicates. The majority of systems aren't going to be made insecure by it, and in fact overall security of the system in terms of the possibility of insecure software being installed isn't even necessarily the primary concern. There are simply packages that one would rather not have installed on many classes of systems because they inherently degrade the security posture, for example why should most user desktops have a C compiler installed? Likewise with certain types of plugins, etc. Also it isn't possible to say that a particular component is securely or insecurely configured in absence of a security context in which to evaluate that statement. Its quite possible there are packages which if installed are configured OOTB in a way that is NOT secure within a given context. For example there is no one "secure" configuration for a DNS resolver.
Perhaps a more mundane but likely issue would simply be the case where the admin desires to keep the configuration of the machine overall, and what software is available, controlled to some greater or lesser degree. It is best if that control by default is fairly restrictive. Its a lot easier and safer to relax a security policy than it is to have it be overly lax by default and expect less than expert admins (probably the vast majority of Linux admins) to know to change policies.
It just wasn't the best default policy apparently that FC12 ended up with, at least in the opinions of what appears to be a vast majority of anyone that actually noticed.
Cool. I'm sure a lot of people have trouble appreciating the sheer complexity of coordinating things. Managing a large software product composed of many components is always challenging, especially if they source from so many different places. I think security is just one of those hot-button issues that raises a lot of hackles. Without knowing in detail how all the different responsibilities are divided up within the whole project and how these kinds of issues get communicated it isn't easy to know how any particular decision ends up being made.
Well, I don't know, but the RESULT is what most people get to judge by. The result was a pretty significant change in behavior that seems to have hit most users of FC kind of out of left field. Maybe the whole issue isn't specific to Fedora but it points out that some level of visibility of the consequences of changes, upstream or not, doesn't exist. From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through. Obviously they seriously misjudged what the wider community's desires were. These things happen, but in the security arena they probably shouldn't happen. I don't know what the fix is, but there needs to be some analysis within the team and I suspect the answer is going to be what should have been the obvious answer, don't step on the traditional security policy principles that have existed as expectations within the Linux community since the earliest days.
It will be interesting to see what the ultimate response is in terms of process. Hopefully it will stimulate some creative thinking.
I think it is a bad direction to go in with security policy in general.
Sure, the desktop user can shutdown the machine, etc. The issue is that the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. In fact its pretty easy to do and certainly anyone knowledgeable enough to be authoring exploits will know how to do that.
There are some other ways in which I just disagree with the team's position on this. They argue that its better to "not train user's to click on things" but doing that by simply essentially making the default for everything "OK, do the dangerous thing" is not an answer! Maybe there is no answer, but popping up a dialog or showing a prompt and requiring a password is SOMETHING at least. It can't possibly be worse.
They say that they don't like the concept of each user's policy management being essentially scattered to the four winds in the form of whatever dialog's happen to come up here and there, but centralizing it into one unified policy manager isn't better. Normal users, and even fairly advanced users in a lot of cases, have no idea what the settings in such a manager mean because they aren't presented with any sort of context. At least when a dialog pops up the user is aware of the context within which the decision is being made. Nothing will ever force users to make good decisions or even informed decisions, but some control panel they will never find and if they do find it is just a big list of dry explanations and check boxes is not better. Sure, that manager needs to exist, but as the sole way to access that stuff its not a good design.
There may be no perfect way for things to work, but reducing the level of security to triviality is patently less desirable than not doing that. That the Fedora team could even entertain any other opinion seriously undermines my confidence in their ability to make good security decisions overall.
The whole Fedora Team's creation of and response to this issue creates very serious doubt in my mind about their ability to manage a distribution and their understanding of proper security policy. I think they've got to open up their decision making process more and learn to communicate better. An idea this bad should have been squashed 5 minutes after it was proposed instead of being allowed to actually make it into a released distribution.
At least it all shows that the community still ultimately calls the shots.
Sure. I think Winooski was just not quite the place with the means to do all of that. Its not a rich town. It just happens to be a very geographically small area with a reasonably high density (well, for Vermont anyway, plenty of suburbs in the US that are probably at least as good a place to start).
I think the view in Winooski was pretty much "This is pretty newfangled". Its really a pretty blue collar kind of place. I don't recall exactly what they claimed it would cost, but its safe to say in Winooski terms its "a really huge amount of money" (it isn't exactly a rich town). Maybe somebody like the Feds aught to do the big experiment. People around here thought it was an interesting idea, just a little high risk.
Given that I actually live about 5 miles from where the whole Winooski Dome was planned to go this is all pretty well trodden territory here in this part of Vermont. The real killer problems are twofold. One is just that nobody has ever done it before and who wants to be first? In theory its a great idea, but its always the problem you didn't consider that bites you in the end. The second and more practical problem was always snow load. As anyone that has lived in Vermont can tell you, we get plenty of snow. Now pile it up a few feet deep on top of that dome, it adds up real fast. Nobody was ever sure exactly what would happen with all that snow or how long it would stay up there, etc. Roofs regularly collapse around here from snow load. You REALLY don't want to have that happen to your dome. That brings up what was the real final issue. What happens if something goes wrong? Its not just like you wasted a bunch of money. Having that dome come down on top of a whole town? That would be a big mess indeed...
Basically if the concept is ever going anywhere someone needs to build one way out in the middle of nowhere and figure out the basic problems first. Winooski residents wisely decided that being guinea pigs maybe isn't such a great idea.
Yet it appears that about 90% of the people developing web apps are entirely sans-clue on the whole subject. Most of these apps I suspect never have ANY real design applied to them anyway, just ad-hoc stuff that starts from at best some templating system.
Ah well, I shouldn't complain. I get to go in and clean up the mess (IE tell them what they have is probably worthless) and get paid for it.
And if you aren't using a webapp framework which deals with this kind of thing transparently to application business logic, then you need a better framework.
Seriously, look into things like JBoss SEAM. I'm not suggesting that any particular core technology is the preferred choice, but that happens to be one which provides a fairly nice implementation of the concept.
Again in J2EE land, the concept is also more directly supported by EJB3 configurations using optimistic locking (the technical term for checking a counter/datestamp when a record to saved). Entity beans attached to an EntityManager which is configured for optlocking will handle the whole process transparently. If a stale record gets persisted, you'll get an appropriate exception at the SSB (application logic) layer and you can take whatever action you need to in the UI.
These are the kinds of reasons everyone should be using well designed frameworks instead of hacking together any non-trivial webapps on their own. It looks easy, until you start to get into the details.
My point is perfectly cogent. Motivation in the context we're discussing here is an aspect of human character. Certainly if we could reproduce something essentially like a human mind in some artificial form, then we could talk about motivation in some meaningful sense. However when we are talking about something built for a purpose then we're talking about essentially a technological artifact. It is built to a purpose. Certainly it has to built in such a way as to serve that purpose, but the fact that we HAVE the thing presupposes it can meet the purpose for which it is designed.
A technical discussion of the means by which a specific AI would be designed in order to meet its purpose is one thing, some kind of philosophical maunderings about "motivation" of such a technical artifact is no more meaningful than wondering how we get our automobile to want to drive down the road. Its simply not a useful way of looking at the problem. You build an automobile which DOES drive down the road. Motivation doesn't enter into it. The discussion would be about how engines, drive trains, etc work.
So when someone has advanced the technology of AI to the point where we even have the equivalent of engines and drive trains to talk about, then we can have a meaningful discussion about how its all put together into a functional package. However note that we also would require specific criteria for evaluating our AI in terms of what we want it to do (IE a specification).
One of the major problems with the whole field of AI up to now has been a propensity to think about the problem in terms of philosophical concepts like free will. Its an engineering problem. No doubt philosophers have explored thought, reason, knowledge representation, etc and some of that work can be relevant to AI, but the fact is an AI will be a human artifact, no more or less so than a hammer or a wheel. Albeit a complex one, but yet still fundamentally in the same class.
This whole line of reasoning is based on some sort of anthropomorphization of a putative AI. Why would it behave anything like a human being? Why would it even have a mental architecture similar to ours at all? Presumably it will be built for some kind of purpose. Just like any piece of equipment it will be designed to fulfill that particular purpose. If it fails to function properly then its just like any other machine that doesn't work correctly.
Does the wheel of your car have "motivation" to go round and round?
For that matter if you actually look a bit too closely the whole concept of "motivation" goes up in a puff of smoke. Humans are simply survival machines. The end result of 4.5 billion years, give or take, of evolution. What is our "motivation"? We simply do what we do. If that isn't surviving then we aren't around anymore to question the value of it.
Ummm, where do people get this kind of weird misinformation from?
Program (black box) trading is not at all illegal. There are certain rules put in place by NYSE and NASDAQ to allow them to control program trading activities to some extent, plus post-trade reporting (OTS/OATS phase III) which tracks trading activity. The upshot is in the stock market it is regulated slightly differently from other types of trading. In other markets there are generally no restrictions of any kind.
As far as how these guys get speed, well, you'd have pretty high speed too if you had 100's of millions worth of hardware sitting co-located in racks right next to ARCA and NASDAQ and connected to them via Infiniband, hehe. These things are built to reduce latencies down into the low microseconds. There are smaller firms out there (I should know) but they're not able to directly compete with the big guys. Only a few players do the sort of stuff Goldman does.
Nobody is putting down Opera. It is still a very small percentage of desktop users. The question is, is 4% market share, to use your number, significant enough to drive adoption?
No doubt the people using Opera can take advantage of Unite, but IMHO it isn't enough to just have some widgets and applications that people use in lieu of hosting stuff someplace. That isn't revolutionary. It would be revolutionary if a large enough percentage of people had a facility that would allow fairly easy and straightforward development of applications using HTTP, HTML, and Javascript that were capable of full duplex communications. THAT would enable a whole new generations of applications that cannot be built using web technologies now. It requires a lot more than 4% market share before that will be at all tempting to developers.
It COULD be tempting in the mobile market where Opera has a much bigger market share, but that also supposes people have a wireless service which is capable of supporting it, and phones that can support it, and that the phone vendors and service providers will bite. None of those things are at all assured.
Regardless of whether or not we were to think Opera is the best browser out there, the best software is clearly not enough to win in the market. If it was then things would look much different than they do now in the software world. Experience tells me that the quality of your technology is only one small factor.
Slashdot Mirror
Think about it this way. Which would you rather have fired at you, a solid kinetic penetrator or a nuclear warhead? Any argument about the difficulty of getting the nuke close to the target also applies to any other weapon. If I can't get that nuke within 1 Km of you, or 10 km or 50 km or whatever the kill radius is for a given sized warhead, then I'm sure not going to get a kinetic kill device to make a dead on hit.
I would expect space warfare to be a lot like naval warfare or modern air war. The main trick is not being detected and seeing the enemy first. Then you attack him with relatively stealthy weapons. Those could be heavily cloaked guided weapons with probably nuclear warheads or energy weapons (which are stealthy simply because they hit you before you could possibly detect them).
Unfortunately there are some pretty hard limits on energy weapons. Lasers CAN be effective but besides just the beam divergence caused by diffraction and other limits on columnation there are also internal effects in a high energy density beam which tend to cause the photons to spread. Ranges might be considered fairly limited depending on how good sensor technology is vs stealth. A missile on the other hand can deliver its payload over a virtually unlimited distance.
The other fundamental limit with directed energy weapons is simply the speed of light. You can't easily hit something that can maneuver fast enough to shift its position on average by half the distance of its shortest profile length during the flight time of your weapon. In fact hitting becomes pure luck, its easy to randomize your dodging as a target. The more likely long range use would be you see someone, he doesn't see you, you set up the shot, bam he's dead. Same tactics work potentially for a missile but again it depends on sensor tech.
Dumb kinetic devices have the same problem, except vs an energy weapon its much worse because they're much slower so you have a lot more time to dodge and you might well detect the incoming weapon long before it hits you.
Basically I think the whole thing would be massive amounts of electronic warfare. Both sides would deploy all sorts of decoys, jamming technology, stealth, etc. 99% of battles would amount to one side got the jump on the other and just plain killed them cold. If the enemy tries to defend a fixed location, too bad for him, you don't need to get close at all, just rain bombs on him from a million miles away, nothing he can do about it and sooner or later you get lucky and get a hit or else his perimeter defenses are so good you can't. Then it might devolve down to feints, deception, sabotage, etc.
Anyway straight up pow pow battles with both sides shooting at each other with big firepower seems unlikely. The real thing would be much less romantic and more like 12 years of boredom followed by .396 milliseconds of sheer terror.
And then the value of carbon credits almost immediately collapsed and then collapsed further a couple of years ago. They're worth more as toilet paper than as financial instruments. Besides there is no workable verification or enforcement regime associated with Kyoto. Don't like the cost of carbon credits, just ignore them. Its a truly worthless system and you cannot make any comparison between a carbon credit and a barrel of oil.
Besides. The game is like this. First you're given a carbon credit as an offset for not pumping a barrel of oil out of the ground effectively. 5 years from now when the price of oil is sky high you go ahead and pump it out anyway. Indeed its a win-win situation for the Russians, as long as there's no concerted move to actually stop using oil.
The real basic equation though. I sell oil, therefore I don't like decarbonization, its not in my business interests. Why, besides this, pray tell are all the oil producers and the oil companies the beating heart of denialism? Its pure blind economic self interest and anything those people say is the most highly suspect information there is. Of course the deniers won't take back anything they say based on this when its all proven to be a bunch of Russian lies. No no, they're still pounding on the hockey stick and making defective claims that Darwin Australia's weather station data was monkeyed with even though both claims are trivial and thoroughly disproven.
I really do understand why the guys doing climate science don't want to hear the BS anymore. NO evidence is ever going to convince people who don't want to be convinced. Deniers simply don't want to hear the truth and big oil is happy to cater to them.
Hey, I mean they have an open society where anyone can say what's on their mind right? I mean Glasnost and all, eh?
Or maybe they have a shitload of oil and gas reserves that they'd really rather not have devalued by anyone actually deciding burning more fossil fuels would be suicidally stupid. Oh, was that the sound of one of Vlad's enforcers putting a bullet in the back of someone's head?
Get real people. Now the deniers are the Russians and the Saudis. Laughable what kind of crimes people will do for a buck.
Actually you could use a simpler wiki if you want, I just happen to have started with TWiki way back and its easy for me to maintain, plus it does have a lot of useful plugins. I do a lot of different little software development projects, integration, maintaining various business processes, interfacing with vendors, contractors, and customers, etc.
More formalized ticketing and bug tracking systems are fine when you have a really stable group of people working on software projects, but for a single person managing their own time and projects where every little project is different than every other one and you're just mostly interested in collecting information in one place, keeping track of documentation, making lists, etc. its much easier IMHO to do it in a free-form way with one tool. If for some reason I need some outside visibility into a project or whatever it is possible to set it up. Basically though its a matter of flexibility over power.
I can use it like a notebook, a simple document management system, a to-do list, etc and if a specific activity can benefit from a bit more structure then I can make forms, use various plugins, etc. Its an informal approach but I find that the more structured tools are a bit too rigid. They would probably work better for larger groups but I don't need something that works for a group, I need something that on any given day when I have some slightly oddball little lump of work to deal with I can organize it ad-hoc in the most appropriate way.
I get the feeling the OP is rather in the same boat.
Wow, the future was never like this in my dreams! ;)
Something like that, yeah. It works great for say a perfectly round non-rotating Earth. Not so good for the real Earth... Could be fixable apparently.
Horavec's formulation works for certain (perfectly spherical) cases of the stress-energy tensor, not in other cases. In fact it produces some wildly inaccurate results in more realistic cases. Nor is he the first to try this kind of thing. Still, it sounds interesting and further refinements could produce a fully consistent theory which can match observation. When and if that happens then it will be a really major advance. It certainly seems like we're edging closer to something.
Well, neither of us can claim to speak for a whole community and I'm sure we can't prove anything one way or another so its just a case of reading the general response. Certainly nothing worth arguing one way or the other.
I'll stick to my stance that its unwise to relax the historical separation between user and admin roles. This is the root reason why Windows has never been terribly secure, they simply cannot disentangle their roles properly. I'm FAR from convinced Linux distros want to march down that path even a tiny bit of the way.
What I mean by my C compiler example is that there are applications that can degrade the security of a machine. C compiler is a common example. Many exploits rely on having a C compiler (its less common these days, but historically it certainly has been true). It has been common practice not to install gcc on things like web servers forever. It shouldn't be installed on desktops unless required either. While it may be true that Fedora DOES install it on all machines that doesn't impact the general argument that a more secure system can be had by not installing many binaries and thus it makes better sense to disallow ad-hoc installation on most systems used for routine work.
Again with DNS resolvers I'm not at all suggesting that the DNS resolver shouldn't be installed. You may have missed the point. I'm stating that there is no one single possible configuration of this component (or MANY other network components) which can be said to be secure or insecure in absence of some security posture to compare it to. Thus you cannot say that the software contained in the FC repos IS properly configured. No proper configuration can exist in a vacuum. Thus I DO NOT want ordinary users installing or upgrading OS components as a general rule. Some of them may not be configured by default in ways that make them adequately secure in the context of my deployment.
I can appreciate too that there is pressure on distributions to make things easy for the single user home desktop system owners, but I think in the long run better security serves them better than letting them avoid a one-time popup.
Ah, yes, well, why not just mention Hitler and lets have the end of the whole discussion.
Actually some of us KNOW a few things about security. In a serious way. I think I'm qualified to have an opinion.
Default Deny has been proven over the years to be the wise postion to take WRT to security settings OOTB. Anyone claiming knowledge of real-world IT security who raises an objection to that position is IMHO not someone who should be in the business of deciding security policies or implementing them. You can scream Nazi all you want, but it isn't a rational way to discuss anything. I'll not only stand behind what I said in my post, I am vindicated by the overwhelming number of people who agree. It appears that in the Linux community there are still a lot of sensible people.
So please, either make an actual argument or just go away.
No, I understand the scope of the issue. I think it could be a potentially more significant problem than your analysis indicates. The majority of systems aren't going to be made insecure by it, and in fact overall security of the system in terms of the possibility of insecure software being installed isn't even necessarily the primary concern. There are simply packages that one would rather not have installed on many classes of systems because they inherently degrade the security posture, for example why should most user desktops have a C compiler installed? Likewise with certain types of plugins, etc. Also it isn't possible to say that a particular component is securely or insecurely configured in absence of a security context in which to evaluate that statement. Its quite possible there are packages which if installed are configured OOTB in a way that is NOT secure within a given context. For example there is no one "secure" configuration for a DNS resolver.
Perhaps a more mundane but likely issue would simply be the case where the admin desires to keep the configuration of the machine overall, and what software is available, controlled to some greater or lesser degree. It is best if that control by default is fairly restrictive. Its a lot easier and safer to relax a security policy than it is to have it be overly lax by default and expect less than expert admins (probably the vast majority of Linux admins) to know to change policies.
It just wasn't the best default policy apparently that FC12 ended up with, at least in the opinions of what appears to be a vast majority of anyone that actually noticed.
Cool. I'm sure a lot of people have trouble appreciating the sheer complexity of coordinating things. Managing a large software product composed of many components is always challenging, especially if they source from so many different places. I think security is just one of those hot-button issues that raises a lot of hackles. Without knowing in detail how all the different responsibilities are divided up within the whole project and how these kinds of issues get communicated it isn't easy to know how any particular decision ends up being made.
Well, I don't know, but the RESULT is what most people get to judge by. The result was a pretty significant change in behavior that seems to have hit most users of FC kind of out of left field. Maybe the whole issue isn't specific to Fedora but it points out that some level of visibility of the consequences of changes, upstream or not, doesn't exist. From looking at the chatter on the mailing list it seems to me that people on the 'inside' were aware of the ramifications of the change and let it go through. Obviously they seriously misjudged what the wider community's desires were. These things happen, but in the security arena they probably shouldn't happen. I don't know what the fix is, but there needs to be some analysis within the team and I suspect the answer is going to be what should have been the obvious answer, don't step on the traditional security policy principles that have existed as expectations within the Linux community since the earliest days.
It will be interesting to see what the ultimate response is in terms of process. Hopefully it will stimulate some creative thinking.
I think it is a bad direction to go in with security policy in general.
Sure, the desktop user can shutdown the machine, etc. The issue is that the default packageKit no-password setup is a recipe for non-technical users to potentially blow their own left foot off. 99% of what one would like to guard against is simply accidental damage to the system. The other issue is once you have such a passwordless system in place someone will easily find a way to exploit it. In fact its pretty easy to do and certainly anyone knowledgeable enough to be authoring exploits will know how to do that.
There are some other ways in which I just disagree with the team's position on this. They argue that its better to "not train user's to click on things" but doing that by simply essentially making the default for everything "OK, do the dangerous thing" is not an answer! Maybe there is no answer, but popping up a dialog or showing a prompt and requiring a password is SOMETHING at least. It can't possibly be worse.
They say that they don't like the concept of each user's policy management being essentially scattered to the four winds in the form of whatever dialog's happen to come up here and there, but centralizing it into one unified policy manager isn't better. Normal users, and even fairly advanced users in a lot of cases, have no idea what the settings in such a manager mean because they aren't presented with any sort of context. At least when a dialog pops up the user is aware of the context within which the decision is being made. Nothing will ever force users to make good decisions or even informed decisions, but some control panel they will never find and if they do find it is just a big list of dry explanations and check boxes is not better. Sure, that manager needs to exist, but as the sole way to access that stuff its not a good design.
There may be no perfect way for things to work, but reducing the level of security to triviality is patently less desirable than not doing that. That the Fedora team could even entertain any other opinion seriously undermines my confidence in their ability to make good security decisions overall.
The whole Fedora Team's creation of and response to this issue creates very serious doubt in my mind about their ability to manage a distribution and their understanding of proper security policy. I think they've got to open up their decision making process more and learn to communicate better. An idea this bad should have been squashed 5 minutes after it was proposed instead of being allowed to actually make it into a released distribution.
At least it all shows that the community still ultimately calls the shots.
effectively. This is called progress...
Sure. I think Winooski was just not quite the place with the means to do all of that. Its not a rich town. It just happens to be a very geographically small area with a reasonably high density (well, for Vermont anyway, plenty of suburbs in the US that are probably at least as good a place to start).
I think the view in Winooski was pretty much "This is pretty newfangled". Its really a pretty blue collar kind of place. I don't recall exactly what they claimed it would cost, but its safe to say in Winooski terms its "a really huge amount of money" (it isn't exactly a rich town). Maybe somebody like the Feds aught to do the big experiment. People around here thought it was an interesting idea, just a little high risk.
Given that I actually live about 5 miles from where the whole Winooski Dome was planned to go this is all pretty well trodden territory here in this part of Vermont. The real killer problems are twofold. One is just that nobody has ever done it before and who wants to be first? In theory its a great idea, but its always the problem you didn't consider that bites you in the end. The second and more practical problem was always snow load. As anyone that has lived in Vermont can tell you, we get plenty of snow. Now pile it up a few feet deep on top of that dome, it adds up real fast. Nobody was ever sure exactly what would happen with all that snow or how long it would stay up there, etc. Roofs regularly collapse around here from snow load. You REALLY don't want to have that happen to your dome. That brings up what was the real final issue. What happens if something goes wrong? Its not just like you wasted a bunch of money. Having that dome come down on top of a whole town? That would be a big mess indeed...
Basically if the concept is ever going anywhere someone needs to build one way out in the middle of nowhere and figure out the basic problems first. Winooski residents wisely decided that being guinea pigs maybe isn't such a great idea.
Yet it appears that about 90% of the people developing web apps are entirely sans-clue on the whole subject. Most of these apps I suspect never have ANY real design applied to them anyway, just ad-hoc stuff that starts from at best some templating system.
Ah well, I shouldn't complain. I get to go in and clean up the mess (IE tell them what they have is probably worthless) and get paid for it.
And if you aren't using a webapp framework which deals with this kind of thing transparently to application business logic, then you need a better framework.
Seriously, look into things like JBoss SEAM. I'm not suggesting that any particular core technology is the preferred choice, but that happens to be one which provides a fairly nice implementation of the concept.
Again in J2EE land, the concept is also more directly supported by EJB3 configurations using optimistic locking (the technical term for checking a counter/datestamp when a record to saved). Entity beans attached to an EntityManager which is configured for optlocking will handle the whole process transparently. If a stale record gets persisted, you'll get an appropriate exception at the SSB (application logic) layer and you can take whatever action you need to in the UI.
These are the kinds of reasons everyone should be using well designed frameworks instead of hacking together any non-trivial webapps on their own. It looks easy, until you start to get into the details.
Spare me the thoughtless ad hominum eh?
My point is perfectly cogent. Motivation in the context we're discussing here is an aspect of human character. Certainly if we could reproduce something essentially like a human mind in some artificial form, then we could talk about motivation in some meaningful sense. However when we are talking about something built for a purpose then we're talking about essentially a technological artifact. It is built to a purpose. Certainly it has to built in such a way as to serve that purpose, but the fact that we HAVE the thing presupposes it can meet the purpose for which it is designed.
A technical discussion of the means by which a specific AI would be designed in order to meet its purpose is one thing, some kind of philosophical maunderings about "motivation" of such a technical artifact is no more meaningful than wondering how we get our automobile to want to drive down the road. Its simply not a useful way of looking at the problem. You build an automobile which DOES drive down the road. Motivation doesn't enter into it. The discussion would be about how engines, drive trains, etc work.
So when someone has advanced the technology of AI to the point where we even have the equivalent of engines and drive trains to talk about, then we can have a meaningful discussion about how its all put together into a functional package. However note that we also would require specific criteria for evaluating our AI in terms of what we want it to do (IE a specification).
One of the major problems with the whole field of AI up to now has been a propensity to think about the problem in terms of philosophical concepts like free will. Its an engineering problem. No doubt philosophers have explored thought, reason, knowledge representation, etc and some of that work can be relevant to AI, but the fact is an AI will be a human artifact, no more or less so than a hammer or a wheel. Albeit a complex one, but yet still fundamentally in the same class.
This whole line of reasoning is based on some sort of anthropomorphization of a putative AI. Why would it behave anything like a human being? Why would it even have a mental architecture similar to ours at all? Presumably it will be built for some kind of purpose. Just like any piece of equipment it will be designed to fulfill that particular purpose. If it fails to function properly then its just like any other machine that doesn't work correctly.
Does the wheel of your car have "motivation" to go round and round?
For that matter if you actually look a bit too closely the whole concept of "motivation" goes up in a puff of smoke. Humans are simply survival machines. The end result of 4.5 billion years, give or take, of evolution. What is our "motivation"? We simply do what we do. If that isn't surviving then we aren't around anymore to question the value of it.
Ummm, where do people get this kind of weird misinformation from?
Program (black box) trading is not at all illegal. There are certain rules put in place by NYSE and NASDAQ to allow them to control program trading activities to some extent, plus post-trade reporting (OTS/OATS phase III) which tracks trading activity. The upshot is in the stock market it is regulated slightly differently from other types of trading. In other markets there are generally no restrictions of any kind.
As far as how these guys get speed, well, you'd have pretty high speed too if you had 100's of millions worth of hardware sitting co-located in racks right next to ARCA and NASDAQ and connected to them via Infiniband, hehe. These things are built to reduce latencies down into the low microseconds. There are smaller firms out there (I should know) but they're not able to directly compete with the big guys. Only a few players do the sort of stuff Goldman does.
Nobody is putting down Opera. It is still a very small percentage of desktop users. The question is, is 4% market share, to use your number, significant enough to drive adoption?
No doubt the people using Opera can take advantage of Unite, but IMHO it isn't enough to just have some widgets and applications that people use in lieu of hosting stuff someplace. That isn't revolutionary. It would be revolutionary if a large enough percentage of people had a facility that would allow fairly easy and straightforward development of applications using HTTP, HTML, and Javascript that were capable of full duplex communications. THAT would enable a whole new generations of applications that cannot be built using web technologies now. It requires a lot more than 4% market share before that will be at all tempting to developers.
It COULD be tempting in the mobile market where Opera has a much bigger market share, but that also supposes people have a wireless service which is capable of supporting it, and phones that can support it, and that the phone vendors and service providers will bite. None of those things are at all assured.
Regardless of whether or not we were to think Opera is the best browser out there, the best software is clearly not enough to win in the market. If it was then things would look much different than they do now in the software world. Experience tells me that the quality of your technology is only one small factor.