Ugh, this is misleading enough that the post should probably be corrected - how many Apache HTTPD users are having fits trying to figure out how to fix this "vulnerability" ??
The sort of fool who can ask, or seriously consider, the question "Should Star Trek Die?" really doesn't "get it".
Star Trek is, above all else, an optimistic vision of a future in which humanity has successfully addressed certain critical challenges, facilitating its expansion beyond its germinal, fragile, distressed habitat into the community of the stars.
The question Kowinski is really asking is "should the conceptually tiny, creatively moribund, and increasingly irrelevant commercial aspect of Star Trek - a greedy engine focusing primarily on pandering to an unenlightened mass audience with an oatmeal-like mush of vapid books, television programs, and movies - die ??".
The answer??
Who cares! It can't affect the vision.
Kowinski's feebleminded conception and narrow world-view would appear to rule out the possibility of his (intentionally) putting together any words which might be of relevance.
The two formats do NOT do the same thing. Furthermore, MusicXML is (at least potentially) far richer than MIDI. In other words, you could generate MIDI from MusicXML, but not vice-versa.
You can do a lame job of creating a score from MIDI, but there is so much information missing that much human editing would be required to create a "technically correct" score. It's the computer equivalent of transcribing a score from listening to a performance. That's what Midi is, a (fairly crude) performance.
MusicXML, on the other hand, is intended to complete represent every nuance necessary to represent a complex musical score.
MusicXML is a data format for representing musical scores, to be used by, and between, computer programs. It is not intended to be used by humans!!
Rather, you will use some computer software to transcribe, say, a real-time performance into a score, which will be represented as MusicXML on your computer's disk. Or, you will use a software tool to create a new score, from scratch, which the software will store to disk as MusicXML.
The fact that it is somewhat readable is just a side benefit of XML and the words chosen as tag names by the designers of the MusicXML DTD.
It's all about open and standard representation of rich, hierarchical information - XML is just the first widely used, portable, easy to use, domain-neutral way of representing hierarchical information.
XML is the first data representation to recognize that, from the perspective of DTD (domain) authors and software developers, these kinds of things are of the highest importance:
* we can re-use the same damn Xerces parser to read and write ANY XML document (rather than building new domain-specific parsers, over and over again, for arcane file formats which nobody but the creator will ever understand),
* we can make straightforward extensions to the format which don't necessarily BREAK existing software,
* XML is human-readable enough to readily facilitate human sanity-checking of complex documents,
What's NOT important is that we be able to represent Beethoven's 9th Symphony in 27 bits!
Last time I checked, the computer on my desktop had 1GB of RAM and over 100 GB of disk space... I can comfortably fit 10^5, very beefy, 1000-note songs on my computer without breaking a sweat, and without doing any compression (XML tends to compress very well, by the way - even without XML-specific compression).
On top of that, XML is slowly replacing HTML as the lingua franca of the internet, and of information representation in general. The portability of information engendered by the efforts of organzations such as OASIS, and by DTD's like RSS, RDF, and SOAP would not be possible without a technology like XML at the core.
Don't misunderstand - the folks who have been using XML to make over the world of information don't "love" XML - they just recognize that any equally useful alternative would be just another flavor of the same juice.
And just because it's XML don't mean it's good - there are lots of crummy DTD's designed by people who don't "get it". But that's not XML's problems - and cooperative standards organizations are supposed to keep the overall quality at least high enough to be useful.
Get a clue. The last of you XML bashers will be dead long before XML hits its peak.
Actually, distance from equator has a lot less to do with how well photovoltaic solar energy works at a given location than was indicated above.
The federal government (I forget which dept.) publishes seasonal tables every year which indicate, among other things, the SOLAR INSOLATION for many cities and areas in North America. Solar insolation is measured in equivalent hours per day of "full intensity" sun - and latitude is only one factor which affects it.
It turns out that the sun, at peak intensity, radiates energy with an magnitude of about 1KW/M^2 at the surface of the earth.
The tables indicate, for example, that Pittsburgh's solar insolation is something like this:
Summer months: ~4 hours / day Winter months: ~1.5 hours / day Annual average: ~3 hours / day
So, on an average summer day, a square meter of Pittsburgh earth receives about 400W of solar radiation. At the same time, southern S. Dakota (at the same latitude) is getting over 600W!
Seasonal weather conditions (cloud cover) have at least as much affect as latitude. There are a number of cities north of Pittsburgh which have much greater solar insolation than Pittsburgh.
See Joel Davidson's "The New Solar Electric Home" for more info:
Gee, I could provide for my total power needs in the summer (about 1200 KWH/month) with only 10 square meters of PV panels, right??
Unfortunately, NO. With PV efficiencies in the 12-13% range, plus I^2R losses, battery efficiency, etc. I would need more like 100 square meters with present-day technology.
Well, on further reflection, I neglected the fact that Vonage is not a "pure play" VOIP company: they offer gateways to the POTS telcos.
As a first shot at policy, I would suggest that the laws/regulations which apply should be those which would apply for a POTS call made between the gateway city and the POTS recipient of the call.
So:
If I make a Vonage call from Minnesapolis to New York City, which happens to ride the internet from Minneapolis to Vonage's NYC telco gateway, it should be viewed for regulatory purposes as a POTS call from the NYC gateway to the NYC callee.
And technically, only those regs which apply for the "Central Office to callee" half of the connection should apply - NOT those which apply for "caller to CO".
The only time the state of Minnesota would be in the loop would be when a telco gateway INSIDE Minnesota was involved in the call.
In the case of a "pure" VOIP-VOIP call, no POTS regulations would apply.
A VOIP "provider" at the core just offers a simple directory service!!
The voice data packets travel over the internet between the client applications!! As a rule, the VOIP "provider" is NOT INVOLVED in the call once the two (or N) phones have established communications...
HENCE...
It is impossible to meaningfully compare the services offered by a LEC monopoly with the simple software mapping / proxy / etc. services offered by a VOIP provider!!
The REAL "providers" of service for a VOIP "phone call" are (1) client 1's ISP, (2) client 2's ISP, and (3) the backbones over which their RTP packets are routed!!
Has anybody checked the crack these frosty old farts are smoking?? My opinions of white-haired Minnesotans is not bettered by this decision....
Let's fix this once and for all by locating directory and proxy services in adjacent countries not subject to the foolish laws of the country where the service is used!
Sheesh - I can't believe that, in the 21st century, anybody would still want to put sound cards in a central server and pipe ANALOG around the home??
Make a centralized server which uses a modern set of protocols (RTP, RTSP, RTCP, over UDP, etc.) to transmit multiple sessions of multicast streamed audio and video. The vlc/vls client/server is just one example of an open source system offering most, if not all, of these capabilities.
Some open source systems let you use a local client to control a back channel to get "remote control" capabilities over a chosen stream.
Put Cat5e+ or Cat6 cable in the walls. You will want at least 100mbit ethernet all around to handle the bandwidth requirements (presumably you will want video eventually.) Using at least Cat5e+ lets you upgrade to at least 1Gbps without ripping the wire out of the walls...
Or you can do it wirelessly with 802.11g (802.11b is too slow for quality video, esp. if you want real-time), either instead of wire or as an adjunct to wire.
Put thin clients all around your house. Each thin client (and each fat networked machine) can serve as a remote presentation terminal for your audio/video/multimedia broadcasts. Assuming a low-latency, high-bandwidth network, high quality source material, and server with the right stuff, the quality (audio, video) at the individual terminal is limited only by the presentation components (DAC/amplifier/speakers for audio, video card/display for video, etc..) in that terminal.
Something like this is a better alternative to running grungy, noisy line level analog audio all over the place...
While you're at it, use your thin clients as SIP VOIP telephones, then you can get rid of the phone wires, the legacy phones, AND the audio cables..
Then, for even more fun, integrate this system with your RFID tag-based badge system (or video face recognition system) so that your program of choice will follow you around the house from room to room!
The "cell phone-like" systems to which many readers keep referring are primitive "radiotelephone" or "mobile phone service" systems. These were basic, analog, channelized two-way radios with a telephone handset, and a central dispatch office with a trunk to the telco - little better than walkie-talkies communicating with a base station.
More sophisticated systems had multiple "repeater" stations linked by phone lines to allow better coverage. Even this enhancement did not really make these dinosaurs practical for the masses.
They were sorely limited in all regards, and made very poor use of spectral resources compared to today's state of the art. They were available in most major metro areas, and a number of smaller ones, but could handle such a small number of simultaneous users that they could not practically be deployed on a wide scale.
Although the theoretical underpinnings for the modern cell phone - at least the original analog variety - were relatively mature in the 1960's, at least two key developments, and a substantial amount of engineering, precluded the appearance of something like AT&T's Advanced Mobile Phone System (AMPS) - which is what we call 1G cell technology - until the late 1970's at the earliest:
The microprocessor (uP) and the programmable read-only memory (PROM) (Intel, 1971)
The complexity of the control software used even in first-generation cell phones - handling, among other things, control requests from the cell site to change to a different pair of frequencies and "handoff" to another cell site - pretty much precluded pure-hardware implementations this early in the game.
Low cost solid state devices able to operate
at 1 GHz (Motorola and a few others, early 1970's)
High-frequency solid state devices and microstripline circuitry made possible the RF tranmitter and receiver components needed to build reasonably portable cell phones.
Although devices working at somewhat lower frequences were available in the 1960's, there simply wasn't enough free spectrum space that low
in the RF spectrum for practical deployment of a cell phone system which could support many users.
----
These two developments, plus an enormous amount of elbow grease, allowed AT&T to deploy AMPS in Chicago in 1983 (right before the Consent Decree broke them up into the Baby Bells) - the world's first high-capacity cell-based full-duplex communication system,
featuring frequency re-use among cells, frequency-agile base stations and portable (customer) units, providing connections between
each other and the public switched telephone network (PSTN), and offering a user interface nearly identical to the standard POTS telephone!!
Slashdot Mirror
Ugh, this is misleading enough that the post should probably be corrected - how many Apache HTTPD users are having fits trying to figure out how to fix this "vulnerability" ??
The sort of fool who can ask, or seriously consider, the question "Should Star Trek Die?" really doesn't "get it".
Star Trek is, above all else, an optimistic vision of a future in which humanity has successfully addressed certain critical challenges, facilitating its expansion beyond its germinal, fragile, distressed habitat into the community of the stars.
The question Kowinski is really asking is "should the conceptually tiny, creatively moribund, and increasingly irrelevant commercial aspect of Star Trek - a greedy engine focusing primarily on pandering to an unenlightened mass audience with an oatmeal-like mush of vapid books, television programs, and movies - die ??".
The answer??
Who cares! It can't affect the vision.
Kowinski's feebleminded conception and narrow world-view would appear to rule out the possibility of his (intentionally) putting together any words which might be of relevance.
Arggghhh!!
MIDI != MusicXML
The two formats do NOT do the same thing. Furthermore, MusicXML is (at least potentially) far richer than MIDI. In other words, you could generate MIDI from MusicXML, but not vice-versa.
You can do a lame job of creating a score from MIDI, but there is so much information missing that much human editing would be required to create a "technically correct" score. It's the computer equivalent of transcribing a score from listening to a performance. That's what Midi is, a (fairly crude) performance.
MusicXML, on the other hand, is intended to complete represent every nuance necessary to represent a complex musical score.
Sorry, dude, you don't get it either.
MusicXML is a data format for representing musical scores, to be used by, and between, computer programs. It is not intended to be used by humans!!
Rather, you will use some computer software to transcribe, say, a real-time performance into a score, which will be represented as MusicXML on your computer's disk. Or, you will use a software tool to create a new score, from scratch, which the software will store to disk as MusicXML.
The fact that it is somewhat readable is just a side benefit of XML and the words chosen as tag names by the designers of the MusicXML DTD.
You XML bashers just don't get it, do you...
It's all about open and standard representation of rich, hierarchical information - XML is just the first widely used, portable, easy to use, domain-neutral way of representing hierarchical information.
XML is the first data representation to recognize that, from the perspective of DTD (domain) authors and software developers, these kinds of things are of the highest importance:
* we can re-use the same damn Xerces parser to read and write ANY XML document (rather than building new domain-specific parsers, over and over again, for arcane file formats which nobody but the creator will ever understand),
* we can make straightforward extensions to the format which don't necessarily BREAK existing software,
* XML is human-readable enough to readily facilitate human sanity-checking of complex documents,
What's NOT important is that we be able to represent Beethoven's 9th Symphony in 27 bits!
Last time I checked, the computer on my desktop had 1GB of RAM and over 100 GB of disk space...
I can comfortably fit 10^5, very beefy, 1000-note songs on my computer without breaking a sweat, and without doing any compression (XML tends to compress very well, by the way - even without XML-specific compression).
On top of that, XML is slowly replacing HTML as the lingua franca of the internet, and of information representation in general. The portability of information engendered by the efforts of organzations such as OASIS, and by DTD's like RSS, RDF, and SOAP would not be possible without a technology like XML at the core.
Don't misunderstand - the folks who have been using XML to make over the world of information don't "love" XML - they just recognize that any equally useful alternative would be just another flavor of the same juice.
And just because it's XML don't mean it's good - there are lots of crummy DTD's designed by people who don't "get it". But that's not XML's problems - and cooperative standards organizations are supposed to keep the overall quality at least high enough to be useful.
Get a clue. The last of you XML bashers will be dead long before XML hits its peak.
Actually, distance from equator has a lot less to do with how well photovoltaic solar energy works at a given location than was indicated above.
9 37 948047/qid=1065134484/sr=1-1/ref=sr_1_1/103-468497 9-8794204?v=glance&s=books
The federal government (I forget which dept.) publishes seasonal tables every year which indicate, among other things, the SOLAR INSOLATION for many cities and areas in North America. Solar insolation is measured in equivalent hours per day of "full intensity" sun - and latitude is only one factor which affects it.
It turns out that the sun, at peak intensity, radiates energy with an magnitude of about 1KW/M^2 at the surface of the earth.
The tables indicate, for example, that Pittsburgh's solar insolation is something like this:
Summer months: ~4 hours / day
Winter months: ~1.5 hours / day
Annual average: ~3 hours / day
So, on an average summer day, a square meter of Pittsburgh earth receives about 400W of solar radiation. At the same time, southern S. Dakota (at the same latitude) is getting over 600W!
Seasonal weather conditions (cloud cover) have at least as much affect as latitude. There are a number of cities north of Pittsburgh which have much greater solar insolation than Pittsburgh.
See Joel Davidson's "The New Solar Electric Home" for more info:
http://www.amazon.com/exec/obidos/tg/detail/-/0
Gee, I could provide for my total power needs in the summer (about 1200 KWH/month) with only 10 square meters of PV panels, right??
Unfortunately, NO. With PV efficiencies in the 12-13% range, plus I^2R losses, battery efficiency, etc. I would need more like 100 square meters with present-day technology.
Sigh.
No, Amazon uses a lot of stuff - but they use MOSTLY Java.
Well, on further reflection, I neglected the fact that Vonage is not a "pure play" VOIP company: they offer gateways to the POTS telcos.
As a first shot at policy, I would suggest that the laws/regulations which apply should be those which would apply for a POTS call made between the gateway city and the POTS recipient of the call.
So:
If I make a Vonage call from Minnesapolis to New York City, which happens to ride the internet from Minneapolis to Vonage's NYC telco gateway,
it should be viewed for regulatory purposes as a POTS call from the NYC gateway to the NYC callee.
And technically, only those regs which apply for the "Central Office to callee" half of the connection should apply - NOT those which apply for "caller to CO".
The only time the state of Minnesota would be in the loop would be when a telco gateway INSIDE Minnesota was involved in the call.
In the case of a "pure" VOIP-VOIP call, no POTS regulations would apply.
A VOIP "provider" at the core just offers a simple directory service!!
The voice data packets travel over the internet between the client applications!! As a rule, the VOIP "provider" is NOT INVOLVED in the call once the two (or N) phones have established communications...
HENCE...
It is impossible to meaningfully compare the services offered by a LEC monopoly with the simple software mapping / proxy / etc. services offered by a VOIP provider!!
The REAL "providers" of service for a VOIP "phone call" are (1) client 1's ISP, (2) client 2's ISP, and (3) the backbones over which their RTP packets are routed!!
Has anybody checked the crack these frosty old farts are smoking?? My opinions of white-haired Minnesotans is not bettered by this decision....
Let's fix this once and for all by locating directory and proxy services in adjacent countries not subject to the foolish laws of the country where the service is used!
I'm sure this grievous oversight will be correcte d in the next edition.
-mdz
Sheesh - I can't believe that, in the 21st century, anybody would still want to put sound cards in a central server and pipe ANALOG around the home??
Make a centralized server which uses a modern set of protocols (RTP, RTSP, RTCP, over UDP, etc.) to transmit multiple sessions of multicast streamed audio and video. The vlc/vls client/server is just one example of an open source system offering most, if not all, of these capabilities.
Some open source systems let you use a local client to control a back channel to get "remote control" capabilities over a chosen stream.
Put Cat5e+ or Cat6 cable in the walls. You will want at least 100mbit ethernet all around to handle the bandwidth requirements (presumably you will want video eventually.) Using at least Cat5e+ lets you upgrade to at least 1Gbps without ripping the wire out of the walls...
Or you can do it wirelessly with 802.11g (802.11b is too slow for quality video, esp. if you want real-time), either instead of wire or as an adjunct to wire.
Put thin clients all around your house. Each thin client (and each fat networked machine) can serve as a remote presentation terminal for your audio/video/multimedia broadcasts. Assuming a low-latency, high-bandwidth network, high quality source material, and server with the right stuff, the quality (audio, video) at the individual terminal is limited only by the presentation components (DAC/amplifier/speakers for audio, video card/display for video, etc..) in that terminal.
Something like this is a better alternative to running grungy, noisy line level analog audio all over the place...
While you're at it, use your thin clients as SIP VOIP telephones, then you can get rid of the phone wires, the legacy phones, AND the audio cables..
Then, for even more fun, integrate this system with your RFID tag-based badge system (or video face recognition system) so that your program of choice will follow you around the house from room to room!
-mdz
More sophisticated systems had multiple "repeater" stations linked by phone lines to allow better coverage. Even this enhancement did not really make these dinosaurs practical for the masses.
They were sorely limited in all regards, and made very poor use of spectral resources compared to today's state of the art. They were available in most major metro areas, and a number of smaller ones, but could handle such a small number of simultaneous users that they could not practically be deployed on a wide scale.
Although the theoretical underpinnings for the modern cell phone - at least the original analog variety - were relatively mature in the 1960's, at least two key developments, and a substantial amount of engineering, precluded the appearance of something like AT&T's Advanced Mobile Phone System (AMPS) - which is what we call 1G cell technology - until the late 1970's at the earliest:
-
The microprocessor (uP) and the programmable read-only memory (PROM) (Intel, 1971)
-
Low cost solid state devices able to operate
at 1 GHz (Motorola and a few others, early 1970's)
----The complexity of the control software used even in first-generation cell phones - handling, among other things, control requests from the cell site to change to a different pair of frequencies and "handoff" to another cell site - pretty much precluded pure-hardware implementations this early in the game.
High-frequency solid state devices and microstripline circuitry made possible the RF tranmitter and receiver components needed to build reasonably portable cell phones. Although devices working at somewhat lower frequences were available in the 1960's, there simply wasn't enough free spectrum space that low in the RF spectrum for practical deployment of a cell phone system which could support many users.
These two developments, plus an enormous amount of elbow grease, allowed AT&T to deploy AMPS in Chicago in 1983 (right before the Consent Decree broke them up into the Baby Bells) - the world's first high-capacity cell-based full-duplex communication system, featuring frequency re-use among cells, frequency-agile base stations and portable (customer) units, providing connections between each other and the public switched telephone network (PSTN), and offering a user interface nearly identical to the standard POTS telephone!!
It WAS black magic...