You say "if I don't surf to your site... then I can't be infected". It almost sounds like you believe you have some control over whether your browser will hit his evil web page. Could it be that you actually think that both Internet routing and the DNS are hard to subvert?
Clientside security is still a joke. Clients get attention in the places where they "asynchronously" give up control to foreign command, like embedded scripts in email and virtual machines for things like Java. But the overwhelming majority of client code was designed assuming that it interacts in good faith with the rest of the world.
The flood of server-side vulnerabilities will slow. Desktop environments will get more and more homogenous. The payoff for writing a single exploit will grow. You should expect not only to see more client-targetting attacks, but also more attacks leveraging the ancient and festering weaknesses in global Internet routing and in DNS.
Consider that today, Internet routing is being subverted with some regularity to play pranks on IRC and to hijack address space for spamming. These are high-risk, low-reward enterprises. It's only a matter of time before smarter people figure out how to use the same tricks to more productive ends.
If "Kahil Jallad, Jonathan Katz, and Bruce Schneier" write a paper, the abbreviation is "Jallad et al". If Schneier is the LAST author in the list, it probably means he did very little except motivate the paper and help brainstorm.
Check it out yourself..then explain what this has to do with the civil war..and why the site owner is so irresponsible in his posting of porn there.
No, what's irresponsible is you adopting the mindset that the domain name system is a keyword search engine.
Pilots should be undergoing more security now, not less. A pilot's uniform and identification of good enough quality to fool an airline security screener should not be a "get through security free" card. Airline employee status is very likely to be exploited in future security mishaps, so airline employees are a wholly appropriate target of profiling and increased scrutiny.
The main reason is quite simple: they were seeing what they could get away with. They were not paying you what you were worth; rather, they were paying you what they thought you'd tolerate. I NEVER work for people like that.
Then you are probably unemployed. Virtually every employer does exactly this. The basic core purpose of a human resources department is to recruit and
retain good employees as cheaply as possible.
Things are priced at what the market will bear, not at
what they are "worth".
The STL doesn't help too much with the big problem of C and C++ programming: keeping track of who owns what. auto_ptr and the STL don't play well together.
Obviously not, because the containers rely on the
safety of the copy constructor and auto_ptr
implements RAII through the copy constructor.
Conceptually, aren't both part of the "STL"
anyways?
This is one of the reasons Boost has a
templated
shared_ptr, which does reference
counting instead of source/sink pointers.
This is covered in Effective C++, but it's
also pretty obvious from the APIs.I question
designs that want source/sink pointers in
containers anyways; part of the idea behind
using containers is to centralize the storage
of objects.
In practice, the big problem with the STL is that Microsoft doesn't like it.
...
So they support it, but badly.
I'm not sure this is a valid criticism:
Microsoft uses Dinkum STL,
which is actually an exceedingly good
implementation. The only problems I've
had are concurrency issues.
Compare Microsoft's problem to
Solaris. Forte uses bizarro Rogue Wave
STL, which is not an exceedingly good
implementation of the STL.
YDL is interesting because, if your day-to-day
operating system is Linux, you cannot do
better than a TiBook running Yellow Dog.
There simply is no hardware in the X86 world
that is comparable (wide screen display,
slim, lightweight, with adequate processing
power).
I used YDL when I first got my TiBook. I had
to, because I needed 802.11 support and
Apple didn't support Orinoco. I switched
because I needed Firewire more than I
needed Orinoco. My experiences:
YDL: Works as well as any mainstream
Linux distribution. Yup works, by some
definition of "works". Better still, Ximian's
stuff builds from SRPMS, and Ximian now
explicitly supports them with binaries. Not
hard to get current, buildable kernel source,
and FreeSWAN works nicely for IPsec.
The (major) negative is that Firewire support
blows, and it is pointless to buy hard drives
that don't come in Firewire enclosures. When
I left YDL, SBP2 drivers didn't work at all.
The (minor) negative is that companies don't
distribute closed-source binaries for YDL,
and they do for X86 Linux.
OSX 10.1: A dream; xterms, xemacs, and
Adobe Illustrator on the same screen. Rootless XFree86, transparent anything,
beautiful user interface, antialiasing. It's
faster than Linux for applications and slower
for tools. The one (big) negative is that
there is no credible IPsec or VPN support.
A minor negative is that you can't keep current
with BOTH the dev kernel AND Apple's
updates.
I'm on OSX 10.1.3 now and I'm not looking
back. However, I can understand why people
want PPC Linux, if they already simply use
Linux for everything and want good portable
environments. It's good to hear that YDL
continues to move forward.
Dan Bernstein has been yelling
for the past few weeks since he published
nfscircuit that his work does
not yet apply to 1024 bit keys
(or other "realistically" small key sizes).
In spite of that, stories like this one
keep popping up, forcing him to defend
himself from idiots who construct bogus
straw-man analyses against points that
he hasn't even made.
I would rather see Bernstein continue
this work, and have knowledgeable people
peer-review it, rather than see people waste
their time discussing whether solar cells
cost more money than AC power (an argument DJB had to get involved in on
sci.crypt) and other such lunacy.
In-case you are thinking how unreasonable it is for us to create a reference implementation before we document the protocol, note that the only reason everyone uses the BSD reference implementation of the TCP stack is that the TCP specification isn't worth the paper it is written on!
Every major operating system (Solaris, Linux,
Windows, BSD) has an independant implementation of TCP. None of them share
significant code, each was designed with
different goals. Every one of these implementations is validated against the standard, which spans multiple RFCs. The entire Internet is held from congestion collapse by cooperation amongst these implementations.
People will ALWAYS use SNMPv1. Nobody
will set up a new authentication infrastructure
just for SNMP. They will build ad-hoc backchannels to isolate SNMP from the rest
of the Internet. They will fail repeatedly, but
it won't be nearly as expensive as deploying
an entire new security infrastructure for
network management.
This is the same reason why nobody will ever use DNSSEC, and why everyone
uses SSH. SSH did the simplest thing
possible and left the infrastructure up to the
consumers. DNSSEC and SNMPvNG
repeatedly fucked this simple problem up by
trying to mandate more of the environment
than was required to get off the ground.
If this was a hole in an SMTP server
it would make sense to say that it's specific
to the server. Because the protocol in question in SNMP, it is NOT valid to make
this assumption. Virtually all implementations
of SNMP trace a lineage back to a common,
ancient implementation.
The reason for this is that SNMP uses an
incredibly complicated wire format: ASN.1/BER. ASN.1/BER is based on the (once
seductive) idea that you could avoid interoperability and extensibility problems by
(in effect) defining a programming language
to encode and decode data structures. As
long as you implement the primitives of the
language, third parties can implement
arbitrarily complex constructs on top of the
protocol without changing your code.
The reality, of course, is that almost all
queries fit into a tiny subset of the "language",
and that the "language" itself is so
complicated to implement (relative to other
protocols) that nobody is willing to "reinvent
the wheel".
So they all downoad the (free) CMU or UCD
SNMP library and use that.
According to ZDNet, this vulnerability was
reported to CERT by a research team one
year ago. It was only today announced in an
advisory. CERT maintained a multiple-month
window of time to suppress the advisory.
And yet, looking at the advisory, the most
important vendors don't yet have patches
. In particular, Microsoft,
Cisco, and Sun remain
vulnerable, with no released patches!
The entire rationale behind keeping
vulnerabilities quiet is to enable vendors to
fix the problem before the exploit falls into
the hands of attackers. The entire rationale
behind CERT's very existance is to act as
a clearinghouse for vulnerabilities so that
fixes can be coordinated prior to announcements. Virtually every credible
security researcher has repeatedly exclaimed
that CERT's model doesn't work. I can't
imagine a clearer vindication for CERT's
critics than this.
From the looks of this announcement, this may well be the most serious security
vulnerability ever published; it's a root hole in
literally every piece of Internet infrastructure
deployed to date (assuming lack of filtering; but remember that most networks aren't
properly firewalled off internally from customers and insiders). If CERT can't
successfully coordinate a response to this
vulnerability, why should we trust them with
any other problems?
SNMP is a bad protocol. It's
universally hated and derided by implementors. This is an amazingly great
example of the problems that spring from
shallow implementation gene pools; most
of these vulnerabilities are probably due to
code in CMU and UCD's (related) SNMP
libraries. This is an excellent example of
why it is critical to diversify
implementations of core protocols on the
Internet. Some
incredibly hardworking researchers have
been working towards these ends for years;
the network engineering community has largely responded to them with derision
. Think about this.
This problem was so subtle that it wasn't
detected for years and years, even though the
vulnerability boils down to simple buffer
overflows. This is because SNMP is an
ASN.1/BER protocol. There are like four
bazillion ways to represent a length in BER. Talented researchers have continuously reiterated
the need for simple, modular protocols to
replace the rickety ad-hoc mess we use now.
They have again met with derision from the
network engineering community. Think about
this.
Finally, the fact that SNMP is an insanely
complicated protocol has not been lost on
attackers. The very fact that CERT "accelerated" the release of this advisory
indicates that they knew attackers "could"
find some of these vulnerabilities. The
fact is that some black hats almost certainly
have worked this out. If we had published
last year, when the discovery was made,
just like the overwhelming majority of
other vulnerabilities, the problem would
have been fixed a year ago. If you manage
a large network, how do you know you
haven't already been compromised? Attackers
have had years to exploit these problems
without you knowing about it.
You mean, like this? The NTBugTraq site itself says (emphasis mine):
There is a distinct difference in the way that vulnerabilities are counted for Microsoft
This context was just added to the
SecurityFocus page. It rules that they added
the disclaimer, but don't pretend like it was
there before and WinFormant simply ignored
it.
Secondly, I'm constantly amazed at how people mis-read our stats page. The Linux aggregate stats are the total of all unique bugs across all the various distributions we track. It's supposed to answer the question "How many Linux-related bugs were there that year." It's based on things like which distro ships a particular package, and when that package is found to have a hole, it also gets attached to the distro. This is so you can look up your distro, and see what bugs you might need to patch.
Easy.
Because you didn't say so.
We know who SecurityFocus is. It's Alfred
Huger and Oliver Friedrichs and Art Wong,
the Secure Networks, Inc. crew.
Secure Networks dealt with exactly the same
problem we're talking about now: the trade
press doesn't know a damn thing about
technology and software engineering.
Everything in the trade press is based off
of newswire press releases and superficial
articles. Alf and Art and Oli had to deal with
this problem constantly as their competitors
made bogus claims about SNI and their
products.
Towards the end of their work on the Ballista
product, Alf had gotten pretty good about
educating the trade press about the issues,
or at least at swaying them towards his way
of thinking.
Alf and Oli and Elias are scrupulous guys,
and they know how the world works. It is
simply an embarassing oversight that there
aren't loud disclaimers on the vulnerability
report at your site explaining how to interpret
the results. You all know how the page is
going to be interpreted. You just saw Slashdot
interpret it the wrong way. Slashdot is dumb,
but InfoWorld is a million times dumber.
You could fix this problem right away, and
pre-empt unethical use of your data, by
releasing a statement explaining that the
numbers on the page aren't a legitimate
security metric. It won't cost you anything and
it will help (us, and you!),
Or you could act like Russ Cooper and try
to use the polarizing effect of the unexplained
numbers to generate controversy, page hits,
and press.
It's all a question of how much your credibility
means to you.
I like SecurityFocus. The people in charge of
SecurityFocus are with-it and honest. I am
completely confident that this work was done
in good faith.
However, the conclusion being drawn here is
invalid. The SecurityFocus vulnerability survey
is interesting, but it is not itself a reasonable
methodology to generate security metrics between operating systems.
I could pick nits at this ad hoc study for hours,
but the biggest problems are also the most
obvious:
First: the study associates third-party software
with the operating system, and aggregates all
the distributions together into a meaningless "Linux" category. This study is literally just
pattern matching against advisories.
Second: there is no notion of "severity" or
"impact" in the study. This is a shame, because SecurityFocus has actually put
some real effort into deriving a taxonomy of
vulnerabilities from their (enormous)
vulnerability database. There is no way to
determine whether the N Linux vulnerabilities
were equivalent to the K NT vulnerabilities.
Third: the study compares a kit of open-source software, which has received extensive peer review, to a closed-source
product. It should surprise nobody that Linux
has more documented problems than
Windows: it's actually possible to go find
vulnerabilities on Linux. Finding Windows
vulnerabilities requires black-box reverse
engineering.
Finally, both Linux and Windows do a
reasonable job of locking down server
configurations out of the box. What IT
people need to know is vulnerability
breakdown by operating system and by
deployed configuration. This study does
nothing to inform us of whether a Linux
web server is at more risk than a Windows
web server, or whether it's safer to expose
a Linux print server or a Windows print
server. Organizations that deploy homogenous Apache+NFS+ssh server
farms don't care about XFree vulnerabilities
or Samba problems.
I don't think SecurityFocus is actually trying
to make claims about the relative security
of Linux and Windows. I think they've been a
bit careless with this report though; it's a
reasonable thing to try to generate from their
database, but more thought should have gone
into presentation.
SecurityFocus has the on-staff expertise to
publish some real conclusions about the
distribution of vulnerabilities between Linux
and Windows. Before this database report
is misconstrued by the trade press, it would
be enormously helpful if they could publish a
statement about the conclusions that can be
legitimately drawn from it. It'd be good press
for them, too.
What's wrong with you people? USB audio is not a new idea, and this isn't even an amazingly good
USB audio device. Are the people here looking
for "musical laptop solutions" that bad at researching peripherals? Is it that much of a
slow news day that a minor product announcement
is headlining news?
Roland's UA-30 (years old, and cheap!) has
*more outputs* than this silly thing (from the
data sheet, the Exigy doesn't even have SPDIF
outs!) and a better interface. It's mainstream
enough that if you plug it into a Mac or a Win2k+
box, it'll just work.
You can get a Roland UA-30 USB audio device
for under $300USD. It will sound better than a
conventional sound card (D/A done outside your
laptop in a solid state device that doesn't have
its own power supply) and has RCA, TOSLink, and
SPDIF outs. They are small and well-supported.
Plan a big sweeping rewrite; idealize the system you design based on your experience with the real one. Make the design clean, simple, and flexible.
Don't build it. Instead, evaluate the code you have now and plot a course towards the idealized system. Approach the actual work of the "retrofit" incrementally. Count on having multiple customer-facing revisions of the software tagged and QA'd before the system you're delivering looks anything like the planned rewrite.
Taking baby steps towards a new design is probably the only way you'll ever migrate your project to that design. With the knowledge you've accrued working on the old system, it probably seems straightforward to start from scratch. Even if this isn't wishful thinking, though, it's a waste of time. Part of the discipline of design is an understanding of where the "hot spots" are that can't tolerate inferior implementation, and how to tell those hots spots from the spongy mass of integration, reporting, tracing, and sanitizing that is neither performance sensitive nor mutable enough to justify engineering effort.
You can take early baby steps that make it easier to make holistic changes down the road. Refactor relentlessly. Migrate code recklessly out of subsystems and into common repositories and libraries. I've found it handy to distinguish between "proper" shared library and "dumps" of utility code that
don't need scrupulously conceived interfaces.
Most importantly, design for testability. In this respect, the biggest asset you have is
the steaming lump of old Perl code you're
facing; use it to figure out the expected behavior of subsystems. Write replacements,
in modules with clean interfaces, and unit
test them. A unit test probes code (functions,
statements, internal states) --- NOT entire
programs. You'll work ten times faster when
you can move forward as a team knowing
what components you can trust and what
components you need to worry about. You'll
work ten times slower if you haven't clarified
your outputs, side effects, and return values
enough to know whether your replacement
parts are valid!
We've seen articles on Slashdot before about
this and I agree with the prevailing opinion:
rewrites are often seductive traps and time
sinks that don't offer value to customers.
A better mentality that will eventually get you
where you (think you) want to be is to adopt
a strategy of constant measurement (testing,
profiling, debugging) and improvement.
The irritating thing is that scaleable FEC schemes have been used for reliable multicast for a long, long time, but Digital Fountain (and to a lesser extent Swarmcast) are gathering accolades for what is basically a simple refinement of a very well-known technique.
Digital Fountain has been around, with product, for a long time.
The technique they are building
on for file transfer, has been around even
longer. Their protocols are even IETF
drafts/standards now.
The concept of "sending equations" instead
of data is extremely well-known. It's called
Forward Error Correction (FEC). FEC is a very
simple idea: take the source data and encode
it with parity data so that you can reconstruct
the original message from any N chunks of
it. One form of
FEC that even your stereo components might
already do is Reed-Solomon encoding; you
can look this up in CS textbooks. If you Google for "Luigi Rizzo Vandermonde", you'll find a fast, free C library for FEC that you can use in your own applications.
Digital Fountain was started by Mike Luby,
who is something of a luminary in information
theory/cryptography. The kernel of their company's IP is "tornado codes", an FEC
codec that is leaner and faster than competing codecs. The basis for their protocols, last time I checked, is FLID/DL and RLC. These protocols set up multiple channels (or "sources" if you must), each
transmitting random chunks of FEC-encoded
files.
The drawbacks to FEC are that it can take a long time to encode data for transfer, which makes FEC hard for some real-time applications like mail, and that the amount of data transferred is going to be some percentage greater than the original file (owing to parity information). But the drawback to FEC file transfers protocols is much more significant: they aren't TCP-friendly.
The whole Internet depends on protocols that have built-in congestion responses that mimic those of TCP. Protocols that don't either starve TCP flows, or are starved by them. Protocols with no real congestion response at all rapidly destabilize Internet links by consuming all available resources. Digital Fountain originally targeted multicast media transfer. Congestion avoidance in multicast schemes is still an open research question. Does this protocol really scale?
More to the point, what's the benefit? There's
obvious payoff for FEC in multicast, where backtraffic from ACKs and NAKs quickly overwhelms the group and kills performance. But in unicast-world, where we will all be living for the next decade, TCP and TCP-friendly forward-reliable protocols like SCTP already provide good performance.
Slow news week at EETimes I guess. Or Digital Fountain just hired a PR firm.
How are surround sound speakers relevant to this
discussion? Do you actually listen to music
filtered through some cheesy "concert hall"
effect?
What difference does it make if your receiver
does Dolby Digital? Your MP3s aren't an AC3
source. Receivers with "all the bells and
whistles" are often of LOWER quality than those
dedicated to doing one task well. Dolby Digital
is for movies with earth-shattering-kabooms.
Are there really people here that think a "16 bit"
sound card can't reproduce full CD audio? How
do you think they play WAV files?
It's amazing the number of completely irrelevant
factors people are bringing up here. Is there a
word for the phenomenon that occurs when someone
shells out money for something and then feels the
need to factor its presence into anything remotely
related to it?
It's also amazing that nobody is bringing up
some REAL issues:
The quality of your connectors is more important
than that of your sound card. Bring the audio to
your receiver over SPDIF or TOSLINK, not over
analog RCA cables! Sound cards --- ALL of them ---
have really awful RCA connectors.
Even SPDIF and TOSLINK aren't lossless --- but
the conveyance of waveform audio in your computer
to your audio peripherals is. Since the inside of
your computer has lots of interferance (hard
drives, power supplies), it logically makes sense
to deliver your audio as far away from your
computer as possible before converting it to send
to your receiver.
So USB audio makes a *lot* of sense for setups
that simply want to do faithful MP3 playback ---
a cheap Roland UA-30 will do SPDIF, TOSLINK,
powers itself off the bus, and can sit yards away
from your computer.
I don't understand the original question or some
of the responses regarding bit rates. I encoded
my entire CD collection at 192kbs MP3. I'm not
an audiophile by ANY means (and I don't want to
be: I'd rather not TRAIN myself not to like my
sound system!!!) --- but I *regret* doing this;
guitar and (real) drum driven music sounds awful
in a good car stereo (Pioneer+JL+DynAudio) at
192, and tolerable at 256.
Even 2 years ago disk space was cheap enough to
make 256 the reasonable choice. But when you can
get a 75G stackable firewire drive/enclosure for
less than $200, what possible incentive could
you have for encoding at less than 256?
I can't tell the difference between 256 and
anything above. VBR improves sound quality when
you set a floor of 256 and a ceiling of infinity;
otherwise, it's just a silly hack to save disk
space at the expense of your MP3 files. It may
not noticeably damage audio quality, but it sure
as hell makes your MP3 files more complex, harder
to analyze and play with/sort/etc. MP3 is just a
poor file format for what VBR asks it to do.
Another big gotcha with MP3 is joint-stereo, the
"reasonable default" in many encoders. Joint
stereo is another psychoacoustic hack that saves
an inconsequential amount of disk space at the
expense of noticeable degradation in sound
quality. It "spoofs" stereo for frequency ranges
that its model believes is hard to localize in
human ears. Make sure you nail your encoder at
real stereo.
The most painful gotcha of all, fortunately,
is one that most people have managed to avoid,
and that is that codec quality is a HUGE factor.
My original batch of 600 CDs was done with
bladeenc (mass groan!); bladeenc is/was completely
broken. People aren't kidding when they say
that Fraunhofer sounds better than random other
encoders. Fortunately LAME is a great choice.
As for Ogg: it's great that we have an open
source codec. This will come in very handy for
streaming audio delivery and for the cores of
sound engines in games or other random programs.
Because of this it's also great that Ogg is
(apparently) more efficient than MP3. One hopes
it will continue to become more and more efficient
so it can give Microsoft's compromised but
extremely efficient format a run for its money.
But since disk space isn't an issue, if you
don't trust MP3 (putting you squarely in the
minority), I'd say use Shorten or some other
lossless format before making the irrevocable
decision to put all your music into young
Ogg Vorbis. It takes a *long time* to re-encode
all of your CDs (*sob*).
Remember this: your time is far more valuable
than disk drive space. Don't encode your music
to the weak sound system you may have now:
encode it to the ideal, even if you can't exploit
it now, so that you'll be able to listen to your
music without wasting time re-encoding it later
on.
Slashdot Mirror
It's not the same; you need a homogenous build cluster (and the cluster needs to be the same as your build target) to use distributed make.
This was on Sweetcode months ago.
Clientside security is still a joke. Clients get attention in the places where they "asynchronously" give up control to foreign command, like embedded scripts in email and virtual machines for things like Java. But the overwhelming majority of client code was designed assuming that it interacts in good faith with the rest of the world.
The flood of server-side vulnerabilities will slow. Desktop environments will get more and more homogenous. The payoff for writing a single exploit will grow. You should expect not only to see more client-targetting attacks, but also more attacks leveraging the ancient and festering weaknesses in global Internet routing and in DNS.
Consider that today, Internet routing is being subverted with some regularity to play pranks on IRC and to hijack address space for spamming. These are high-risk, low-reward enterprises. It's only a matter of time before smarter people figure out how to use the same tricks to more productive ends.
No, if he's the last author on the list, it means his name is last when sorted alphabetically.
No, the primary author of a scholarly paper is always listed first, and authorship is generally sorted by merit.
If "Kahil Jallad, Jonathan Katz, and Bruce Schneier" write a paper, the abbreviation is "Jallad et al". If Schneier is the LAST author in the list, it probably means he did very little except motivate the paper and help brainstorm.
Check it out yourself..then explain what this has to do with the civil war..and why the site owner is so irresponsible in his posting of porn there. No, what's irresponsible is you adopting the mindset that the domain name system is a keyword search engine.
Pilots should be undergoing more security now, not less. A pilot's uniform and identification of good enough quality to fool an airline security screener should not be a "get through security free" card. Airline employee status is very likely to be exploited in future security mishaps, so airline employees are a wholly appropriate target of profiling and increased scrutiny.
Then you are probably unemployed. Virtually every employer does exactly this. The basic core purpose of a human resources department is to recruit and retain good employees as cheaply as possible.
Things are priced at what the market will bear, not at what they are "worth".
Obviously not, because the containers rely on the safety of the copy constructor and auto_ptr implements RAII through the copy constructor. Conceptually, aren't both part of the "STL" anyways?
This is one of the reasons Boost has a templated shared_ptr, which does reference counting instead of source/sink pointers.
This is covered in Effective C++, but it's also pretty obvious from the APIs.I question designs that want source/sink pointers in containers anyways; part of the idea behind using containers is to centralize the storage of objects.
In practice, the big problem with the STL is that Microsoft doesn't like it. ...
So they support it, but badly.
I'm not sure this is a valid criticism:
I used YDL when I first got my TiBook. I had to, because I needed 802.11 support and Apple didn't support Orinoco. I switched because I needed Firewire more than I needed Orinoco. My experiences:
YDL: Works as well as any mainstream Linux distribution. Yup works, by some definition of "works". Better still, Ximian's stuff builds from SRPMS, and Ximian now explicitly supports them with binaries. Not hard to get current, buildable kernel source, and FreeSWAN works nicely for IPsec. The (major) negative is that Firewire support blows, and it is pointless to buy hard drives that don't come in Firewire enclosures. When I left YDL, SBP2 drivers didn't work at all. The (minor) negative is that companies don't distribute closed-source binaries for YDL, and they do for X86 Linux.
OSX 10.1: A dream; xterms, xemacs, and Adobe Illustrator on the same screen. Rootless XFree86, transparent anything, beautiful user interface, antialiasing. It's faster than Linux for applications and slower for tools. The one (big) negative is that there is no credible IPsec or VPN support. A minor negative is that you can't keep current with BOTH the dev kernel AND Apple's updates.
I'm on OSX 10.1.3 now and I'm not looking back. However, I can understand why people want PPC Linux, if they already simply use Linux for everything and want good portable environments. It's good to hear that YDL continues to move forward.
Dan Bernstein has been yelling for the past few weeks since he published nfscircuit that his work does not yet apply to 1024 bit keys (or other "realistically" small key sizes).
In spite of that, stories like this one keep popping up, forcing him to defend himself from idiots who construct bogus straw-man analyses against points that he hasn't even made.
I would rather see Bernstein continue this work, and have knowledgeable people peer-review it, rather than see people waste their time discussing whether solar cells cost more money than AC power (an argument DJB had to get involved in on sci.crypt) and other such lunacy.
There are perhaps a few thousand people in the world who can credibly claim to be expert in the disciplines of computer security.
Almost nobody in the latter category is a member of the former.
Security certification is a bad idea.
Every major operating system (Solaris, Linux, Windows, BSD) has an independant implementation of TCP. None of them share significant code, each was designed with different goals. Every one of these implementations is validated against the standard, which spans multiple RFCs. The entire Internet is held from congestion collapse by cooperation amongst these implementations.
What are you talking about?
Nobody uses SNMPv3.
Nobody uses SNMPv2
Everyone uses SNMPv1
People will ALWAYS use SNMPv1. Nobody will set up a new authentication infrastructure just for SNMP. They will build ad-hoc backchannels to isolate SNMP from the rest of the Internet. They will fail repeatedly, but it won't be nearly as expensive as deploying an entire new security infrastructure for network management.
This is the same reason why nobody will ever use DNSSEC, and why everyone uses SSH. SSH did the simplest thing possible and left the infrastructure up to the consumers. DNSSEC and SNMPvNG repeatedly fucked this simple problem up by trying to mandate more of the environment than was required to get off the ground.
The reason for this is that SNMP uses an incredibly complicated wire format: ASN.1/BER. ASN.1/BER is based on the (once seductive) idea that you could avoid interoperability and extensibility problems by (in effect) defining a programming language to encode and decode data structures. As long as you implement the primitives of the language, third parties can implement arbitrarily complex constructs on top of the protocol without changing your code.
The reality, of course, is that almost all queries fit into a tiny subset of the "language", and that the "language" itself is so complicated to implement (relative to other protocols) that nobody is willing to "reinvent the wheel".
So they all downoad the (free) CMU or UCD SNMP library and use that.
Hence, everyone is vulnerable.
And yet, looking at the advisory, the most important vendors don't yet have patches . In particular, Microsoft, Cisco, and Sun remain vulnerable, with no released patches!
The entire rationale behind keeping vulnerabilities quiet is to enable vendors to fix the problem before the exploit falls into the hands of attackers. The entire rationale behind CERT's very existance is to act as a clearinghouse for vulnerabilities so that fixes can be coordinated prior to announcements. Virtually every credible security researcher has repeatedly exclaimed that CERT's model doesn't work. I can't imagine a clearer vindication for CERT's critics than this.
From the looks of this announcement, this may well be the most serious security vulnerability ever published; it's a root hole in literally every piece of Internet infrastructure deployed to date (assuming lack of filtering; but remember that most networks aren't properly firewalled off internally from customers and insiders). If CERT can't successfully coordinate a response to this vulnerability, why should we trust them with any other problems?
SNMP is a bad protocol. It's universally hated and derided by implementors. This is an amazingly great example of the problems that spring from shallow implementation gene pools; most of these vulnerabilities are probably due to code in CMU and UCD's (related) SNMP libraries. This is an excellent example of why it is critical to diversify implementations of core protocols on the Internet. Some incredibly hardworking researchers have been working towards these ends for years; the network engineering community has largely responded to them with derision . Think about this.
This problem was so subtle that it wasn't detected for years and years, even though the vulnerability boils down to simple buffer overflows. This is because SNMP is an ASN.1/BER protocol. There are like four bazillion ways to represent a length in BER. Talented researchers have continuously reiterated the need for simple, modular protocols to replace the rickety ad-hoc mess we use now. They have again met with derision from the network engineering community. Think about this.
Finally, the fact that SNMP is an insanely complicated protocol has not been lost on attackers. The very fact that CERT "accelerated" the release of this advisory indicates that they knew attackers "could" find some of these vulnerabilities. The fact is that some black hats almost certainly have worked this out. If we had published last year, when the discovery was made, just like the overwhelming majority of other vulnerabilities, the problem would have been fixed a year ago. If you manage a large network, how do you know you haven't already been compromised? Attackers have had years to exploit these problems without you knowing about it.
Why isn't anyone learning from these mistakes?
There is a distinct difference in the way that vulnerabilities are counted for Microsoft
This context was just added to the SecurityFocus page. It rules that they added the disclaimer, but don't pretend like it was there before and WinFormant simply ignored it.
Easy.
Because you didn't say so.
We know who SecurityFocus is. It's Alfred Huger and Oliver Friedrichs and Art Wong, the Secure Networks, Inc. crew.
Secure Networks dealt with exactly the same problem we're talking about now: the trade press doesn't know a damn thing about technology and software engineering. Everything in the trade press is based off of newswire press releases and superficial articles. Alf and Art and Oli had to deal with this problem constantly as their competitors made bogus claims about SNI and their products.
Towards the end of their work on the Ballista product, Alf had gotten pretty good about educating the trade press about the issues, or at least at swaying them towards his way of thinking.
Alf and Oli and Elias are scrupulous guys, and they know how the world works. It is simply an embarassing oversight that there aren't loud disclaimers on the vulnerability report at your site explaining how to interpret the results. You all know how the page is going to be interpreted. You just saw Slashdot interpret it the wrong way. Slashdot is dumb, but InfoWorld is a million times dumber.
You could fix this problem right away, and pre-empt unethical use of your data, by releasing a statement explaining that the numbers on the page aren't a legitimate security metric. It won't cost you anything and it will help (us, and you!),
Or you could act like Russ Cooper and try to use the polarizing effect of the unexplained numbers to generate controversy, page hits, and press.
It's all a question of how much your credibility means to you.
However, the conclusion being drawn here is invalid. The SecurityFocus vulnerability survey is interesting, but it is not itself a reasonable methodology to generate security metrics between operating systems.
I could pick nits at this ad hoc study for hours, but the biggest problems are also the most obvious:
First: the study associates third-party software with the operating system, and aggregates all the distributions together into a meaningless "Linux" category. This study is literally just pattern matching against advisories.
Second: there is no notion of "severity" or "impact" in the study. This is a shame, because SecurityFocus has actually put some real effort into deriving a taxonomy of vulnerabilities from their (enormous) vulnerability database. There is no way to determine whether the N Linux vulnerabilities were equivalent to the K NT vulnerabilities.
Third: the study compares a kit of open-source software, which has received extensive peer review, to a closed-source product. It should surprise nobody that Linux has more documented problems than Windows: it's actually possible to go find vulnerabilities on Linux. Finding Windows vulnerabilities requires black-box reverse engineering.
Finally, both Linux and Windows do a reasonable job of locking down server configurations out of the box. What IT people need to know is vulnerability breakdown by operating system and by deployed configuration. This study does nothing to inform us of whether a Linux web server is at more risk than a Windows web server, or whether it's safer to expose a Linux print server or a Windows print server. Organizations that deploy homogenous Apache+NFS+ssh server farms don't care about XFree vulnerabilities or Samba problems.
I don't think SecurityFocus is actually trying to make claims about the relative security of Linux and Windows. I think they've been a bit careless with this report though; it's a reasonable thing to try to generate from their database, but more thought should have gone into presentation.
SecurityFocus has the on-staff expertise to publish some real conclusions about the distribution of vulnerabilities between Linux and Windows. Before this database report is misconstrued by the trade press, it would be enormously helpful if they could publish a statement about the conclusions that can be legitimately drawn from it. It'd be good press for them, too.
USB audio device. Are the people here looking
for "musical laptop solutions" that bad
at researching peripherals? Is it that much of a
slow news day that a minor product announcement
is headlining news?
Roland's UA-30 (years old, and cheap!) has
*more outputs* than this silly thing (from the
data sheet, the Exigy doesn't even have SPDIF
outs!) and a better interface. It's mainstream
enough that if you plug it into a Mac or a Win2k+
box, it'll just work.
Check out Roland's site for more information.
Don't build it. Instead, evaluate the code you have now and plot a course towards the idealized system. Approach the actual work of the "retrofit" incrementally. Count on having multiple customer-facing revisions of the software tagged and QA'd before the system you're delivering looks anything like the planned rewrite.
Taking baby steps towards a new design is probably the only way you'll ever migrate your project to that design. With the knowledge you've accrued working on the old system, it probably seems straightforward to start from scratch. Even if this isn't wishful thinking, though, it's a waste of time. Part of the discipline of design is an understanding of where the "hot spots" are that can't tolerate inferior implementation, and how to tell those hots spots from the spongy mass of integration, reporting, tracing, and sanitizing that is neither performance sensitive nor mutable enough to justify engineering effort.
You can take early baby steps that make it easier to make holistic changes down the road. Refactor relentlessly. Migrate code recklessly out of subsystems and into common repositories and libraries. I've found it handy to distinguish between "proper" shared library and "dumps" of utility code that don't need scrupulously conceived interfaces.
Most importantly, design for testability. In this respect, the biggest asset you have is the steaming lump of old Perl code you're facing; use it to figure out the expected behavior of subsystems. Write replacements, in modules with clean interfaces, and unit test them. A unit test probes code (functions, statements, internal states) --- NOT entire programs. You'll work ten times faster when you can move forward as a team knowing what components you can trust and what components you need to worry about. You'll work ten times slower if you haven't clarified your outputs, side effects, and return values enough to know whether your replacement parts are valid!
We've seen articles on Slashdot before about this and I agree with the prevailing opinion: rewrites are often seductive traps and time sinks that don't offer value to customers. A better mentality that will eventually get you where you (think you) want to be is to adopt a strategy of constant measurement (testing, profiling, debugging) and improvement.
The irritating thing is that scaleable FEC schemes have been used for reliable multicast for a long, long time, but Digital Fountain (and to a lesser extent Swarmcast) are gathering accolades for what is basically a simple refinement of a very well-known technique.
The concept of "sending equations" instead of data is extremely well-known. It's called Forward Error Correction (FEC). FEC is a very simple idea: take the source data and encode it with parity data so that you can reconstruct the original message from any N chunks of it. One form of FEC that even your stereo components might already do is Reed-Solomon encoding; you can look this up in CS textbooks. If you Google for "Luigi Rizzo Vandermonde", you'll find a fast, free C library for FEC that you can use in your own applications.
Digital Fountain was started by Mike Luby, who is something of a luminary in information theory/cryptography. The kernel of their company's IP is "tornado codes", an FEC codec that is leaner and faster than competing codecs. The basis for their protocols, last time I checked, is FLID/DL and RLC. These protocols set up multiple channels (or "sources" if you must), each transmitting random chunks of FEC-encoded files.
The drawbacks to FEC are that it can take a long time to encode data for transfer, which makes FEC hard for some real-time applications like mail, and that the amount of data transferred is going to be some percentage greater than the original file (owing to parity information). But the drawback to FEC file transfers protocols is much more significant: they aren't TCP-friendly.
The whole Internet depends on protocols that have built-in congestion responses that mimic those of TCP. Protocols that don't either starve TCP flows, or are starved by them. Protocols with no real congestion response at all rapidly destabilize Internet links by consuming all available resources. Digital Fountain originally targeted multicast media transfer. Congestion avoidance in multicast schemes is still an open research question. Does this protocol really scale?
More to the point, what's the benefit? There's obvious payoff for FEC in multicast, where backtraffic from ACKs and NAKs quickly overwhelms the group and kills performance. But in unicast-world, where we will all be living for the next decade, TCP and TCP-friendly forward-reliable protocols like SCTP already provide good performance.
Slow news week at EETimes I guess. Or Digital Fountain just hired a PR firm.
What difference does it make if your receiver does Dolby Digital? Your MP3s aren't an AC3 source. Receivers with "all the bells and whistles" are often of LOWER quality than those dedicated to doing one task well. Dolby Digital is for movies with earth-shattering-kabooms.
Are there really people here that think a "16 bit" sound card can't reproduce full CD audio? How do you think they play WAV files?
It's amazing the number of completely irrelevant factors people are bringing up here. Is there a word for the phenomenon that occurs when someone shells out money for something and then feels the need to factor its presence into anything remotely related to it?
It's also amazing that nobody is bringing up some REAL issues:
The quality of your connectors is more important than that of your sound card. Bring the audio to your receiver over SPDIF or TOSLINK, not over analog RCA cables! Sound cards --- ALL of them --- have really awful RCA connectors.
Even SPDIF and TOSLINK aren't lossless --- but the conveyance of waveform audio in your computer to your audio peripherals is. Since the inside of your computer has lots of interferance (hard drives, power supplies), it logically makes sense to deliver your audio as far away from your computer as possible before converting it to send to your receiver.
So USB audio makes a *lot* of sense for setups that simply want to do faithful MP3 playback --- a cheap Roland UA-30 will do SPDIF, TOSLINK, powers itself off the bus, and can sit yards away from your computer.
I don't understand the original question or some of the responses regarding bit rates. I encoded my entire CD collection at 192kbs MP3. I'm not an audiophile by ANY means (and I don't want to be: I'd rather not TRAIN myself not to like my sound system!!!) --- but I *regret* doing this; guitar and (real) drum driven music sounds awful in a good car stereo (Pioneer+JL+DynAudio) at 192, and tolerable at 256.
Even 2 years ago disk space was cheap enough to make 256 the reasonable choice. But when you can get a 75G stackable firewire drive/enclosure for less than $200, what possible incentive could you have for encoding at less than 256?
I can't tell the difference between 256 and anything above. VBR improves sound quality when you set a floor of 256 and a ceiling of infinity; otherwise, it's just a silly hack to save disk space at the expense of your MP3 files. It may not noticeably damage audio quality, but it sure as hell makes your MP3 files more complex, harder to analyze and play with/sort/etc. MP3 is just a poor file format for what VBR asks it to do.
Another big gotcha with MP3 is joint-stereo, the "reasonable default" in many encoders. Joint stereo is another psychoacoustic hack that saves an inconsequential amount of disk space at the expense of noticeable degradation in sound quality. It "spoofs" stereo for frequency ranges that its model believes is hard to localize in human ears. Make sure you nail your encoder at real stereo.
The most painful gotcha of all, fortunately, is one that most people have managed to avoid, and that is that codec quality is a HUGE factor. My original batch of 600 CDs was done with bladeenc (mass groan!); bladeenc is/was completely broken. People aren't kidding when they say that Fraunhofer sounds better than random other encoders. Fortunately LAME is a great choice.
As for Ogg: it's great that we have an open source codec. This will come in very handy for streaming audio delivery and for the cores of sound engines in games or other random programs. Because of this it's also great that Ogg is (apparently) more efficient than MP3. One hopes it will continue to become more and more efficient so it can give Microsoft's compromised but extremely efficient format a run for its money.
But since disk space isn't an issue, if you don't trust MP3 (putting you squarely in the minority), I'd say use Shorten or some other lossless format before making the irrevocable decision to put all your music into young Ogg Vorbis. It takes a *long time* to re-encode all of your CDs (*sob*).
Remember this: your time is far more valuable than disk drive space. Don't encode your music to the weak sound system you may have now: encode it to the ideal, even if you can't exploit it now, so that you'll be able to listen to your music without wasting time re-encoding it later on.