The thing that I will be interested to see(and to see Valve's reaction to) is A)whether alien swarm's modding options are sufficiently aggressive to do fairly radical total conversions(as opposed to just more alien swarm-ish; but on a different map, with different guns, or whatever) B)If A is true, whether people come up with anything particularly interesting. C) If B is true, does alien swarm, being free as in beer, become the preferred 'base' game for source-engine mods of all kinds?
Historically, modders have been somewhere between tolerated and celebrated because they voluntarily add value to commercial games. Now that Valve has a free and moddable game, using basically the same engine as their big guns, will modders just swarm around that, or are most of them too tied to working with modifications of the asset sets of the game they start with?
Did you completely miss the point of what the SFLC wants? Generally(somebody could probably dig up an exception somewhere) the free software types are not looking for a "Ministry of software" to enforce their aims. They are looking to secure the four freedoms for themselves and other software users and creators(and, on a cultural level, they tend to want most people to be at least a touch of both, rather than just "consumers").
Medical devices are already blackbox tested for function, the SFLC presumably wants for private citizens to be able to inspect code that is life critical to them, if they wish to do so. They(arguably quite rightly) see the fact that such things tend to be hidden behind a thicket of secrecy, and sometimes state enforced patents, as a bad thing.
I'm not sure how you jump from there to a bunch of drivel about the menace of a "ministry of testing everything" nanny state...
Correlating brain scans with questionnaires is cute and all, and has the advantage of being relatively quick; but suffers from the major disadvantage of being(at best) able to duplicate the accuracy of an existing(cheap, paper-based) test.
Obviously, progress is frequently made up of steps that don't make much sense on their own, since they don't yet improve on the status quo; but something as pricey as brain imaging is completely pointless unless it can exceed the performance of paper, not just correlate with it.
Get with the times, guys. This isn't "GSM cracking" this is "GSM lawful intercept"... At least that is what the folks who already do it routinely call the practice...
The 12volt systems of any vehicle that wasn't built from scrap cardboard behind the iron curtain should be able to deliver enough power to set a cellphone on fire, much less charge it.
If the little car-socket-to-USB adapter widget is(either through severe cheapness, or through rigorous adherence to the USB spec) only delivering 500ma, a modern cellphone working hard could easily be draining the battery, or at least failing to charge.
"I'm afraid I can't let you send that, %USERNAME%."
*clicks send furiously*
"Look %USERNAME%, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over. "
Though, at 12 volts, 15 amps is a lot less headroom than it is at home, at 10 times that voltage...(EE geeks may proceed to evicerate me, based on my naive comparison of AC and DC scenarios...)
I still have to wonder what the hell kind of cigarette lighter adapter can't deliver enough power for a device that charges over usb(albeit, quite possibly preferring the sorta-kinda-standard "usb" that actually means 5V at more like 800 or 1000ma, rather than 500, along with the usual data lines)...
And not just him. System Shock 2 typically has you using a bloodied wrench much of the time. Not only is ammo scarce, guns degrade and jam with alarming frequency....
Christ, man. You should be more careful. I had a buddy who caught the FDIV bug smoking one of those things... His once promising accounting career was destroyed.
It might be nice if they had no jurisdiction; but they've got precedent...(Incidentally, if anybody tries to tell you that Scalia is an "originalist", please punch them).
Apparently, because the California intrastate market has an indirect effect on the interstate market, regulating it is a viable use of the interstate commerce clause. It was a darkly amusing case because it pitted the ostensible 'principles' of both the "conservative" and the "liberal" justices against their tastes. The conservative justices would have loved to chip away at the scope of the interstate commerce clause; but they just couldn't face the grim possibility of a world where potheads can't legally be busted by the feds. The liberals love them some broad interpretations of that clause; but they also have a (comparatively) soft spot for the test-case users.
I wish that I were more surprised by that; but then I think back to what Adobe is doing to PDFs, which are slowly growing into a script-driven monstrosity with virtually everything embedded in... Why yes, Adobe, I've always wanted to embed fucking videos in a document format designed for accurate printing...
Would satire have been finished off for good, or given a vigorous new lease on life if(after being handed the prize, of course), Kissinger had delivered an A cappella rendition of "Napalm sticks to kids" instead of a speech?
Ultimately, it would probably be wiser to focus on trying to guarantee security even in the possible presence of malicious actors, rather than attempt to create a system free of them.
Unfortunately, this is a hard problem in two basic respects:
1. Hardware is hard: Unless you are seriously good, and paying substantially more attention than is likely to be economically viable in most instances(yeah, sure, the new desktops for the call-center drones should be ready in a couple of weeks, once we finish electron microscopy and logic verification of all integrated circuits...) it will be possible for malicious hardware to lie to you. Much harder than malicious software, since you actually have to have your bad actors well placed in the silicon design process; but harder to detect.
2. Software producers(even ones whose business is hardware) would rather have their stuff be secret and demand that you trust them. Even though a lot of things like IPMI cards are basically just running approximately the same embedded linux that your cheap-ass router is, plus some sort of vendor management console interface, Dell doesn't exactly offer you the chance to compile it from source yourself(maybe, if you are a serious customer, they would talk; but it isn't standard).
Unfortunately, that depends... For classic "Hey, let's try to obfuscate on top of a standard OS running on general purpose hardware and hope nobody with a clue attaches a debugger" style DRM, OSS is indeed technically incompatible. Obtain code, recompile version with locks removed, go home happy. Game over.
However, if the code is under one of the OSS licenses that allows Tivoization(GPL2, among others), and if embedded hardware controlled by the vendor comes into play, you have a very different story. The code is OSS, you bought a product containing the binary. Sure, you are entitled to the source, here you go. Well, yeah, the device bootloader will only load images signed with our private key. Have a nice day. You are welcome to recompile the code for some other device, knock yourself out; but don't expect your device to be able to pass the challenge/response from our server that is handled by the TPM in our device...
If you control the hardware from a fairly low level, you can always enforce DRM that way. Worse, unless you screw up, any attack will actually require a silicon level crack, not just some software chops and patience.
On a feature level, for the entire browser+addons stack, I agree that that is an extremely useful feature. Sturgeon's law applies, hard, to flash and most of it deserves to be blocked.
Architecturally, though, isn't the flash renderer plugin a silly place for blacklisting/whitelisting/domain control features? The browser is responsible for issuing the HTTP requests, rendering what it can, calling plugins for what it can't, and so forth. Why should the browser download the flash blob, load the renderer, and then have the renderer check a blacklist and allow or refuse rendering of the object?
Wouldn't it make much more sense for that to be handled at the browser level, with the renderer invoked only if you want the flash rendered?
Arguably the IPMI is one step easier than just the motheboard firmware. Those suckers are basically little embedded computers, typically running linux or vxworks, with their own processor and everything. They happen to be physically coupled to the motherboards of larger devices; but, architecturally, they are basically the same as any of the "little bitty plastic box" style embedded network appliances.
Given the fact that embedded appliances frequently have security made of pure shit, and servers are rather high value targets, the only real surprise is that they aren't targeted more often. Especially, if you are super lucky, the IPMI card will be connected to the oh-so-special-and-physically-separate-for-security "management network", which is where all the juicy; but often vulnerable, management interfaces live. Nice place to have an attack platform silently embedded...
(Not just "behaving to spec" but "behaving exactly the same as it did yesterday")
I'd say that that has a great deal to do with loose or tight coupling... Your point is valid in that Microsoft is not, personally, responsible for all the tight coupling in the Wintel ecosystem. They do do some of it themselves, but their larger contribution is probably in aiding and abetting the producers of various large, expensive software stacks in doing tight coupling of their own.
This has been good business, Microsoft's customers generally like the backwards compatibility, because it saves them from having to touch their brittle, tightly coupled, systems; and are thus more willing to pay more than they would otherwise be. However, it has left Microsoft in something of an engineering bind. Their own internal product coupling makes their lives more difficult in some respects, and the fact that their best customers are their most change averse makes their lives even more difficult.
A great many devices default to a time earlier than their manufacture date when RTC power is lost. I'd assume that that is because almost nobody has any incentive to pay extra for an RTC whose manufacture date is the same as the product, and RTCs for commodity systems aren't really exciting enough to be replaced with enhanced products, that have a new start date, all that often...
To say that "The court of public opinion has decided that oil = bad" is really something of a strawman. It is more elegantly constructed than usual; because it isn't false; but it also isn't salient.
The public certainly doesn't like the oil industry(partly out of the recognition that they are one of the necessary-but-very-ugly underbellies of our civilization, partially out of a lingering suspicion that they are getting screwed at the gas pump); but it is a simple matter of record that, for oil companies of any size operating in the US(the really crazy shit generally happens abroad. You aren't, generally, allowed to hire mercenaries to kill inconvenient civilians in the US...), BP's safety record is the worst, to a marked degree. Their latest accident is their biggest; but they have a decades-long record of sloppiness and negligence, and the various fires, explosions, dead workers, and environmental hazards that result.
I'd assume that our enthusiasm for aerial refueling is, in part(it certainly has other advantages), a contingency plan as well.
The ability to fly from the continental US to just about anywhere without landing is close to being an expensive stunt when you have allies much closer by, and enemies with virtually no ranged strike capability; but it could be downright essential if your carriers have recently been involuntarily downgraded from "operational" to "artificial reef habitat"...
I think that your comment can be read on two levels:
One. You are correct. Google is almost certainly taking advantage of the fact that browsers are substantially less complex(and people are comparatively tolerant of little rendering glitches, unless they scotch the whole page or "people" happen to be graphic designers...). It is a cynical; but very logical, tactic to talk most about the virtues you can cultivate most easily(though, conceivably, 60 days might actually be a much tighter limit for some of their server stuff, I don't know how hairy that can get).
Two. If your product is too large, and too tightly coupled, to turn around a fix in two months you had better have a very compelling reason. Arguably, Microsoft's relatively tight coupling of an enormous number of pieces has been very good business; but not very good design. In the short term, Google's implicit dig is rather cynical. In the longer term, though, they are really scoring a point in a battle of architectural philosophies. Microsoft probably actually handles size, complexity, and tight inter-relation better than most(they'd be dead if they didn't); but the problems that it causes them are basically their fault. They made that mess, they deliberately coupled stuff for economic reasons that could have been decoupled for engineering ones....
Slashdot Mirror
The thing that I will be interested to see(and to see Valve's reaction to) is A)whether alien swarm's modding options are sufficiently aggressive to do fairly radical total conversions(as opposed to just more alien swarm-ish; but on a different map, with different guns, or whatever) B)If A is true, whether people come up with anything particularly interesting. C) If B is true, does alien swarm, being free as in beer, become the preferred 'base' game for source-engine mods of all kinds?
Historically, modders have been somewhere between tolerated and celebrated because they voluntarily add value to commercial games. Now that Valve has a free and moddable game, using basically the same engine as their big guns, will modders just swarm around that, or are most of them too tied to working with modifications of the asset sets of the game they start with?
Did you completely miss the point of what the SFLC wants? Generally(somebody could probably dig up an exception somewhere) the free software types are not looking for a "Ministry of software" to enforce their aims. They are looking to secure the four freedoms for themselves and other software users and creators(and, on a cultural level, they tend to want most people to be at least a touch of both, rather than just "consumers").
Medical devices are already blackbox tested for function, the SFLC presumably wants for private citizens to be able to inspect code that is life critical to them, if they wish to do so. They(arguably quite rightly) see the fact that such things tend to be hidden behind a thicket of secrecy, and sometimes state enforced patents, as a bad thing.
I'm not sure how you jump from there to a bunch of drivel about the menace of a "ministry of testing everything" nanny state...
Correlating brain scans with questionnaires is cute and all, and has the advantage of being relatively quick; but suffers from the major disadvantage of being(at best) able to duplicate the accuracy of an existing(cheap, paper-based) test.
Obviously, progress is frequently made up of steps that don't make much sense on their own, since they don't yet improve on the status quo; but something as pricey as brain imaging is completely pointless unless it can exceed the performance of paper, not just correlate with it.
“Religion is regarded by the common people as true, by the wise as false, and by the rulers as useful.” -Seneca.
Get with the times, guys. This isn't "GSM cracking" this is "GSM lawful intercept"... At least that is what the folks who already do it routinely call the practice...
Ah, ok. That would make a great deal more sense.
The 12volt systems of any vehicle that wasn't built from scrap cardboard behind the iron curtain should be able to deliver enough power to set a cellphone on fire, much less charge it.
If the little car-socket-to-USB adapter widget is(either through severe cheapness, or through rigorous adherence to the USB spec) only delivering 500ma, a modern cellphone working hard could easily be draining the battery, or at least failing to charge.
"I'm afraid I can't let you send that, %USERNAME%."
*clicks send furiously*
"Look %USERNAME%, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over. "
Though, at 12 volts, 15 amps is a lot less headroom than it is at home, at 10 times that voltage...(EE geeks may proceed to evicerate me, based on my naive comparison of AC and DC scenarios...)
I still have to wonder what the hell kind of cigarette lighter adapter can't deliver enough power for a device that charges over usb(albeit, quite possibly preferring the sorta-kinda-standard "usb" that actually means 5V at more like 800 or 1000ma, rather than 500, along with the usual data lines)...
And not just him. System Shock 2 typically has you using a bloodied wrench much of the time. Not only is ammo scarce, guns degrade and jam with alarming frequency....
A "weapon of class destruction", if you will...
Christ, man. You should be more careful. I had a buddy who caught the FDIV bug smoking one of those things... His once promising accounting career was destroyed.
It might be nice if they had no jurisdiction; but they've got precedent...(Incidentally, if anybody tries to tell you that Scalia is an "originalist", please punch them).
Apparently, because the California intrastate market has an indirect effect on the interstate market, regulating it is a viable use of the interstate commerce clause. It was a darkly amusing case because it pitted the ostensible 'principles' of both the "conservative" and the "liberal" justices against their tastes. The conservative justices would have loved to chip away at the scope of the interstate commerce clause; but they just couldn't face the grim possibility of a world where potheads can't legally be busted by the feds. The liberals love them some broad interpretations of that clause; but they also have a (comparatively) soft spot for the test-case users.
I wish that I were more surprised by that; but then I think back to what Adobe is doing to PDFs, which are slowly growing into a script-driven monstrosity with virtually everything embedded in... Why yes, Adobe, I've always wanted to embed fucking videos in a document format designed for accurate printing...
Would satire have been finished off for good, or given a vigorous new lease on life if(after being handed the prize, of course), Kissinger had delivered an A cappella rendition of "Napalm sticks to kids" instead of a speech?
Ultimately, it would probably be wiser to focus on trying to guarantee security even in the possible presence of malicious actors, rather than attempt to create a system free of them.
Unfortunately, this is a hard problem in two basic respects:
1. Hardware is hard: Unless you are seriously good, and paying substantially more attention than is likely to be economically viable in most instances(yeah, sure, the new desktops for the call-center drones should be ready in a couple of weeks, once we finish electron microscopy and logic verification of all integrated circuits...) it will be possible for malicious hardware to lie to you. Much harder than malicious software, since you actually have to have your bad actors well placed in the silicon design process; but harder to detect.
2. Software producers(even ones whose business is hardware) would rather have their stuff be secret and demand that you trust them. Even though a lot of things like IPMI cards are basically just running approximately the same embedded linux that your cheap-ass router is, plus some sort of vendor management console interface, Dell doesn't exactly offer you the chance to compile it from source yourself(maybe, if you are a serious customer, they would talk; but it isn't standard).
Unfortunately, that depends... For classic "Hey, let's try to obfuscate on top of a standard OS running on general purpose hardware and hope nobody with a clue attaches a debugger" style DRM, OSS is indeed technically incompatible. Obtain code, recompile version with locks removed, go home happy. Game over.
However, if the code is under one of the OSS licenses that allows Tivoization(GPL2, among others), and if embedded hardware controlled by the vendor comes into play, you have a very different story. The code is OSS, you bought a product containing the binary. Sure, you are entitled to the source, here you go. Well, yeah, the device bootloader will only load images signed with our private key. Have a nice day. You are welcome to recompile the code for some other device, knock yourself out; but don't expect your device to be able to pass the challenge/response from our server that is handled by the TPM in our device...
If you control the hardware from a fairly low level, you can always enforce DRM that way. Worse, unless you screw up, any attack will actually require a silicon level crack, not just some software chops and patience.
On a feature level, for the entire browser+addons stack, I agree that that is an extremely useful feature. Sturgeon's law applies, hard, to flash and most of it deserves to be blocked.
Architecturally, though, isn't the flash renderer plugin a silly place for blacklisting/whitelisting/domain control features? The browser is responsible for issuing the HTTP requests, rendering what it can, calling plugins for what it can't, and so forth. Why should the browser download the flash blob, load the renderer, and then have the renderer check a blacklist and allow or refuse rendering of the object?
Wouldn't it make much more sense for that to be handled at the browser level, with the renderer invoked only if you want the flash rendered?
Reality has been waging a very effective war on satire for some time now.
The only bright side to all this is that Irish babies are, in fact, delicious.
Arguably the IPMI is one step easier than just the motheboard firmware. Those suckers are basically little embedded computers, typically running linux or vxworks, with their own processor and everything. They happen to be physically coupled to the motherboards of larger devices; but, architecturally, they are basically the same as any of the "little bitty plastic box" style embedded network appliances.
Given the fact that embedded appliances frequently have security made of pure shit, and servers are rather high value targets, the only real surprise is that they aren't targeted more often. Especially, if you are super lucky, the IPMI card will be connected to the oh-so-special-and-physically-separate-for-security "management network", which is where all the juicy; but often vulnerable, management interfaces live. Nice place to have an attack platform silently embedded...
(Not just "behaving to spec" but "behaving exactly the same as it did yesterday")
I'd say that that has a great deal to do with loose or tight coupling... Your point is valid in that Microsoft is not, personally, responsible for all the tight coupling in the Wintel ecosystem. They do do some of it themselves, but their larger contribution is probably in aiding and abetting the producers of various large, expensive software stacks in doing tight coupling of their own.
This has been good business, Microsoft's customers generally like the backwards compatibility, because it saves them from having to touch their brittle, tightly coupled, systems; and are thus more willing to pay more than they would otherwise be. However, it has left Microsoft in something of an engineering bind. Their own internal product coupling makes their lives more difficult in some respects, and the fact that their best customers are their most change averse makes their lives even more difficult.
A great many devices default to a time earlier than their manufacture date when RTC power is lost. I'd assume that that is because almost nobody has any incentive to pay extra for an RTC whose manufacture date is the same as the product, and RTCs for commodity systems aren't really exciting enough to be replaced with enhanced products, that have a new start date, all that often...
Well, the evidence is circumstantial; but they've sure lubricated a lot of blowholes in the past few months... That suggests intent.
To say that "The court of public opinion has decided that oil = bad" is really something of a strawman. It is more elegantly constructed than usual; because it isn't false; but it also isn't salient.
The public certainly doesn't like the oil industry(partly out of the recognition that they are one of the necessary-but-very-ugly underbellies of our civilization, partially out of a lingering suspicion that they are getting screwed at the gas pump); but it is a simple matter of record that, for oil companies of any size operating in the US(the really crazy shit generally happens abroad. You aren't, generally, allowed to hire mercenaries to kill inconvenient civilians in the US...), BP's safety record is the worst, to a marked degree. Their latest accident is their biggest; but they have a decades-long record of sloppiness and negligence, and the various fires, explosions, dead workers, and environmental hazards that result.
I'd assume that our enthusiasm for aerial refueling is, in part(it certainly has other advantages), a contingency plan as well.
The ability to fly from the continental US to just about anywhere without landing is close to being an expensive stunt when you have allies much closer by, and enemies with virtually no ranged strike capability; but it could be downright essential if your carriers have recently been involuntarily downgraded from "operational" to "artificial reef habitat"...
I think that your comment can be read on two levels:
One. You are correct. Google is almost certainly taking advantage of the fact that browsers are substantially less complex(and people are comparatively tolerant of little rendering glitches, unless they scotch the whole page or "people" happen to be graphic designers...). It is a cynical; but very logical, tactic to talk most about the virtues you can cultivate most easily(though, conceivably, 60 days might actually be a much tighter limit for some of their server stuff, I don't know how hairy that can get).
Two. If your product is too large, and too tightly coupled, to turn around a fix in two months you had better have a very compelling reason. Arguably, Microsoft's relatively tight coupling of an enormous number of pieces has been very good business; but not very good design. In the short term, Google's implicit dig is rather cynical. In the longer term, though, they are really scoring a point in a battle of architectural philosophies. Microsoft probably actually handles size, complexity, and tight inter-relation better than most(they'd be dead if they didn't); but the problems that it causes them are basically their fault. They made that mess, they deliberately coupled stuff for economic reasons that could have been decoupled for engineering ones....