Yup. It's a much bigger problem than people realize. Many companies are very dependent on a mountain of applications which were built exactly in the manner of the one you describe. Management didn't budget for maintenance of the application, so IT staff are "maintaining" it by responding to crisis situations which float to the top of priorities and put other work on hold. Maintenance of applications is a cost that is nearly always underfunded or not funded in corporate IT. Heck, most companies can't even tell you how many custom applications they have. They don't even know until they break how critical they have become to some process or another. The converse happens occasionally, too, where a "critical" application breaks and nobody notices for quite a while. That happens less often, though.
All of those problems can be fixed, too, by a competent IT department. The fact that they persist, today, years and years after these issues *should* have been fixed (noting also that many of which there was no excuse for creating in the first place) is a testimony to the very sorry state of affairs in enterprise IT these days. The rules are pretty simple, for a CIO. Fire everyone who told you to deploy applications in.asp. Fire anyone who told you that Windows was just as secure as UNIX. That pretty much wipes out your staff. Now, go find a bunch of eager young beavers who actually grok computers and networks and start over.
I know that you are simply repeating the excuse you have been given by your IT people, but they are smoking crack. The "understood" security risks are that using IE 6 to surf the web is probably the most efficient way to funnel malware into the Norton AntiVirus malware collection system. The real truth in most of these companies, if you scratch the surface, is that they have a mountain of HTML code for internal custom applications which assumed all the flaws in IE6, and they don't have a budget, nor a plan, for updating those apps. If you're the CIO or CEO, demand a plan. If they can't produce one, fire them, and get people who know what they're doing.
"I'm sorry, but this is ridiculous. The reason you have trans-continental railroads is to move raw materials from one end of a continent to the other. Purely economic."
You embarrass yourself. There is a world of information beyond whatever you read in a cliff notes summary of Ayn Rand's Atlas Shrugged. Heck, 30 seconds with Wikipedia and you would realize that history of the economics of railroads isn't what you assumed it was.
In the United States (and other places) the creation of the Transcontinental railroads were heavily subsidized by governments. There is no doubt that there creation was accelerated greatly (by decades or more) by these subsidies.
Fixing the Constellation / Orion program is not really going to fix the problem. "Go to the Moon, again!" and "Go to Mars!" are not strategic objectives. They are relics of the Cold War, where space exploration is viewed as a trophy. We got there first!
We spent a decade and over a hundred billion on a space station, only to yank the transportation system out from under it without preparing another first, and change the plan to: "abandon it a few years after its completion, never funding the science research it was built for, so we can... go to the Moon!"
Could there be a more colossal failure of leadership in our space program?
In fact, there has been. A series of programs over the past 30 years were cancelled before they could yield the fruits of R&D which would be required to build a next generation space transportation system. So now we've decided to stop pretending that there is any motivation beyond the Cold War trophies, and get down to business building trophy capturing systems, updated versions of tried and true expendable rockets.
Sure, we could send people to Mars, once, or maybe twice, before the program was cancelled or cut back to occasional in-orbit operations only, which at that point will consist of visits to the Russian or Chinese space station or Lunar outpost.
The biggest problems with Constellation are that the system will do little to reduce the cost of a pound of payload into orbit, and is designed to conform to a launch infrastructure which isn't scalable. Two launch pads, with room at the Cape, but no funding to build a third. Two giant crawlers, Four vertical assembly bays (in practice 3, because 1 is use for storage), but barely enough funding to keep that facility water tight, let alone expand it.
How many flights per year could this infrastructure sustain? Enough to sustain a base on the Moon and occasional flights to Mars? Unlikely. It can barely sustain six or eight Shuttle flights per year. It could possibly handle a dozen or maybe 18 launches under Constellation per year, in a well funded year. What can you achieve with that? That certainly isn't going to be a foundation for a growing space economy.
We need to think about space access as an economic stimulus on the nature of the trans-continental railroads. We need to build an infrastructure to get to orbit reliably, then the moon reliably, then the asteroids and beyond. The first step would be an X-33 / VentureStar style program (with reasonable goals for the current generation system, but planning and R&D to lay the groundwork for advanced systems like space elevators come later) which builds R&D, then a fleet of vehicles, to increase our ability to get there, reduce the cost of a pound of payload to orbit, and increases the reliability. In parallel, we would have steady funding for technologies laying the roadbed to the next generation vehicles, twenty or thirty years out, as well as the power plants, and in-space engines needed for the in-space operations.
Maybe Constellation could be a first step in that plan, but it doesn't look to me like we're planning anything beyond failure. This system isn't scalable, and can't become scalable. It won't be cheap enough to fly, so we won't fly it often. (Sound familiar?)
Compared to fixing health care, this project wouldnâ(TM)t be all that expensive. Approached with the mindset that we are building a railroad to allow us to develop an in-space economy, the payoff would be enormous. If we continue a cold war, Moon-as-trophy mindset, we will never reap the full rewards of the investment weâ(TM)ve already made.
Perhaps we could redirect the 4% DoD increase to a long term investment.
This claim is made by nearly every spokesperson for any major organization which is forced to disclose a malware attack to the public. In nearly every case the claim cannot be substantiated. Run of the mill malware often scans hard drives and uploads data to remote servers over encrypted connections. Most organizations have no way of knowing if these even happened. They don't know how long they have been infected. They don't know if the attack is directed at them, specifically (and thus might be smarter about hiding its activity). These folk really don't know yet what the extent of the damage is. The stock line should be, "we don't know", not, "nothing bad happened". Something bad happened -- malware got on your network and spread. That much is clear.
That's the whole point of of the OpenCL architecture, to let the compiler figure out the hardware specific optimizations. If you want a cross platform, GPU-independent mechanism to:
[ _Booming_ _Monster_ _Truck_ _Voice_] Tap the hidden potential of your GPU! then you want OpenCL.
It's not really clear what you're looking for, possibly because you're looking for the wrong thing. It might help if you first spend an hour or three learning a little more about OpenCL, and reading up at various sites to see who's doing what.
OpenCL is an Open Standard compute language which comprises:
a language extended from C99,
a platform (hardware + OpenCL-aware device driver), and
a compiler and runtime (which may decide where to send a compute task at run time).
If you're writing an OpenCL-aware device device driver for a GPU, you'll probably need to wait a bit for some open source examples. It's reasonably likely that there will be some included in Darwin (once updated for Snow Leopard).
Look to the LLVM project (sponsored heavily by Apple and others) for an open source compiler which will (if it doesn't already) know about OpenCL.
It sounds like you might be looking for a higher level API which allows you to more easily use the OpenCL, or possibly for language bindings to Java or Python perhaps? I suspect you'll see those coming along, once Apple ships Snow Leopard, and people have a chance to kick the tires, and then integrate LLMV into their tool chains, extend various higher level API, bridge to Java and whatnot.
The earliest high level API to take easy and broad advantage of OpenCL will probably be from Apple, of course. They'll likely provide some nicely automatic ways to take advantage of OpenCL without programming the OpenCL C API directly. As a Cocoa programmer, you'll be using various high level objects, maybe an indexer for example, which have been taught new OpenCL tricks. You'll just recompile your program and it will tap the GPU as appropriate and if available. The Cocoa implementation is closed source, but people will see what's possible and emulate it in various open source libraries, on other platforms, for Java and other languages.
Insightful would be something like this: Businesses which are dependent on proprietary document storage formats like.doc,.xls, and.ppt, or upon Windows-only programming frameworks like Win32,.Net, or ASP should immediately begin migration to platform independent programming API and document storage formats.
A small but highly vocal minority of the population wields undo influence over the GOP. The Democratic Party, on the other hand, seeks to avoid becoming tarnished with the same crud that the GOP smeared themselves with, and thus actively seeks compromise at every turn. Polls indicate that stem cell research has broad, lasting support among American voters. Don't let the spirit of compromise wind up blocking this valuable research. You won, Obama, tell your party, and your bureaucracy to get on with it, already.
Mac are not "harder to find due to being less common". Windows malware spreads through several means, here are the three most common:
sending email to everyone in your address book Malware could trivially examine the email headers, determine which of your friends have Macs, and attach the Mac version of itself when sending email to them.
probing the network for vulnerable ports (worms) Malware could trivially fingerprint Macs, scan for vulnerable Mac ports, and send a custom Mac egg through the network connection. (Ed Skoudis described multi-payload worms in his encyclopedic Malware a few years ago)
by infecting a web server, and crawling back down the vulnerable browserMalware could trivially fingerprint the browser, and send custom packages to Safari for Firefox on the Mac when those users connect to an infected web site
So many people who think they know this stuff, and many of whom call themselves "security experts", and yet how don't even take the time to read the literature, study the history, or even take a programming class so they understand what can be done, and what's easy vs. what's hard.
tsk tsk.
And your parent poster was suggesting that taking over 1% of the Macs would create a very competitive botnet. He's right. You're wrong.
The barrier to entry most commonly cited as the largest barrier protecting the Mac, prior to the CPU transition of the Mac platform, was Apple's use of the PowerPC, which allegedly required that malware authors know PowerPC assembly language. This argument ignored:
the fact that plenty of malware existed for the old "System 7" and Mac OS 8/9,
the fact that anyone who knows x86 assembly can buy a book and write a perl script to convert their egg from x86 to PowerPC, then clean the rest up by hand. They've got the skills. They've got the hubris. They've clearly got the time, particularly when so much malware was authored by people just trying to demonstrate their prowess and make pranks, and
the fact that with all this malware, a small fraction of cr@X0rz are actually proficient in assembly, and the eggs are used by legion skript kiddiez who do *not* know assembly, so there was plenty of PowerPC mad skilz available.
Those people are still around, plenty of them, even though the most widely discussed malware is now part of profit seeking black market enterprises. Some of them are writing remote systems management code which puts Tivoli to shame. (e.g. Some of them are clearly bright enough to learn Objective C in a weekend, as they already know C, C++, C#, and x86 assembly) They are writing malware for Symbian, even though the statistics indicate that iPhone dominates the mobile web market. (Symbian has more browser instances on the planet, but they are not actually used by people to access the web, so you're not going to capture many passwords infecting those phones).
In fact, it's time to really start wondering: Where's the Mac OS X malware?
At some point we security experts must begin to consider the possibility that Mac OS X might be protected by more than it's niche market share.
"If the marketshare argument was true then there wouldn't have been any viruses for pre-OSX Macs either. But there were; lots of them.
There were also viruses for the Apple IIGS, hardly a market leader."
These and other inconvenient truths of the malware "market" are ignored, universally, by the industry trade press, and a surprising number of "security experts". There were worms exploiting Microsoft SQL Server on web servers when Apache + any of several other db had as much or greater market share. There have been Linux malware.
(Some of the various examples are relevant for fair comparison only within a market segment, such as the "web server" market, considered separately since these are considered "high value" targets, for their ability to spread to potentially many desktop systems, or for the data they might contain. For example, Linux had a minority share of the web server market when it first became a malware target. Perhaps this makes the case too subtle for pundits and the trade press, but it's not too subtle for the malware authors.)
The market share argument might be a partial explanation, but it really cannot explain the entirety of the vacuum in the Mac OS X malware marketplace. It's been five years, and still no malware plague. How many versions, and how many years must pass, before the industry realizes that perhaps there is something to this Mac OS X thing?
Slashdot Mirror
Microsoft is the real underdog in the cell phone world these days. Surely you're not holding out for a Windows Mobile device?
"Most people are not very susceptible to reason." -- Leonard Silk
Yup. It's a much bigger problem than people realize. Many companies are very dependent on a mountain of applications which were built exactly in the manner of the one you describe. Management didn't budget for maintenance of the application, so IT staff are "maintaining" it by responding to crisis situations which float to the top of priorities and put other work on hold. Maintenance of applications is a cost that is nearly always underfunded or not funded in corporate IT. Heck, most companies can't even tell you how many custom applications they have. They don't even know until they break how critical they have become to some process or another. The converse happens occasionally, too, where a "critical" application breaks and nobody notices for quite a while. That happens less often, though.
All of those problems can be fixed, too, by a competent IT department. The fact that they persist, today, years and years after these issues *should* have been fixed (noting also that many of which there was no excuse for creating in the first place) is a testimony to the very sorry state of affairs in enterprise IT these days. The rules are pretty simple, for a CIO. Fire everyone who told you to deploy applications in .asp. Fire anyone who told you that Windows was just as secure as UNIX. That pretty much wipes out your staff. Now, go find a bunch of eager young beavers who actually grok computers and networks and start over.
I know that you are simply repeating the excuse you have been given by your IT people, but they are smoking crack. The "understood" security risks are that using IE 6 to surf the web is probably the most efficient way to funnel malware into the Norton AntiVirus malware collection system. The real truth in most of these companies, if you scratch the surface, is that they have a mountain of HTML code for internal custom applications which assumed all the flaws in IE6, and they don't have a budget, nor a plan, for updating those apps. If you're the CIO or CEO, demand a plan. If they can't produce one, fire them, and get people who know what they're doing.
Uhm... you're a nerd posting on an internet tech site. Blame you, shall we?
s/there creation/their creation/
You embarrass yourself. There is a world of information beyond whatever you read in a cliff notes summary of Ayn Rand's Atlas Shrugged. Heck, 30 seconds with Wikipedia and you would realize that history of the economics of railroads isn't what you assumed it was.
In the United States (and other places) the creation of the Transcontinental railroads were heavily subsidized by governments. There is no doubt that there creation was accelerated greatly (by decades or more) by these subsidies.
Fixing the Constellation / Orion program is not really going to fix the problem. "Go to the Moon, again!" and "Go to Mars!" are not strategic objectives. They are relics of the Cold War, where space exploration is viewed as a trophy. We got there first!
We spent a decade and over a hundred billion on a space station, only to yank the transportation system out from under it without preparing another first, and change the plan to:
"abandon it a few years after its completion, never funding the science research it was built for, so we can... go to the Moon!"
Could there be a more colossal failure of leadership in our space program?
In fact, there has been. A series of programs over the past 30 years were cancelled before they could yield the fruits of R&D which would be required to build a next generation space transportation system. So now we've decided to stop pretending that there is any motivation beyond the Cold War trophies, and get down to business building trophy capturing systems, updated versions of tried and true expendable rockets.
Sure, we could send people to Mars, once, or maybe twice, before the program was cancelled or cut back to occasional in-orbit operations only, which at that point will consist of visits to the Russian or Chinese space station or Lunar outpost.
The biggest problems with Constellation are that the system will do little to reduce the cost of a pound of payload into orbit, and is designed to conform to a launch infrastructure which isn't scalable. Two launch pads, with room at the Cape, but no funding to build a third. Two giant crawlers, Four vertical assembly bays (in practice 3, because 1 is use for storage), but barely enough funding to keep that facility water tight, let alone expand it.
How many flights per year could this infrastructure sustain? Enough to sustain a base on the Moon and occasional flights to Mars? Unlikely. It can barely sustain six or eight Shuttle flights per year. It could possibly handle a dozen or maybe 18 launches under Constellation per year, in a well funded year. What can you achieve with that? That certainly isn't going to be a foundation for a growing space economy.
We need to think about space access as an economic stimulus on the nature of the trans-continental railroads. We need to build an infrastructure to get to orbit reliably, then the moon reliably, then the asteroids and beyond. The first step would be an X-33 / VentureStar style program (with reasonable goals for the current generation system, but planning and R&D to lay the groundwork for advanced systems like space elevators come later) which builds R&D, then a fleet of vehicles, to increase our ability to get there, reduce the cost of a pound of payload to orbit, and increases the reliability. In parallel, we would have steady funding for technologies laying the roadbed to the next generation vehicles, twenty or thirty years out, as well as the power plants, and in-space engines needed for the in-space operations.
Maybe Constellation could be a first step in that plan, but it doesn't look to me like we're planning anything beyond failure. This system isn't scalable, and can't become scalable. It won't be cheap enough to fly, so we won't fly it often. (Sound familiar?)
Compared to fixing health care, this project wouldnâ(TM)t be all that expensive. Approached with the mindset that we are building a railroad to allow us to develop an in-space economy, the payoff would be enormous. If we continue a cold war, Moon-as-trophy mindset, we will never reap the full rewards of the investment weâ(TM)ve already made.
Perhaps we could redirect the 4% DoD increase to a long term investment.
Obama's Warfare State
Of course, Iâ(TM)m just tinkering at the margins here with the radical suggestion that the 4% DoD increase could be better spent laying the rai
This claim is made by nearly every spokesperson for any major organization which is forced to disclose a malware attack to the public. In nearly every case the claim cannot be substantiated. Run of the mill malware often scans hard drives and uploads data to remote servers over encrypted connections. Most organizations have no way of knowing if these even happened. They don't know how long they have been infected. They don't know if the attack is directed at them, specifically (and thus might be smarter about hiding its activity). These folk really don't know yet what the extent of the damage is. The stock line should be, "we don't know", not, "nothing bad happened". Something bad happened -- malware got on your network and spread. That much is clear.
Please copy this file to your hard drive, decompress it, untar it, chmod it, and place an entry in the root crontab... so I can have your advice.
Oooh! Ow! Ouch! Yikes! Run away! Run away!
Mods, you can bite me. I can't believe that there are Flash Fanbois at Slashdot. This place has gone to hell.
Kill flash. Kill it stone cold dead.
Correct. The real defect here isn't the phone, it's the system it's spoofing. This phone just makes it easier to construct the spoof.
You are polluting the internet with your whining. Please stop. You're hurting the internet.
Apple and other OpenCL partners are undoubtedly looking forward, beyond SIMD, to the coming generation of MIMD capable GPU such as the nVIDIA GT300.
That's the whole point of of the OpenCL architecture, to let the compiler figure out the hardware specific optimizations. If you want a cross platform, GPU-independent mechanism to:
[ _Booming_ _Monster_ _Truck_ _Voice_]
Tap the hidden potential of your GPU! then you want OpenCL.
OpenCL is an Open Standard compute language which comprises:
If you're writing an OpenCL-aware device device driver for a GPU, you'll probably need to wait a bit for some open source examples. It's reasonably likely that there will be some included in Darwin (once updated for Snow Leopard).
Look to the LLVM project (sponsored heavily by Apple and others) for an open source compiler which will (if it doesn't already) know about OpenCL.
It sounds like you might be looking for a higher level API which allows you to more easily use the OpenCL, or possibly for language bindings to Java or Python perhaps? I suspect you'll see those coming along, once Apple ships Snow Leopard, and people have a chance to kick the tires, and then integrate LLMV into their tool chains, extend various higher level API, bridge to Java and whatnot.
The earliest high level API to take easy and broad advantage of OpenCL will probably be from Apple, of course. They'll likely provide some nicely automatic ways to take advantage of OpenCL without programming the OpenCL C API directly. As a Cocoa programmer, you'll be using various high level objects, maybe an indexer for example, which have been taught new OpenCL tricks. You'll just recompile your program and it will tap the GPU as appropriate and if available. The Cocoa implementation is closed source, but people will see what's possible and emulate it in various open source libraries, on other platforms, for Java and other languages.
Here's a good place to start: OpenCL - Parallel Computing on the GPU and CPU. Follow up with a google search.
Insightful would be something like this: Businesses which are dependent on proprietary document storage formats like .doc, .xls, and .ppt, or upon Windows-only programming frameworks like Win32, .Net, or ASP should immediately begin migration to platform independent programming API and document storage formats.
Oh, stars above, what have we done...
A small but highly vocal minority of the population wields undo influence over the GOP. The Democratic Party, on the other hand, seeks to avoid becoming tarnished with the same crud that the GOP smeared themselves with, and thus actively seeks compromise at every turn. Polls indicate that stem cell research has broad, lasting support among American voters. Don't let the spirit of compromise wind up blocking this valuable research. You won, Obama, tell your party, and your bureaucracy to get on with it, already.
Malware could trivially examine the email headers, determine which of your friends have Macs, and attach the Mac version of itself when sending email to them.
Malware could trivially fingerprint Macs, scan for vulnerable Mac ports, and send a custom Mac egg through the network connection. (Ed Skoudis described multi-payload worms in his encyclopedic Malware a few years ago)
So many people who think they know this stuff, and many of whom call themselves "security experts", and yet how don't even take the time to read the literature, study the history, or even take a programming class so they understand what can be done, and what's easy vs. what's hard.
tsk tsk.
And your parent poster was suggesting that taking over 1% of the Macs would create a very competitive botnet. He's right. You're wrong.
Those people are still around, plenty of them, even though the most widely discussed malware is now part of profit seeking black market enterprises. Some of them are writing remote systems management code which puts Tivoli to shame. (e.g. Some of them are clearly bright enough to learn Objective C in a weekend, as they already know C, C++, C#, and x86 assembly) They are writing malware for Symbian, even though the statistics indicate that iPhone dominates the mobile web market. (Symbian has more browser instances on the planet, but they are not actually used by people to access the web, so you're not going to capture many passwords infecting those phones).
In fact, it's time to really start wondering: Where's the Mac OS X malware?
At some point we security experts must begin to consider the possibility that Mac OS X might be protected by more than it's niche market share.
These and other inconvenient truths of the malware "market" are ignored, universally, by the industry trade press, and a surprising number of "security experts". There were worms exploiting Microsoft SQL Server on web servers when Apache + any of several other db had as much or greater market share. There have been Linux malware.
(Some of the various examples are relevant for fair comparison only within a market segment, such as the "web server" market, considered separately since these are considered "high value" targets, for their ability to spread to potentially many desktop systems, or for the data they might contain. For example, Linux had a minority share of the web server market when it first became a malware target. Perhaps this makes the case too subtle for pundits and the trade press, but it's not too subtle for the malware authors.)
The market share argument might be a partial explanation, but it really cannot explain the entirety of the vacuum in the Mac OS X malware marketplace. It's been five years, and still no malware plague. How many versions, and how many years must pass, before the industry realizes that perhaps there is something to this Mac OS X thing?