Pretty good response, though I would note that even for video decoders writing to a raw framebuffer isn't desired... Writing directly to an allocated overlay in a colorspace natural to the decoding is better (that way, X provides a surface to write to that takes care of both colorspace conversion and scaling in hardware, two *Very* expensive video rendering tasks.).
I thought of that after I clicked [SUBMIT]. You're right that even video can benefit from hardware acceleration when it's available. And modern cards seem to provide both of the forms you mention -- YCC to RGB conversion, and bitmap stretching.
In general, it's hard to get great performance
from direct FB access. Direct hardware access might have been the mantra of the 320x240-ish "Mode X VGA" era, but it's "so last-Millennium." It just doesn't scale to large resolutions, varied hardware, and tons of apps. Higher-level primitives and display independence are good things, since they're the only hope for decent performance and reasonable continuing compatibility on moderm hardware. Needless communication overheads need to go -- latency is bad! -- but let's not lose the progress in the process.
Writing pixels directly to a frame-buffer is slow.
You lose all of the acceleration features of your
video card. Keeping as much of the protocol at a
high level as possible is good. The only things
that benefit from direct frame-buffer access are programs that do all their own rendering. (Think
video decoders.)
Still, if you think about it, the basic gist of your idea is to get rid of the network channel from the communication protocol, and instead have the
app talk directly to the X server, say, in shared
memory. If so, then how does your idea compare to MITSHM and Shared-Memory Transport? Or the Direct Rendering Interface for that matter? And for 2-D stuff, let's not forget the Direct Graphics Architecture extension.
Nothing stops GTK, Qt and friends from using any one
of these technologies if they'd improve performance and latency.
I've heard many times, although I have yet to verify it for myself, that Word (say, around 97 or so, at any rate) had all of Excel inside it, and when you embedded a spreadsheet, it didn't actually call Excel to edit it, but rather used its own internal code. Certainly that would add quite a bit of bulk to it.
I thought that's what OLE^H^H^HCOM or
whatever was supposed to avoid. Or am I smoking crack?
So what happens if I try to embed a Word document in an Excel spreadsheet cell?
Even with a script, some things are much
more difficult to exploit than others. Some holes require local access, a specific set of configuration options, or some other timing aspect
to key off of. For instance, heap-overflow attacks require that
the overflowable buffer get allocated next to something interesting, which, depending on the program, may or may not happen the bulk of the
time.
Compare this to a remote-root overflow vulnerability in telnet that merely requires sending 1000 bytes to in.telnetd over a remote
link. No local account needed, no special
configuration, and works every time.
So, I'd have to disagree with you -- some flaws
are much harder to exploit than others.
This is why, for instance, people harden
their machines in various manners -- making the
root fs read-only, removing exec permission for
the stack,/tmp (and in draconian circumstances) the home areas, and so on.
You lock down as many things as you can, making
it less easy to script and mount an attack.
Cutting through your sarcasm to drive the point home to the less clued:
Copyrights were originally created so that the author (not the publisher, the original author) would have exclusive rights to his or her works for a limited period. This allows them to make some profit from their works
so that they can continue to produce new works, and in general is intended to enrich the PUBLIC DOMAIN.
Since then, copyright has been subverted into a body of laws that protect publishers and their business models for practically unlimited periods. It protects them both from the authors
(who must sign over their rights to get published) and from individuals that try to access
the works. Hence the DMCA, which introduces the
concept of an access control to a copyrighted work, and which criminalizes unauthorized access to (as opposed to unauthorized copying of) the work.
I guess copyright should be split into
two concepts, copyright -- which ONLY governs copying for purpose of distribution -- and accessright -- which ONLY governs viewing and transient copies made in the process of using the work. Then maybe we have a chance of understanding why the current laws stink, and can actually fix them.
If you use Linux (or other *NIX for which it's
available), try Galeon. The Gecko rendering engine is actually quite fast. It's just the slow-ass XUL GUI that Moz implements that slows it to a crawl.
For a quick test, try scrolling down a long page by holding down the down-arrow key in both browsers if you want a graphic example of how slow Moz's GUI is. (Example works best on a slower machine, but even my Sun Blade 1000 at work chokes on that example.)
Or maybe the Slashdot regulars (not the people who hang out at 0 and -1) will look at the piece calmly and discover other very valid flaws with the study.
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 Windows and other operating systems. For instance, applications for Linux and BSD are often grouped in as subcomponents with the operating systems that they are shipped with. For Windows, applications and subcomponents such as Explorer often have their own packages that are considered vulnerable or not vulnerable outside of Windows and therefore may not be included in the count. This may skew numbers.
So, while there may be a stack of Outlook vulnerabilities, those won't get lumped in with
Windows. But sendmail vulnerabilities might get lumped in with RedHat. They go on to say (emphasis theirs):
The numbers presented below should not be considered a metric by which an accurate comparison of the vulnerability of one operating system versus another can be made.
Further, the numbers themselves do not support the conjecture that Windows 2000/NT had fewer reported vulnerabilities reported over the 5-year
period. Let's compare RedHat (the Linux distro for which the largest number of vulnerabilities was reported) vs. Windows 2000/NT from their data:
1997: RedHat 6, Win2K/NT 10
1998: RedHat 10, Win2K/NT 8
1999: RedHat 47, Win2K/NT 78
2000: RedHat 95, Win2K/NT 97
2001: RedHat 54, Win2K/NT 42
Total RedHat 212, Win2K/NT 235
So even though the numbers are potentially skewed against Linux, the totals still come up less for RedHat than for Win2000/NT.
What the other article must be doing (I haven't read it yet, since I wasn't able load it) is totalling across all distributions, which is wrong. One FTPD vulnerability would get multiplied by all the vendors that ship that FTPD, which isn't quite fair.
And mine, too.
Actually, in case you didn't recognize it, the original poster's scenario comes directly from the Terminator series. Skynet became sentient on
August 29th, 1997. (Which was, incidently, my
22nd birthday.)
Yeah, I'd like to see you email a copy of
Charmin to all your friends. The point is
that software can be copied for little marginal
cost ("just click send!"), whereas physical
objects (toilet paper, books, whatever) are
much more costly to reproduce.
As for limited-time registration -- did you read
the article? The registration keys are valid for
30 days, in that you have 30 days between the time the key is generated and when you use it.
Once registered, the software remains registered
indefinitely. And if you lose your registration
data file or for some reason don't use the key
in time, you can get another from their automated server w/out cost.
Actually, if what he is saying is true, then your modem could go to 560kbit/sec by replacing QAM with Wavelet encoding. From the sound of it, it would also be able to establish the full 560kbit over a greater range due to better noise resistance.
Do you mean voiceband modem? I doubt it. The telcos only use about 64kbps of bandwidth to send your voice over the POTS network. Your analog voice/modem signal gets converted to digital for switching purposes.
That's the reason V.90, X2 and so
on only offer the 56K speed for the download
direction -- your ISP's modems actually send
raw digital into the POTS network and can avoid
the losses associated with an analog->digital
conversion, but you the user don't get to do the
same in return.
(In case you're wondering how that works, the ISPs actually get DS1s or DS3s
with all the phone lines still aggregated together, and have special modem servers which
work with the raw, digitally encoded channels
in the DS1s or DS3s. What, did you think that
they had racks of old Sportsters and Couriers
laying around? That's so last century! If you thought that, then I bet you were wondering how
they got all those serial cables hooked to their PCs....)
We're presently getting cable modem service
via OpTel cable (I'm in an apartment). The broadband is being provided by Broadband Now /
Roadrunner. In the ~2 years we've had the service,
we've had like 3 or 4 outages that lasted more than a day. I don't think we've had any other
outages. In general, it just runs like a top. And we have
1Mbit symmetric on a mostly-static IP. Not too
shabby. (And yes, we get the advertised bandwidth
most of time. Any deviation from that bandwidth is
usually not our side's fault.)
Every time I hear someone talk about @Home or
AT&T's service, I shudder.
The OSI 7-layer model is a tool for describing networking
stacks. Actual implemented stacks may combine
one or more layers of the OSI model into a single
layer for implementation purposes.
For instance, according to TCP/IP Illustrated, Volume 2 (by the venerable but sadly deceased
W. Richard Stevens), the BSD network stack in "Net/3" maps onto the 7-level model like so:
The user process: Layer 7 (application),
layer 6 (presentation), and layer 5 (session).
The socket layer. -- no direct mapping (although I'd personally
argue it is partially in layer 5).
The protocol layer (TCP/IP, XNS, OSI, Unix): Layer 4 (transport), and layer 3 (network).
This breakdown is found on page 10, in Figure
1.3 of the aforementioned book.
So, as you can see, all 7 layers of the OSI
model are represented, even if all 7 layers
aren't individually represented as layers in
the software implementation. If nothing else,
though, the OSI model gives us a common terminology for discussing a given network stack
without getting bogged down in OS-specific terminology.
Actually, Cringley gets it wrong. Modulation happens at the PHY layer, not the LINK layer.
So either this is a crock of s**t as big as what
ZeoSync was stirring, or Cringley has his head up
his arse. Notice that that's not an exclusive-or.... both could be true.
This link pretty much covers it. I'll quote the most
relevant bits:
The Physical Layer describes the physical properties of the various communications media, as well as the electrical properties and interpretation of the exchanged signals. Ex: this layer defines the size of Ethernet coaxial cable, the type of BNC connector used, and the termination method.
The Data Link Layer describes the logical organization of data bits transmitted on a particular medium. Ex: this layer defines the framing, addressing and checksumming of Ethernet packets.
So, in other words, the Physical layer is where
signaling happens. (This is where QAM and this wavelet snakeoil are relevant.)
The Link layer is where PPP, SLIP, and Ethernet
Packet encapsulation happen. (Not Ethernet signaling, just the 802.3-or-whatever framing spec.)
Actually, the speed of an electromagnetic wave is somewhat slower in a cable than in a vacuum. How much slower is determined by the dielectric constant for the cabling's material.
This page on transmission
line theory explains things pretty well. It
actually covers the concepts that students performing the described experiment need in order
to actually get their results. It also describes some other neat things (such as the theoretical
reasons why you need a "balun" converter to connect 75ohm coax to 300ohm twinlead. It even
explains why the wire types are called 75ohm and 300ohm, if indirectly.)
If you encode your music more often than you listen to it, then this would be a problem:)
Actually, its just rather annoying that it
takes much
less time to rip a CD and cut it into WAV files
than it does to encode it. I end up enlisting
3 CPUs to do the encoding while I rip CDs.
(That is, when I get the bug to go and convert
another chunk of my CD collection to OGGs.)
The last time I did this, I also simultaneously
encoded them to MP3s, and the MP3 encoder (Lame)
ran easily 2x as fast.
Presently, I use OGG with XMMS for my "online
music", and SHN for backups/working copies of my CDs.
I've been happy with the Ogg's quality at 128kbps,
but not too impressed with encode speed. I'm not
using the latest RC yet though. Once the Ogg
tools mature a bit (ie. they reach 1.0 and switch
focus to speed rather than quality), I'm sure this
will improve.
On the lossless side, he SHN files
are nice, but decode speed on my 300MHz
box makes re-ripping seem more feasible than decoding the SHN file, say, if I need to burn a CDR to go in my disc changer in the car. (I
hate keeping originals in my disc changer in
the Texas heat.) I haven't tried FLAC yet, but
it looked reasonable from the benchmarks on the
FLAC site.
But, linux itself doesn't seem much faster either. Maybe I should go back to the 1.2 kernel...
I doubt that'll help much. A big portion of what makes a machine feel fast is its responsiveness. My Apple ][ with a 1MHz felt fast compared to many machines these days (at least when you were in text mode), since it was crisp and responsive.
Linux's responsiveness is gated in part by the latencies in the OS, and many of those don't change much as CPUs get faster. Stuff like the low-latency work and scheduler tweaks should help the feel of the machine immensely.
The Commodore 64 actually uses a 6510 CPU,
thank you very much. Also, as someone else pointed
out, you can't really overclock the C64 unless you
disable the display and cool everything else evenly, since the whole machine is tied to one clock rate.
Their claims are 100% accurate (they can compress random data 100:1) only if (by their definition) random data comprises a very small percentage of
all possible data sequences. The other 99.9999% of "non-random" sequences would need to expand. You can show this by a simple counting argument.
This is covered in great detail in thecomp.compressionFAQ. Take a look at the information on the
WEB Technologies DataFiles/16 compressor (notice
the similarity of claims!) if you're unconvinced.
You can find it in Section 8 of Part 1 of the FAQ.
Slashdot Mirror
With their feet at right angles to each other. They're really quite orthogonal to the issue, always being on the square you know.
--JoeHeck, I got 58 copies of that spam today alone!! You'd think someone was trying to tell me something.
Does the Direct Rendering Manager support help this issue? APIs such as drmGetInterruptFromBusID seem to be a good sign.
--JoeI thought of that after I clicked [SUBMIT]. You're right that even video can benefit from hardware acceleration when it's available. And modern cards seem to provide both of the forms you mention -- YCC to RGB conversion, and bitmap stretching.
In general, it's hard to get great performance from direct FB access. Direct hardware access might have been the mantra of the 320x240-ish "Mode X VGA" era, but it's "so last-Millennium." It just doesn't scale to large resolutions, varied hardware, and tons of apps. Higher-level primitives and display independence are good things, since they're the only hope for decent performance and reasonable continuing compatibility on moderm hardware. Needless communication overheads need to go -- latency is bad! -- but let's not lose the progress in the process.
--JoeWriting pixels directly to a frame-buffer is slow. You lose all of the acceleration features of your video card. Keeping as much of the protocol at a high level as possible is good. The only things that benefit from direct frame-buffer access are programs that do all their own rendering. (Think video decoders.)
Still, if you think about it, the basic gist of your idea is to get rid of the network channel from the communication protocol, and instead have the app talk directly to the X server, say, in shared memory. If so, then how does your idea compare to MITSHM and Shared-Memory Transport? Or the Direct Rendering Interface for that matter? And for 2-D stuff, let's not forget the Direct Graphics Architecture extension. Nothing stops GTK, Qt and friends from using any one of these technologies if they'd improve performance and latency.
--JoeI thought that's what OLE^H^H^HCOM or whatever was supposed to avoid. Or am I smoking crack?
So what happens if I try to embed a Word document in an Excel spreadsheet cell?
--JoeEven with a script, some things are much more difficult to exploit than others. Some holes require local access, a specific set of configuration options, or some other timing aspect to key off of. For instance, heap-overflow attacks require that the overflowable buffer get allocated next to something interesting, which, depending on the program, may or may not happen the bulk of the time.
Compare this to a remote-root overflow vulnerability in telnet that merely requires sending 1000 bytes to in.telnetd over a remote link. No local account needed, no special configuration, and works every time.
So, I'd have to disagree with you -- some flaws are much harder to exploit than others.
This is why, for instance, people harden their machines in various manners -- making the root fs read-only, removing exec permission for the stack, /tmp (and in draconian circumstances) the home areas, and so on.
You lock down as many things as you can, making
it less easy to script and mount an attack.
--JoeCutting through your sarcasm to drive the point home to the less clued:
Copyrights were originally created so that the author (not the publisher, the original author) would have exclusive rights to his or her works for a limited period. This allows them to make some profit from their works so that they can continue to produce new works, and in general is intended to enrich the PUBLIC DOMAIN.
Since then, copyright has been subverted into a body of laws that protect publishers and their business models for practically unlimited periods. It protects them both from the authors (who must sign over their rights to get published) and from individuals that try to access the works. Hence the DMCA, which introduces the concept of an access control to a copyrighted work, and which criminalizes unauthorized access to (as opposed to unauthorized copying of) the work.
I guess copyright should be split into two concepts, copyright -- which ONLY governs copying for purpose of distribution -- and accessright -- which ONLY governs viewing and transient copies made in the process of using the work. Then maybe we have a chance of understanding why the current laws stink, and can actually fix them.
--JoeIf you use Linux (or other *NIX for which it's available), try Galeon. The Gecko rendering engine is actually quite fast. It's just the slow-ass XUL GUI that Moz implements that slows it to a crawl. For a quick test, try scrolling down a long page by holding down the down-arrow key in both browsers if you want a graphic example of how slow Moz's GUI is. (Example works best on a slower machine, but even my Sun Blade 1000 at work chokes on that example.)
--JoeIf Microsoft weren't actively advocating non-disclosure of vulnerabilities, then sure -- I'd say it the other way around as well. The point is, RedHat seems eager to fix and disclose their own vulnerabilities (to the point of accidentally jumping the gun), and Microsoft seems eager to squelch discussion on theirs.
Given their stances, who would you trust to release advisories in a timely manner?
--JoeYou mean, like this? The NTBugTraq site itself says (emphasis mine):
So, while there may be a stack of Outlook vulnerabilities, those won't get lumped in with Windows. But sendmail vulnerabilities might get lumped in with RedHat. They go on to say (emphasis theirs):
Further, the numbers themselves do not support the conjecture that Windows 2000/NT had fewer reported vulnerabilities reported over the 5-year period. Let's compare RedHat (the Linux distro for which the largest number of vulnerabilities was reported) vs. Windows 2000/NT from their data:
So even though the numbers are potentially skewed against Linux, the totals still come up less for RedHat than for Win2000/NT.
What the other article must be doing (I haven't read it yet, since I wasn't able load it) is totalling across all distributions, which is wrong. One FTPD vulnerability would get multiplied by all the vendors that ship that FTPD, which isn't quite fair.
--JoeAnd mine, too. Actually, in case you didn't recognize it, the original poster's scenario comes directly from the Terminator series. Skynet became sentient on August 29th, 1997. (Which was, incidently, my 22nd birthday.)
--JoeCranking the amp too loud is bad for the computers. Or did you mean power cord ?
--JoeYeah, I'd like to see you email a copy of Charmin to all your friends. The point is that software can be copied for little marginal cost ("just click send!"), whereas physical objects (toilet paper, books, whatever) are much more costly to reproduce.
As for limited-time registration -- did you read the article? The registration keys are valid for 30 days, in that you have 30 days between the time the key is generated and when you use it. Once registered, the software remains registered indefinitely. And if you lose your registration data file or for some reason don't use the key in time, you can get another from their automated server w/out cost.
--JoeDo you mean voiceband modem? I doubt it. The telcos only use about 64kbps of bandwidth to send your voice over the POTS network. Your analog voice/modem signal gets converted to digital for switching purposes.
That's the reason V.90, X2 and so on only offer the 56K speed for the download direction -- your ISP's modems actually send raw digital into the POTS network and can avoid the losses associated with an analog->digital conversion, but you the user don't get to do the same in return.
(In case you're wondering how that works, the ISPs actually get DS1s or DS3s with all the phone lines still aggregated together, and have special modem servers which work with the raw, digitally encoded channels in the DS1s or DS3s. What, did you think that they had racks of old Sportsters and Couriers laying around? That's so last century! If you thought that, then I bet you were wondering how they got all those serial cables hooked to their PCs....)
--JoeWe're presently getting cable modem service via OpTel cable (I'm in an apartment). The broadband is being provided by Broadband Now / Roadrunner. In the ~2 years we've had the service, we've had like 3 or 4 outages that lasted more than a day. I don't think we've had any other outages. In general, it just runs like a top. And we have 1Mbit symmetric on a mostly-static IP. Not too shabby. (And yes, we get the advertised bandwidth most of time. Any deviation from that bandwidth is usually not our side's fault.)
Every time I hear someone talk about @Home or AT&T's service, I shudder.
--JoeThe OSI 7-layer model is a tool for describing networking stacks. Actual implemented stacks may combine one or more layers of the OSI model into a single layer for implementation purposes.
For instance, according to TCP/IP Illustrated, Volume 2 (by the venerable but sadly deceased W. Richard Stevens), the BSD network stack in "Net/3" maps onto the 7-level model like so:
This breakdown is found on page 10, in Figure 1.3 of the aforementioned book.
So, as you can see, all 7 layers of the OSI model are represented, even if all 7 layers aren't individually represented as layers in the software implementation. If nothing else, though, the OSI model gives us a common terminology for discussing a given network stack without getting bogged down in OS-specific terminology.
--JoeActually, Cringley gets it wrong. Modulation happens at the PHY layer, not the LINK layer. So either this is a crock of s**t as big as what ZeoSync was stirring, or Cringley has his head up his arse. Notice that that's not an exclusive-or.... both could be true.
This link pretty much covers it. I'll quote the most relevant bits:
So, in other words, the Physical layer is where signaling happens. (This is where QAM and this wavelet snakeoil are relevant.) The Link layer is where PPP, SLIP, and Ethernet Packet encapsulation happen. (Not Ethernet signaling, just the 802.3-or-whatever framing spec.)
--JoeActually, the speed of an electromagnetic wave is somewhat slower in a cable than in a vacuum. How much slower is determined by the dielectric constant for the cabling's material.
This page on transmission line theory explains things pretty well. It actually covers the concepts that students performing the described experiment need in order to actually get their results. It also describes some other neat things (such as the theoretical reasons why you need a "balun" converter to connect 75ohm coax to 300ohm twinlead. It even explains why the wire types are called 75ohm and 300ohm, if indirectly.)
--JoeActually, its just rather annoying that it takes much less time to rip a CD and cut it into WAV files than it does to encode it. I end up enlisting 3 CPUs to do the encoding while I rip CDs. (That is, when I get the bug to go and convert another chunk of my CD collection to OGGs.) The last time I did this, I also simultaneously encoded them to MP3s, and the MP3 encoder (Lame) ran easily 2x as fast.
--JoePresently, I use OGG with XMMS for my "online music", and SHN for backups/working copies of my CDs.
I've been happy with the Ogg's quality at 128kbps, but not too impressed with encode speed. I'm not using the latest RC yet though. Once the Ogg tools mature a bit (ie. they reach 1.0 and switch focus to speed rather than quality), I'm sure this will improve.
On the lossless side, he SHN files are nice, but decode speed on my 300MHz box makes re-ripping seem more feasible than decoding the SHN file, say, if I need to burn a CDR to go in my disc changer in the car. (I hate keeping originals in my disc changer in the Texas heat.) I haven't tried FLAC yet, but it looked reasonable from the benchmarks on the FLAC site.
--JoeI doubt that'll help much. A big portion of what makes a machine feel fast is its responsiveness. My Apple ][ with a 1MHz felt fast compared to many machines these days (at least when you were in text mode), since it was crisp and responsive.
Linux's responsiveness is gated in part by the latencies in the OS, and many of those don't change much as CPUs get faster. Stuff like the low-latency work and scheduler tweaks should help the feel of the machine immensely.
--JoeThe Commodore 64 actually uses a 6510 CPU, thank you very much. Also, as someone else pointed out, you can't really overclock the C64 unless you disable the display and cool everything else evenly, since the whole machine is tied to one clock rate.
--JoeHmmm...
Claims that WEB was making about Datafiles/16:
Corresponding claims that ZeoSync made:
Now, I agree, there are some notable differences, but in general, ZeoSyncs claims sound right at home with WEBs and the others on the page I linked.
Incidentally, my comment about ZeoSync's definition of "random" was unrelated.
--JoeTheir claims are 100% accurate (they can compress random data 100:1) only if (by their definition) random data comprises a very small percentage of all possible data sequences. The other 99.9999% of "non-random" sequences would need to expand. You can show this by a simple counting argument.
This is covered in great detail in the comp.compression FAQ. Take a look at the information on the WEB Technologies DataFiles/16 compressor (notice the similarity of claims!) if you're unconvinced. You can find it in Section 8 of Part 1 of the FAQ.
--Joe