www.gcn.com/print/27_8/46117-1.html

Interesting quotes --

“We have achieved the promises of Moore’s Law,”

“Much more pervasive now is the problem with software.”

“Software is getting bigger and more complex,"

"The Windows Vista operating system is so much bigger than its
predecessors, that it is not any faster even though processing speeds
have increased.”


= = = ==================================

DOD wants apps up to speed

Despite hardware advances, complex code and heavy traffic put a drag
on systems Bloated operating systems and applications are preventing
military organizations from getting sufficient speed from their
information technology systems, according to several speakers at a
recent Navy IT Day in Washington.

“We have achieved the promises of Moore’s Law,” the decades-old axiom
that processing power would roughly double every 18 to 24 months, said
Chris Miller, the Navy’s domain lead for command, control,
communications, computers and intelligence (C4I).

“Much more pervasive now is the problem with software.”

“Software is getting bigger and more complex,” Miller said. “The
Windows Vista operating system is so much bigger than its
predecessors, [but] it is not any faster, even though processing
speeds have increased.”

Elizabeth Sedlacek, director of information systems and infrastructure
at the Marine Corps Systems Command, echoed Miller’s complaint.
“Windows 95 required 50M of hard drive space,” she said. “Vista
requires 15G.”

Part of the problem is that Moore’s Law isn’t the only one in the IT
universe.

Sedlacek said increased resource requirements from the multiplication
of software code illustrate an adaptation of Parkinson’s Law: software
will expand to fill the resources available to it. The original
Parkinson’s Law states that work would expand to fill the time
available. A corollary to Parkinson’s Law states that software
eventually reaches a coefficient of inefficiency, meaning that it gets
so large that it no longer processes data effectively.

Sedlacek summarized her conundrum by citing yet another law. “Wirth’s
Law states that software gets faster slower than hardware gets
faster,” she said. According to Wirth’s law, then, software will
always lag behind processing capacity.

But it wasn’t always so. “In the 1970s and 1980s, hardware processing
power was wanting, and programmers had to code effectively and
efficiently in order to get done what we needed to get done,” Sedlacek
said. “Now that capacity has increased and the software industry is
much larger, developers want to put lots of features on software and
to do it quickly in order to gain a competitive advantage. Efficiency
of coding is no longer a priority.”

A problem the Marines face, for example, is that they rarely operate
in a resource-rich environment.

Marines are on expedition-like missions when they deploy, Sedlacek
said, and they typically operate with a minimal footprint in areas of
limited bandwidth. They rely on small handheld devices for information
and communications.

She challenged industry to help solve the problem.

Aside from software coding, agencies could address the problem through
more efficient data management.

Miller suggested that the Navy needs a data strategy for how it
expands applications. Richard Hull, chief scientist at Modus Operandi,
agreed in an interview with GCN that getting smarter about collecting
and processing data will help software work more efficiently.

“Software gets slower because the data operating over a network is
increasing faster than computer processing rates,” Hull said.

Some satellites generate several gigabytes of data per second, Hull
said. “The next generation may be terabytes of information per
second,” he said. “If a computer has to deal with 100 times or 1,000
times the amount of data today than it did yesterday, it’s going to be
swamped.”

Hull suggested two strategies to cope with the glut of data. One
involves prioritizing so that only the data most relevant to the
mission is actually processed.

“A weather information system may have collected temperature once per
hour, yielding 24 readings per day,” he said. “Then a new technology
comes along allowing you to collect a new temperature reading every
second. That’s 600 times more information than you had before.

But that doesn’t mean you need to analyze it all in depth. You’re
really just interested in changes or anomalies.”

Using semantic architectures to analyze and filter data sets up
hierarchies of data and processing that can help ensure that only the
most interesting data climbs the ladder for in-depth analysis. “You
might have a network of 64 computers filtering the data and passing up
relevant data to a level consisting of 16 computers and then to eight
computers,” Hull said. “This can filter out a lot of junk and provides
a higher degree of fidelity in information collecting and analysis.”

Another possible solution is to use cloud computing schemes, he said.
Cloud computing refers to the ability to construct ad hoc networks of
computers that can share resources to tackle tough computing
challenges.

An organization might have 10,000 computers at its disposal. Cloud
computing provides a management structure by which, for example, 1,000
of those machines might be aggregated to solve a particular problem.

“It could take a year to build a network of

1,000 computers,” Hull said, “but the cloud computing architecture
allows this to be done quickly.”

Another potential solution comes in the form of muticore processing,
essentially assigning pieces of the puzzle to different processors
running simultaneously on a single device. There are limitations to
this approach, as there are with cloud computing, because most
applications are single-threaded, Sedlacek said. Muticore central
processing units do not increase computing power when the applications
can’t be divvied up into discrete tasks.

The premise of multicore computing is that the computing capacity of
microchips is leveling off and that the computing power inherent in
existing machines must be maximized and optimized. Making that happen
requires programmers to accomplish two things, said Joey Sevin, Navy
programs manager at Mercury Federal Systems. They must develop a
greater understanding of computer hardware, and they must do something
about how they write software.

“It requires people to think differently about applications and how to
write them,” Sevin said.

“Programmers are encouraged to throw off code quickly, but in the end
this is very inefficient when the application is single-threaded.”

Sevin said the solution is to use middleware that can coordinate
messaging among multiple processors. “What needs to happen is the
adoption of a standard” for a message passing interface, he said.

MPIs would allow existing computers to distribute tasks across their
existing processors and boost their processing power. The effect of
distributing computing assignments across multiple processors also has
the effect of making the software less complex, Sevin said.

Mercury is working on developing multiprocessor solutions for
processing sensor data.

Because data collection platforms are getting smaller and more
complex, Mercury wants to pool processing power to support multiple
missions.

“The idea is to create an environment adaptive to different
situations,” Sevin said. An unmanned aerial vehicle “may go out on a
mission.

When it finishes its job and transmits its data, the computing asset
may be reallocated to some other mission in another location and with
a different type of sensor.”

This type of system is designed to handle two problems inherent in the
collection and transmission of sensor data: latency and throughput.

Latency refers to the need for computing to function in real time.
Throughput problems arise when the volume of data overwhelms
processors and causes delays.

What sort of solution would the Marine Corps be most interested in?
Sedlacek leaned toward simpler and leaner software. She urged industry
to adopt open, modular and scalable software designs and to avoid
“featuritis.” She also suggested that the Marine Corps might develop
incentives for lean software design, and she urged software developers
to adopt the YAGNI principle: You Ain’t Gonna Need It, so don’t code
it.

= = = ==================================

www.gcn.com/print/27_8/46117-1.html

hsyq8xg******.com wrote:
> www.gcn.com/print/27_8/46117-1.html
>
> Interesting quotes --
>
> “We have achieved the promises of Moore’s Law,”
>
> “Much more pervasive now is the problem with software.”
>
> “Software is getting bigger and more complex,"
>
> "The Windows Vista operating system is so much bigger than its
> predecessors, that it is not any faster even though processing speeds
> have increased.”
>
>
> = = = ==================================
>

I don't see anywhere in this article where they say what OSs they are
using.

Steve

"Steve de Mena" <steve@stevedemena.com> wrote in message
news:qfudncEI1P8olLDVnZ2dnUVZ_qzinZ2d@giganews.com ...
> hsyq8xg******.com wrote:
>> www.gcn.com/print/27_8/46117-1.html
>>
>> Interesting quotes --
>>
>> “We have achieved the promises of Moore’s Law,”
>>
>> “Much more pervasive now is the problem with software.”
>>
>> “Software is getting bigger and more complex,"
>>
>> "The Windows Vista operating system is so much bigger than its
>> predecessors, that it is not any faster even though processing speeds
>> have increased.”
>>
>>
>> = = = ==================================
>>
>
> I don't see anywhere in this article where they say what OSs they are
> using.
>
> Steve

Advocating junk again AS USUAL I see.

John wrote:
>
> "Steve de Mena" <steve@stevedemena.com> wrote in message
> news:qfudncEI1P8olLDVnZ2dnUVZ_qzinZ2d@giganews.com ...
>> hsyq8xg******.com wrote:
>>> www.gcn.com/print/27_8/46117-1.html
>>>
>>> Interesting quotes --
>>>
>>> “We have achieved the promises of Moore’s Law,”
>>>
>>> “Much more pervasive now is the problem with software.”
>>>
>>> “Software is getting bigger and more complex,"
>>>
>>> "The Windows Vista operating system is so much bigger than its
>>> predecessors, that it is not any faster even though processing speeds
>>> have increased.”
>>>
>>>
>>> = = = ==================================
>>>
>>
>> I don't see anywhere in this article where they say what OSs they are
>> using.
>>
>> Steve
>
> Advocating junk again AS USUAL I see.

I was making a statement of FACT, as usual.

Steve

hsyq8xg******.com wrote:
> www.gcn.com/print/27_8/46117-1.html
>
> Interesting quotes --
>
> “We have achieved the promises of Moore’s Law,”
>
> “Much more pervasive now is the problem with software.”
>
> “Software is getting bigger and more complex,"
>
> "The Windows Vista operating system is so much bigger than its
> predecessors, that it is not any faster even though processing speeds
> have increased.”
>
>
> = = = ==================================
>
> DOD wants apps up to speed
>
> Despite hardware advances, complex code and heavy traffic put a drag
> on systems Bloated operating systems and applications are preventing
> military organizations from getting sufficient speed from their
> information technology systems, according to several speakers at a
> recent Navy IT Day in Washington.
>
> “We have achieved the promises of Moore’s Law,” the decades-old axiom
> that processing power would roughly double every 18 to 24 months, said
> Chris Miller, the Navy’s domain lead for command, control,
> communications, computers and intelligence (C4I).
>
> “Much more pervasive now is the problem with software.”
>
> “Software is getting bigger and more complex,” Miller said. “The
> Windows Vista operating system is so much bigger than its
> predecessors, [but] it is not any faster, even though processing
> speeds have increased.”
>
> Elizabeth Sedlacek, director of information systems and infrastructure
> at the Marine Corps Systems Command, echoed Miller’s complaint.
> “Windows 95 required 50M of hard drive space,” she said. “Vista
> requires 15G.”
>
> Part of the problem is that Moore’s Law isn’t the only one in the IT
> universe.
>
> Sedlacek said increased resource requirements from the multiplication
> of software code illustrate an adaptation of Parkinson’s Law: software
> will expand to fill the resources available to it. The original
> Parkinson’s Law states that work would expand to fill the time
> available. A corollary to Parkinson’s Law states that software
> eventually reaches a coefficient of inefficiency, meaning that it gets
> so large that it no longer processes data effectively.
>
> Sedlacek summarized her conundrum by citing yet another law. “Wirth’s
> Law states that software gets faster slower than hardware gets
> faster,” she said. According to Wirth’s law, then, software will
> always lag behind processing capacity.
>
> But it wasn’t always so. “In the 1970s and 1980s, hardware processing
> power was wanting, and programmers had to code effectively and
> efficiently in order to get done what we needed to get done,” Sedlacek
> said. “Now that capacity has increased and the software industry is
> much larger, developers want to put lots of features on software and
> to do it quickly in order to gain a competitive advantage. Efficiency
> of coding is no longer a priority.”
>
> A problem the Marines face, for example, is that they rarely operate
> in a resource-rich environment.
>
> Marines are on expedition-like missions when they deploy, Sedlacek
> said, and they typically operate with a minimal footprint in areas of
> limited bandwidth. They rely on small handheld devices for information
> and communications.
>
> She challenged industry to help solve the problem.
>
> Aside from software coding, agencies could address the problem through
> more efficient data management.
>
> Miller suggested that the Navy needs a data strategy for how it
> expands applications. Richard Hull, chief scientist at Modus Operandi,
> agreed in an interview with GCN that getting smarter about collecting
> and processing data will help software work more efficiently.
>
> “Software gets slower because the data operating over a network is
> increasing faster than computer processing rates,” Hull said.
>
> Some satellites generate several gigabytes of data per second, Hull
> said. “The next generation may be terabytes of information per
> second,” he said. “If a computer has to deal with 100 times or 1,000
> times the amount of data today than it did yesterday, it’s going to be
> swamped.”
>
> Hull suggested two strategies to cope with the glut of data. One
> involves prioritizing so that only the data most relevant to the
> mission is actually processed.
>
> “A weather information system may have collected temperature once per
> hour, yielding 24 readings per day,” he said. “Then a new technology
> comes along allowing you to collect a new temperature reading every
> second. That’s 600 times more information than you had before.
>
> But that doesn’t mean you need to analyze it all in depth. You’re
> really just interested in changes or anomalies.”
>
> Using semantic architectures to analyze and filter data sets up
> hierarchies of data and processing that can help ensure that only the
> most interesting data climbs the ladder for in-depth analysis. “You
> might have a network of 64 computers filtering the data and passing up
> relevant data to a level consisting of 16 computers and then to eight
> computers,” Hull said. “This can filter out a lot of junk and provides
> a higher degree of fidelity in information collecting and analysis.”
>
> Another possible solution is to use cloud computing schemes, he said.
> Cloud computing refers to the ability to construct ad hoc networks of
> computers that can share resources to tackle tough computing
> challenges.
>
> An organization might have 10,000 computers at its disposal. Cloud
> computing provides a management structure by which, for example, 1,000
> of those machines might be aggregated to solve a particular problem.
>
> “It could take a year to build a network of
>
> 1,000 computers,” Hull said, “but the cloud computing architecture
> allows this to be done quickly.”
>
> Another potential solution comes in the form of muticore processing,
> essentially assigning pieces of the puzzle to different processors
> running simultaneously on a single device. There are limitations to
> this approach, as there are with cloud computing, because most
> applications are single-threaded, Sedlacek said. Muticore central
> processing units do not increase computing power when the applications
> can’t be divvied up into discrete tasks.
>
> The premise of multicore computing is that the computing capacity of
> microchips is leveling off and that the computing power inherent in
> existing machines must be maximized and optimized. Making that happen
> requires programmers to accomplish two things, said Joey Sevin, Navy
> programs manager at Mercury Federal Systems. They must develop a
> greater understanding of computer hardware, and they must do something
> about how they write software.
>
> “It requires people to think differently about applications and how to
> write them,” Sevin said.
>
> “Programmers are encouraged to throw off code quickly, but in the end
> this is very inefficient when the application is single-threaded.”
>
> Sevin said the solution is to use middleware that can coordinate
> messaging among multiple processors. “What needs to happen is the
> adoption of a standard” for a message passing interface, he said.
>
> MPIs would allow existing computers to distribute tasks across their
> existing processors and boost their processing power. The effect of
> distributing computing assignments across multiple processors also has
> the effect of making the software less complex, Sevin said.
>
> Mercury is working on developing multiprocessor solutions for
> processing sensor data.
>
> Because data collection platforms are getting smaller and more
> complex, Mercury wants to pool processing power to support multiple
> missions.
>
> “The idea is to create an environment adaptive to different
> situations,” Sevin said. An unmanned aerial vehicle “may go out on a
> mission.
>
> When it finishes its job and transmits its data, the computing asset
> may be reallocated to some other mission in another location and with
> a different type of sensor.”
>
> This type of system is designed to handle two problems inherent in the
> collection and transmission of sensor data: latency and throughput.
>
> Latency refers to the need for computing to function in real time.
> Throughput problems arise when the volume of data overwhelms
> processors and causes delays.
>
> What sort of solution would the Marine Corps be most interested in?
> Sedlacek leaned toward simpler and leaner software. She urged industry
> to adopt open, modular and scalable software designs and to avoid
> “featuritis.” She also suggested that the Marine Corps might develop
> incentives for lean software design, and she urged software developers
> to adopt the YAGNI principle: You Ain’t Gonna Need It, so don’t code
> it.
>
> = = = ==================================
>
> www.gcn.com/print/27_8/46117-1.html

They (USN) must be using that POS toy os linux cause no where does it
say they're using Vista.
Frank

On May 16, 12:12 am, Steve de Mena <st...@stevedemena.com> wrote:
> I don't see anywhere in this article where they say what OSs they are
> using.
>
> Steve

If they have brains they are using the SELinux which was created by
the NSA. Its the most secure distribution of Linux and they encourage
all branches of the government to use it instead of Windows.

--TheZorch

<hsyq8xg******.com> wrote in message
news:e18a23ab-2f89-4da8-9dc3-cdd9a1ac677b@1g2000prg.googlegroups.com...

A poor troll..
the important bit is

>>>>
“Software gets slower because the data operating over a network is
increasing faster than computer processing rates,” Hull said.

Some satellites generate several gigabytes of data per second, Hull
said. “The next generation may be terabytes of information per
second,” he said. “If a computer has to deal with 100 times or 1,000
times the amount of data today than it did yesterday, it’s going to be
swamped.”
<<<<<


Its the same for all OSes so you can insert any OS you like and the post
means the same.

In fact you probably can't insert windows there at all as its unlikely to
run the processing of terabytes of data from a satellite and it certainly
will not be Vista as it hasn't been around long enough and is a desktop OS.

follow ups set!

>> www.gcn.com/print/27_8/46117-1.html
>
> They (USN) must be using that POS toy os linux cause no where does it
> say they're using Vista.
> Frank

Ah, then Linux must be much more popular than I had suspected. I always
assumed if it wasn't mentioned they were probably using MS - guess I was
wrong.

"ray" <ray@zianet.com> wrote in message
news:695jjoF2v6p0qU1@mid.individual.net...
>
>>> www.gcn.com/print/27_8/46117-1.html
>>
>> They (USN) must be using that POS toy os linux cause no where does it
>> say they're using Vista.
>> Frank
>
> Ah, then Linux must be much more popular than I had suspected. I always
> assumed if it wasn't mentioned they were probably using MS - guess I was
> wrong.

Probably, no mention of vista gives you several choices including: linux,
Mac, XP, 98, 95, CE, pSOS, DOS, and loads of others.
Choose the best one for the application and everything will be fine.

"dennis@home" <den...@killspam.kicks-ass.net> wrote:
>
> ... no mention of vista gives you several
> choices including: linux, Mac, XP, 98, 95, CE,
> pSOS, DOS, and loads of others. Choose the best
> one for the application and everything will be fine.

IIRC, the USN had been using NT on some of their ships a couple of
years ago.

Here's some links:

<http://www.gcn.com/print/17_17/33727-1.html>

<http://www.wired.com/science/discoveries/news/1998/07/13987>

<http://windowsitpro.com/article/arti...nt-sinks-navy-
ship.html>

These are all pretty dated; not sure if there's more current info
online or not.


-hh

On Fri, 16 May 2008 10:56:01 -0700, -hh wrote:

> "dennis@home" <den...@killspam.kicks-ass.net> wrote:
>>
>> ... no mention of vista gives you several choices including: linux,
>> Mac, XP, 98, 95, CE, pSOS, DOS, and loads of others. Choose the best
>> one for the application and everything will be fine.
>
> IIRC, the USN had been using NT on some of their ships a couple of years
> ago.
>
> Here's some links:
>
> <http://www.gcn.com/print/17_17/33727-1.html>
>
> <http://www.wired.com/science/discoveries/news/1998/07/13987>
>
> <http://windowsitpro.com/article/arti...nt-sinks-navy-
> ship.html>
>
> These are all pretty dated; not sure if there's more current info online
> or not.

Sorry... but the Yorktown meltdown had to do with a divide by zero error
in the engine power interface when the operator entered zero into a data
input field which was the fault of the person who programmed the control
software and had nothing to do with the operating system.

*This should in no way be misconstrued as an endorsement of windows. I
would not knowingly trust my life to a Microsoft OS.*

--
"Remain calm, we're here to protect you!"

On Fri, 16 May 2008 13:37:30 -0500, Ivan Marsh wrote:


> *This should in no way be misconstrued as an endorsement of windows. I
> would not knowingly trust my life to a Microsoft OS.*

Ever been in a hospital?
If so ,you already have.

Ever go to the doctor?
If so, you already have.

Ever go to the dentist?
If so you already have.

Ever go to the pharmacy to get medications?
If so you already have.

.....and so forth..


--
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/

On Fri, 16 May 2008 14:44:09 -0400, Moshe Goldfarb wrote:

> On Fri, 16 May 2008 13:37:30 -0500, Ivan Marsh wrote:
>
>> *This should in no way be misconstrued as an endorsement of windows. I
>> would not knowingly trust my life to a Microsoft OS.*
>
> Ever been in a hospital?
> If so ,you already have.
>
> Ever go to the doctor?
> If so, you already have.
>
> Ever go to the dentist?
> If so you already have.
>
> Ever go to the pharmacy to get medications? If so you already have.
>
> ....and so forth..

I said I didn't WANT to know.

--
"Remain calm, we're here to protect you!"

On Fri, 16 May 2008 13:53:47 -0500, Ivan Marsh wrote:

> On Fri, 16 May 2008 14:44:09 -0400, Moshe Goldfarb wrote:
>
>> On Fri, 16 May 2008 13:37:30 -0500, Ivan Marsh wrote:
>>
>>> *This should in no way be misconstrued as an endorsement of windows. I
>>> would not knowingly trust my life to a Microsoft OS.*
>>
>> Ever been in a hospital?
>> If so ,you already have.
>>
>> Ever go to the doctor?
>> If so, you already have.
>>
>> Ever go to the dentist?
>> If so you already have.
>>
>> Ever go to the pharmacy to get medications? If so you already have.
>>
>> ....and so forth..
>
> I said I didn't WANT to know.

Hahaha!
Good one.

--
Moshe Goldfarb
Collector of soaps from around the globe.
Please visit The Hall of Linux Idiots:
http://linuxidiots.blogspot.com/

In comp.os.linux.advocacy, Ivan Marsh
<ivanmarsh******.com>
wrote
on Fri, 16 May 2008 13:53:47 -0500
<pan.2008.05.16.18.53.46.486748******.com>:
> On Fri, 16 May 2008 14:44:09 -0400, Moshe Goldfarb wrote:
>
>> On Fri, 16 May 2008 13:37:30 -0500, Ivan Marsh wrote:
>>
>>> *This should in no way be misconstrued as an endorsement of windows. I
>>> would not knowingly trust my life to a Microsoft OS.*
>>
>> Ever been in a hospital?
>> If so ,you already have.
>>
>> Ever go to the doctor?
>> If so, you already have.
>>
>> Ever go to the dentist?
>> If so you already have.
>>
>> Ever go to the pharmacy to get medications? If so you already have.
>>
>> ....and so forth..
>
> I said I didn't WANT to know.
>

Well, FWIW my dentist also uses Windows to keep track
of appointments. AFAIK the drilling equipment and such
is not computer-controlled. I wouldn't worry
unnecessarily.

Bear also in mind that Java's EULA has the following clause:

3. RESTRICTIONS. [...] You acknowledge that Licensed
Software is not designed or intended for use in the design,
construction, operation or maintenance of any nuclear
facility. Sun Microsystems, Inc. disclaims any express
or implied warranty of fitness for such uses. [...]

(Personally, I'm not sure *any* language is explicitly
intended for use in the design of nuclear facilities --
or anything else, really. It's a strange inclusion, though.)

--
#191, ewill3@earthlink.net
"640K ought to be enough for anybody."
- allegedly said by Bill Gates, 1981, but somebody had to make this up!
** Posted from http://www.teranews.com **