An OS could choose to make these attributes protected, i.e requires 'sufficient privilege' (e.g. root) to change.
The file extension is not "simple and descriptive" for a file type you've never seen before. Hence the existence of sites that translate those TLAs into a description, often overloaded, of what they might mean.
The other problem is that the file extension conflates content and implicit creator/handler. A text file is a text file, there's nothing special about NotePad, SimpleText, EMACS or (shudder) vi as the creator/handler for text files.
The idea of using file name extensions as a means to denote content/application association dates to the 1970s (or even earlier). It's an idea that deserves to die, along with Disco music.
Mac OS 9 and earlier got the OS/file system mechanisms right, with two file attributes. One denoted the contents of the file, and the other denoted the default (usually creating) application.
The challenge for OS designers is how to present this information to the user in some meaningful way. Cryptic text strings at the end of file names aint' it! And the ease by which these can be changed (particularly by malicious programs) are a bug, not a feature. If there's a way to prevent these attributes from being mis-applied/forged, that would be a real accomplishment.
In honor of the WWII 79th Armoured Division, that contained all the special purpose vehicles that were so useful during D-Day and beyond. https://en.wikipedia.org/wiki/...
(And without the advantages of being part of the Borg Collective.) http://venturebeat.com/2015/01... Pay particular attention to the chart showing -layoffs- across the IT sector!
I was planning to go see this, not that I'm interested in the movie, but to show that I won't kow-tow to terrorists and extortionists. But since Sony has caved by deferring its release, Sony has joined the ranks of the chicken-droppings.
Several sites have called for Sony to release this on the Internet, and that's what I think they should do. And someone needs to make "we don't negotiate with Young Weasel" stickers with Kim Jong Un's face in the background.
The pumps lost power after the backup systems failed (ran out of battery, and the generators were knocked out), and that's what caused the reactors to overheat and meltdown. If power had been retained to the pumps, the major problems would have been averted.
https://en.wikipedia.org/wiki/... "The switching stations that provided power from the three backup generators located higher on the hillside failed when the building that housed them flooded.[68] Power for control systems switched over to batteries that were designed to last about eight hours.[102] Further batteries and mobile generators were dispatched to the site. They were delayed by poor road conditions and the first arrived only at 21:00 11 March,[95][103] almost six hours after the tsunami."
After years of insisting that the rest of the organization exists to make the CIO's job easier, it's great to see the 'revolt of the masses' moving away from the one-size-fits-all/everything-Microsoft-regardless-of-the-security-cost solution to stuff that makes the individual more productive.
The complexity of everything makes the IT job harder, but "I can't be bothered to learn new things" response to the user demand for alternatives is ultimately self-defeating.
As a side observation over the last 35 years in the business, systems that support multiple platforms/clients/etc tend to be a lot more reliable than those that support a single configuration. The unwritten and often unknown assumptions about the execution environment (client or server, etc) are latent bugs even in a monoculture. (I'm certainly old enough to remember how much software broke in the move from 32 bit to 64 bit; anyone who coded as if integers and pointers are same size/interoperable got all the problems s/he deserved!)
And anecdotally, it seems many, if not most, of the ATC failures I remember hearing about in the US have also been power problems. These are kinda hard to test, as I wrote to a friend, "The on-duty ATC controllers get irate when you 'pull the big power plug' on their shift."
Usually failures like these are chains of events, e.g. "UPS ran out of batteries more rapidly than expected, and then we couldn't get the generators started."
Power problems are what doomed Fukushima, too, by the way.
I just read through the Bank of America Online Banking Service Agreement, and I don't see anything like this, nor is there any mention of IBM. Reading the Wikipedia page, it seems this is software used -inside- a bank.
Mod parent up insightful. And from extensive experience booking travel, I can assure you the tools the airlines use are better (more responsive, better data) than what they give us access to.
It's possible there are other versions. But that's not my point. The version that has been discovered and documented runs on Windows, a fact that is probably deliberately not made clear in the articles.
To discover this is a Windows-only virus? That was the first thing that crossed my mind, what platform(s) are vulnerable? It sure as hell isn't clearly stated in any of the articles I read, you have to dive into the details of the Symantec white paper to notice that all the attack vectors were specific to Windows.
And how much does the tech journalism community and the security products & services industry, from Ars to The Verge, to Symantec, get paid to hide the fact this is Yet Another Windows (only) vulnerability?
I contacted Senator Warner's office about this, and frankly was blown off. That being said, I think we need a -law- that requires the Telcos to work out how to make Caller ID unforgeable. I've been challenged to 'show the RFCs and related standards that would support this,' but since the industry has shown no interest in solving the technical problems, I reluctantly believe that it'll take legal action (either law, regulation or legal liability) to force the issue.
On a related note, I also asked about the impact of all those CallerID violations I've filed over the years, and got no response back from that. In both cases, I was forwarded a letter from the FCC that basically quoted from their website.
This is a language that of course was designed very differently from the common C based languages in wide use today, and one for which there is a very large amount of publicly available code (but not on GitHub.) I've seen studies from large volumes of Ada code, both with respect to error rates and with respect to development and maintenance costs, that show a significant advantage for that language.
My personal mileage varies significantly. I still prefer Ada, which is a language that you'd probably characterize as having a lot of "boilerplate". An experience Ada programmer learns how to use that to his advantage in several ways:
1. When you're on a large or long-lived project, readability of code (even your own, years later) is more important than writeability,
2. The compiler checks consistency, and as you get better with the language you learn how to maximize what the compiler can check. (This is particularly true for strong typing, where in my experience the bugs caught by typechecking are caught on scalar types. You're a lot more likely to add 'count-of-apples' to 'count-of-oranges' than you are to actually try to add apples and oranges.) Thus as a designer, I'd concentrate on the algorithm, logic flow, etc, and let the compiler check things like parameter names/types. When the compiler and I both agreed that the program was right, it usually was correct.
3. Syntactic error recovery. This is a big deal when first learning a language, and later when doing significant changes (e.g. refactoring). On a lot of compilers, a single syntax error made all the subsequent error messages both numerous and confusing/worthless (usually because the compiler made an incorrect assumption.) Ada compilers, particularly the hand-craft GNAT parser, got really good at providing meaningful error messages for the rest of the compilation after detecting (and recovering from) a syntax error.
4. Better optimization. The more info the compiler can get and depend on, the better job the optimizer can do, mostly by limiting the assumptions about how data or control flow is used.
"boilerplate" can be your best friend, when you and the compilation system take advantage of it.
A lot of the mail I get that goes into quarantine or marked as spam comes from outsourced senders, where Domain.com uses some 3rd party to send mail on behalf of it. This can be ISPs, companies like Constantcontact.com or God-only-knows what else. Of course, the company who bought this service probably doesn't know or want to understand what the problem is, and the company that's doing the outsourcing has no real incentive to make sure their hosts (including SPF, etc) are configured properly.
Slashdot Mirror
An OS could choose to make these attributes protected, i.e requires 'sufficient privilege' (e.g. root) to change.
The file extension is not "simple and descriptive" for a file type you've never seen before. Hence the existence of sites that translate those TLAs into a description, often overloaded, of what they might mean.
The other problem is that the file extension conflates content and implicit creator/handler. A text file is a text file, there's nothing special about NotePad, SimpleText, EMACS or (shudder) vi as the creator/handler for text files.
The idea of using file name extensions as a means to denote content/application association dates to the 1970s (or even earlier). It's an idea that deserves to die, along with Disco music.
Mac OS 9 and earlier got the OS/file system mechanisms right, with two file attributes. One denoted the contents of the file, and the other denoted the default (usually creating) application.
The challenge for OS designers is how to present this information to the user in some meaningful way. Cryptic text strings at the end of file names aint' it! And the ease by which these can be changed (particularly by malicious programs) are a bug, not a feature. If there's a way to prevent these attributes from being mis-applied/forged, that would be a real accomplishment.
In honor of the WWII 79th Armoured Division, that contained all the special purpose vehicles that were so useful during D-Day and beyond.
https://en.wikipedia.org/wiki/...
(And without the advantages of being part of the Borg Collective.)
http://venturebeat.com/2015/01...
Pay particular attention to the chart showing -layoffs- across the IT sector!
I'd publish a paper, "C syntax considered harmful" with roughly the same kind of rationale as the "Goto considered harmful" paper.
self.fuck
Short answer: Yes.
And I've also served in the US Army.
I was planning to go see this, not that I'm interested in the movie, but to show that I won't kow-tow to terrorists and extortionists. But since Sony has caved by deferring its release, Sony has joined the ranks of the chicken-droppings.
Several sites have called for Sony to release this on the Internet, and that's what I think they should do. And someone needs to make "we don't negotiate with Young Weasel" stickers with Kim Jong Un's face in the background.
"it is believed" - conspiracy theorists will believe anything that supports their theories.
Last time I checked, I'm not an oil&gas company.
Neither will NSA. You have your Three Letter Agencies mixed up.
All things considered, I trust the NSA more with my data. At least they're not in the business of selling it.
... You are measured by the budget that you consume. ....
Mod parent up insightful!
The pumps lost power after the backup systems failed (ran out of battery, and the generators were knocked out), and that's what caused the reactors to overheat and meltdown. If power had been retained to the pumps, the major problems would have been averted.
https://en.wikipedia.org/wiki/...
"The switching stations that provided power from the three backup generators located higher on the hillside failed when the building that housed them flooded.[68] Power for control systems switched over to batteries that were designed to last about eight hours.[102] Further batteries and mobile generators were dispatched to the site. They were delayed by poor road conditions and the first arrived only at 21:00 11 March,[95][103] almost six hours after the tsunami."
After years of insisting that the rest of the organization exists to make the CIO's job easier, it's great to see the 'revolt of the masses' moving away from the one-size-fits-all/everything-Microsoft-regardless-of-the-security-cost solution to stuff that makes the individual more productive.
The complexity of everything makes the IT job harder, but "I can't be bothered to learn new things" response to the user demand for alternatives is ultimately self-defeating.
As a side observation over the last 35 years in the business, systems that support multiple platforms/clients/etc tend to be a lot more reliable than those that support a single configuration. The unwritten and often unknown assumptions about the execution environment (client or server, etc) are latent bugs even in a monoculture. (I'm certainly old enough to remember how much software broke in the move from 32 bit to 64 bit; anyone who coded as if integers and pointers are same size/interoperable got all the problems s/he deserved!)
And anecdotally, it seems many, if not most, of the ATC failures I remember hearing about in the US have also been power problems. These are kinda hard to test, as I wrote to a friend, "The on-duty ATC controllers get irate when you 'pull the big power plug' on their shift."
Usually failures like these are chains of events, e.g. "UPS ran out of batteries more rapidly than expected, and then we couldn't get the generators started."
Power problems are what doomed Fukushima, too, by the way.
Well, the original thread was on BOA. Sounds to me like your business needs to change its bank.
Let's be clear: This is an Opt-In "feature". It is neither mandated nor included by default.
(That doesn't make it less objectionable, but it does clarify how it could get onto your computer.)
I just read through the Bank of America Online Banking Service Agreement, and I don't see anything like this, nor is there any mention of IBM. Reading the Wikipedia page, it seems this is software used -inside- a bank.
Mod parent up insightful. And from extensive experience booking travel, I can assure you the tools the airlines use are better (more responsive, better data) than what they give us access to.
It's possible there are other versions. But that's not my point. The version that has been discovered and documented runs on Windows, a fact that is probably deliberately not made clear in the articles.
To discover this is a Windows-only virus? That was the first thing that crossed my mind, what platform(s) are vulnerable? It sure as hell isn't clearly stated in any of the articles I read, you have to dive into the details of the Symantec white paper to notice that all the attack vectors were specific to Windows.
And how much does the tech journalism community and the security products & services industry, from Ars to The Verge, to Symantec, get paid to hide the fact this is Yet Another Windows (only) vulnerability?
I contacted Senator Warner's office about this, and frankly was blown off. That being said, I think we need a -law- that requires the Telcos to work out how to make Caller ID unforgeable. I've been challenged to 'show the RFCs and related standards that would support this,' but since the industry has shown no interest in solving the technical problems, I reluctantly believe that it'll take legal action (either law, regulation or legal liability) to force the issue.
On a related note, I also asked about the impact of all those CallerID violations I've filed over the years, and got no response back from that. In both cases, I was forwarded a letter from the FCC that basically quoted from their website.
This is a language that of course was designed very differently from the common C based languages in wide use today, and one for which there is a very large amount of publicly available code (but not on GitHub.) I've seen studies from large volumes of Ada code, both with respect to error rates and with respect to development and maintenance costs, that show a significant advantage for that language.
My personal mileage varies significantly. I still prefer Ada, which is a language that you'd probably characterize as having a lot of "boilerplate". An experience Ada programmer learns how to use that to his advantage in several ways:
1. When you're on a large or long-lived project, readability of code (even your own, years later) is more important than writeability,
2. The compiler checks consistency, and as you get better with the language you learn how to maximize what the compiler can check. (This is particularly true for strong typing, where in my experience the bugs caught by typechecking are caught on scalar types. You're a lot more likely to add 'count-of-apples' to 'count-of-oranges' than you are to actually try to add apples and oranges.) Thus as a designer, I'd concentrate on the algorithm, logic flow, etc, and let the compiler check things like parameter names/types. When the compiler and I both agreed that the program was right, it usually was correct.
3. Syntactic error recovery. This is a big deal when first learning a language, and later when doing significant changes (e.g. refactoring). On a lot of compilers, a single syntax error made all the subsequent error messages both numerous and confusing/worthless (usually because the compiler made an incorrect assumption.) Ada compilers, particularly the hand-craft GNAT parser, got really good at providing meaningful error messages for the rest of the compilation after detecting (and recovering from) a syntax error.
4. Better optimization. The more info the compiler can get and depend on, the better job the optimizer can do, mostly by limiting the assumptions about how data or control flow is used.
"boilerplate" can be your best friend, when you and the compilation system take advantage of it.
A lot of the mail I get that goes into quarantine or marked as spam comes from outsourced senders, where Domain.com uses some 3rd party to send mail on behalf of it. This can be ISPs, companies like Constantcontact.com or God-only-knows what else. Of course, the company who bought this service probably doesn't know or want to understand what the problem is, and the company that's doing the outsourcing has no real incentive to make sure their hosts (including SPF, etc) are configured properly.