Well, it might work in the short term. All content protection, whether through DRM, laws, takedown notices, or any other mechanism is fundamentally founded on the principal that "we're smarter than you are", which in the long term is always an untenable position merely because of the scale involved. For every one person they employ to defend their copyright, there are a thousand people looking for ways to break whatever measures they put in place.
For example, it is possible to design a P2P system that does not rely on trackers (e.g. the DHT scheme that TPB uses). With such a system, content is not hosted anywhere that can get a takedown notice. Combined with onion routing (crypto), you can also make it highly infeasible to determine who is actually seeding the content, nearly guaranteeing that anyone you attack is an innocent victim, thus making the courts take progressively more negative attitudes towards your attacks. Put simply, the harder they try to clamp down on P2P, the greater the security measures that will be put in place to thwart it.
You cannot compete with P2P by attacking it. You can only compete with it by providing a better experience (or at least a comparable experience) through legal channels for a price that the market is willing to bear. Start by reducing the price of Blu-Ray movies to the same price as their DVD counterparts. That alone will take a huge chunk out of P2P.
The original poster was me, and I thought it was obvious that I would also occasionally use it to play games. If I just wanted a MythTV front end, there are other ways to achieve that for significantly less money.
Actually, you really can't build a machine with better specs for less money, or at least not much less. A critical spec for a machine that goes into a media center is "small and quiet". Just dealing with the "small" part (nano-ITX, for example) is hard to do for significantly under $300 even without an optical drive, and that will get you a VIA CPU with VGA output. Want DVI? You're pretty much forced into the pico-ITX form factor and a $250 motherboard. And you still get a little toy VIA CPU.
If you can go as big as micro-ATX, you can get a real CPU and motherboard and case and come in just under $300 ($50 motherboard, $60 case, $50 HD, $60 CPU, plus probably another $50 for RAM), but you still have no Blu-Ray playback, no console gaming, etc.
Yeah, but that's like buying a pickup truck because you need to haul stuff around town and then being told, "After next month, you won't be allowed to drive it on the highway unless you permanently fill the bed with concrete." Sure, I could keep running the old firmware, but if I'm not going to also get a fully functioning gaming console out of it, I might as well use an AppleTV instead. It's about about 70 bucks cheaper, and it doesn't lock me in with any encrypted bootloader bullshit.
Terrifying that they thought this was a good idea. That said, AFAIK, Cell was never part of the POWER architecture in any way; their mainframe integration amounted to a coprocessor card to which specially-written apps could offload work.
No surprise that it got few takers; most code probably ran faster on the POWER6... with vector optimizations turned off... and the CPU scaled back to half its normal speed... and all but one core disabled....
Not to mention that IIRC, Cell basically only does one thing well: single-precision floating-point math. For certain tasks, that's great, but then again, my GPU does a good job of that, too, and I can stick several beefy ones in a computer for a whole heck of a lot less than the cost of an IBM mainframe....:-)
The funny thing about this is I actually saw a pile of PS3 boxes in Fry's yesterday and seriously considered buying one on impulse to run Linux as a MythTV front end, but my bad experiences with past Sony products held me back. Now I'm really glad I didn't pick one up. I would have returned it first thing tomorrow.
Actually, what am I saying? I kind of wish I had bought one the other day so that I could have returned it tomorrow... stick it to the Man and all that.
Why would they want to? Internet Explorer and Safari play H.264 just fine so where's the incentive for Microsoft and Apple? Google already has ffmpeg built in and most likely won't want to absorb another codec (interface).
The same reason Apple supports NPAPI, and in fact, has been a major contributor to the modernization of NPAPI recently---so that they can point to documentation and say, "Tell the developer to code their page right" instead of saying, "Sorry, that doesn't work in our browser. Use FireFox for that site." As for Internet Explorer, the only reason they're not in the same position as Apple is that they still have the dominant position. Give them a few more years of continuous market share losses, and I'm pretty sure you'll see them coming around to the importance of standards. They are already showing some indication that they "get it" inasmuch as they are supporting the <video> and <audio> tags in IE 9.
Plus, Opera's method of just leveraging codecs the system has does the same without duplicationg data and without requiring the user to figure out which website to trust when downloading codecs.
No, it really doesn't. For non-default codecs (e.g. Theora), the Opera scheme just forces the users to go out and search for the codec themselves, then download it as a system codec, and then decide whether to trust it or not. Moving the trust problem around a little does not eliminate it in any way.
Further, the design I would suggest for this programming interface is such that the user shouldn't have to care whether that plug-in from girlswithbigtits.cn is safe in the first place. The JavaScript you got from loading the page itself could do more damage. The plug-ins would not talk to the GPU. They would perform operations on blocks of data, which the browser would compile into either native CPU or GPU functions that operate on the actual data. This makes the risk of them interfering with anything else your CPU or GPU is doing fairly minimal, and the total exposed surface far, far smaller than the main JavaScript engine, or even the HTML parser or PNG renderer....
Put another way, yes, it would be a bit of an added security risk, but orders of magnitude lower than any native plug-in or codec, which is what people will end up using in the absence of such a feature.:-)
Since I'm commenting anyway, I'd like to add that such an API should also allow for "container" plug-ins (a.k.a. demuxing plug-ins) for specific container formats, which output multiple streams and tag them with a particular MIME type and provide an optional URI for a decoder plug-in for that MIME type (which the browser is allowed to ignore if it already has a built-in decoder for that type). Now, to address your points.
First, that mobile devices do the decoding in hardware, so you'd have to expose functions like 'send this H.264 stream to the ASIC,' which is not very useful in the general case.
As far as I can tell, mobile hardware is gradually moving away from using custom ICs for decoding and towards small general-purpose vector engines. For example, iPhone 3GS uses a PowerVR chip as best I can tell from a quick Google search. As such, I don't think that issue will be particularly important in the long term. Also, any such system whose CPU and GPU aren't fast enough to do a software decode would be incapable of ever supporting any other codecs anyway, making the argument moot. Ideally, the language design should be such that the code can be compiled and executed on the CPU or on a GPU, whichever is more capable. This obviously puts limits on what you can do in the language, but also greatly enhances the ability of mobile devices to tune the efficiency of playback to maximize battery life.
The second problem is what exactly to put in the API. You mention DCT, but Dirac uses DWTs, so a Dirac implementation would need to do the wavelet operations entirely in bytecode. Alternatively, you could need to force every browser to implement DWT, even if they never played back Dirac content.
Sure, throw in some wavelets. I wasn't trying to give a compete list of transforms that should be included, just the first few examples that popped into my head. Working out which math ops should be included is the sort of thing standards bodies are good at doing, so long as those mathematical transforms are not patented. Besides, if you use compiled JavaScript as I suggested, there shouldn't be a huge performance difference between a native code library and a JavaScript port of that library anyway except in the amount of time it takes to download the codec (which was the whole point of providing more math functions).... You might have to limit the use of certain JavaScript constructs, but you'd probably have to avoid those anyway to compile for a GPU, so that's probably a moot point.
Given the security holes in browsers' JavaScript sandboxing over the past few years, I'm also not completely convinced that this is more secure than just installing a CODEC once for each format that you want to play.
Such a design would be inherently a lot more secure than installing native code. For one thing, bugs in the JavaScript engine notwithstanding, you can't generate out-of-bounds memory accesses or call arbitrary native code functions using JavaScript. The ability to restrict the developer to a very limited set of calls (with no developer-accessible pointers, per se) means that they can't, for example, read and write arbitrary files on your hard drive, change random preferences, or open a port 25 connection and send a death threat to the President. Any security problems caused by bugs in the engine are likely to be present in the engine even if you don't expose this additional use of the engine, making any argument about whether this is a good idea based on that rather moot.
Besides, the point of using JavaScript was not security. The point was to create a CPU-agnostic (or even GPU-agnostic) codec API designed as a simple filter (compressed data in, uncompressed frames out). The security bit basically comes for free in such a design; it's hard for code that can only call specific functions and shares no variables (two ring buffers notwithstanding) with any other running code t
Also, maybe in some mega ISPs or some insanely complex intranet environment, you might have a DNS server that queries something other than the root server, but I suspect you could count all such installations worldwide on one hand if you used base 2. In practice, the only servers that support recursion are client-facing servers at ISPs.
And the root servers never recurse. They didn't even recurse back in the mid 1990s when I was first learning this stuff. As best I could determine, the last root server had its recursion turned off way back in 1995, five years before they moved COM to the GTLD fleet, which AFAIK have never supported recursion.
The request your DNS server sends to "ns1.google.com" may be iterative relative to the request to the root server, but it is still recursive relative to the original request. Thus, my original statement was completely correct. You just misread it.
Sure, you can learn the syntax pretty easily, but the syntax still makes it a pain in the backside every time you use it no matter how well you know it. It's just too clumsy. I mean you have:
insert into foo (bar, baz) values ("x", "y"); update foo set bar="x", baz="y";
What kind of crack do you have to smoke to come up with a query language where two of the three most common operations have a completely different syntax for no good reason? Pick one style or the other. And to a lesser degree:
create table foo (foo bigint bar bigint); alter table foo add column foo_column bigint after bar
Why not standardize that:
alter table foo add column (foo_column bigint, baz_column bigint,... ) after bar
And so on. Pretty much everywhere you look in the SQL syntax, the inconsistencies stick out like a sore thumb.
For that matter, having relationships between a single table and multiple columns in another table are the exception rather than the rule, so why not design the tree structure into the database itself so that for the 99% case, you don't have to specify all that crap in the syntax. Imagine something like this:
select fullname, subject, body from comments, users, docs where path=/path/to/foo.html;
instead of
select fullname, subject, body from comments, users, docs where path=/path/to/foo.html and comments.doc_id=docs.id and comments.user_id=users.id;
And in the case of ambiguity,
select fullname, projectname from users, projects related by project_owner; select fullname, projectname from users, projects related by project_members;
Oh, yes, and allow array data types. Having to create a separate table to associate projects with users for the above many-to-many relationship is absurd. Sure, it would probably be implemented as a table internally, but there's no reason for such an ugly implementation detail to be exposed in the syntax.
Finally, given that security in SQL is a perpetual problem, why not design a syntax in which data values cannot be specified in the syntax and must be passed out of band? If you need to enter a query manually, the client could prompt you for the values.
Odd, from what i've seen, most physicists write the worst code of all. Scientists and mathematicians gave us COBOL, BLAS, and LAPACK. They gave us functions with names like xerbla and sgemm. And so on. They tend to create code that is so brilliant that nobody can understand it except the person who wrote it, and after a few weeks, not even that person. That may not be your experience, but the experience is far from uncommon.:-)
And just to be clear, I didn't say that all musicians would be good programmers. I said that more of the good programmers that I've known are musicians than math majors by a large margin, at least among recent grads. If you look far enough back, everybody who learned programming did so in a math department, but that's just a historical artifact arising out of computers having been created originally to solve math problems. Among recent grads in computing, math is certainly a common minor, but it's not a very common major at all.
I also strongly disagree with the Wikipedia article's assertion that any significant amount of music doesn't involve problem solving. Well, maybe singing to a limited degree. Beyond that, though, that's a pretty absurd argument, IMHO.
Even basic performance involves a lot of creative problem solving, from realizing that a particular fingering doesn't lend itself to playing a given passage on piano or choosing an alternate fingering on flute for trills to listening to everyone else and choosing the right volume to blend or stand out as needed, staying with them in tempo, etc. Every single technical skill involves creative problem solving, and playing any musical instrument is necessarily a technical skill. More to the point, it's continuous creative problem solving for long periods of time in which a single mistake wrecks things.
And once you get into composition, that's doubly true. Whether you're coming up with good voice leading that avoids parallel fourth/fifth motion, ending up on the same note, or other awkwardness, dodging cross-relations between voices, creating countermelodies that obey good rules of counterpoint, or handling transpositions for different instruments (which admittedly most people just let software handle now), you're doing creative problem solving at a very high level. I actually think that composing good music is in many ways harder than writing software in terms of the amount of problem solving that you have to do (either intuitively or deliberately) at every step of the process. Try juggling 20+ independent voices in your head and you'll understand what I'm talking about.
So both composing music and performing it involve a not insignificant amount of problem solving and analysis. There's no such thing as purely artistic music, really. I have a hard time understanding how anyone who really knows music could even suggest such a concept.
Simply put, a root DNS server serves one or more root zones such as.com,.org,.cn, etc.
DNS is hierarchical. When you look up a hostname such as "www.google.com", your computer goes to a DNS server. If it happens to know the IP number for that hostname, it returns it. Otherwise, it asks a root server.
The root server, in turn, looks for "google.com" in a giant file (well, I think it's actually a database now) called a root zone and figures out which servers know how to return IP information for that domain. It then returns something along the lines of "ask ns1.google.com". Next, your local DNS server (the one your computer asked) recursively asks ns1.google.com for the IP number of "www.google.com". The ns1.google.com server could theoretically tell you to "ask ns1.www.google.com", but usually it will simply respond with an IP number.
...and this guy has a do it yourself kit in the form of a shell script.
Aw, man! And I was hoping he had written a codec as a shell script! That would be freaking awesome. (Of course, he'd also probably have to write a shell that precompiles shell scripts into native code, but....)
It's all well and good standing around hinting at what a huge compression ratio you have, but sooner or later, you're going to have to open up the throttle.
Here's a novel idea. How about the browser vendors get together and standardize on a single bytecode and API for compression codecs similar to the way they standardized the Netscape plug-in API all those years ago.
Provide a very limited API that takes a stream of data in from the browser and writes out a series of audio and video frames to a buffer, with a bunch of common math operations (FFTs/DFTs, DCTs, etc.) provided as library calls into native code. Allow the codec to provide a vector version and a non-vector version if needed.
Allow the codec (in bytecode form) to be downloaded from a web page and executed without being stored locally as a plug-in in much the same way that JavaScript is loaded now. Heck, given that most browsers compile JavaScript to native code anyway, it could even be a JavaScript codec API, so long as you provide a sufficient library of transforms so people don't have to write their own in JavaScript....
And this, ladies and gentlemen, is what happens when you edit code too many times without a regression test.
IIRC, it originally was a completely different sentence that started with "a lot of very good programmers". I ditched the original sentence and added a totally new last half and missed the extra word in the recombining process. My bad.
Someone good in math is far more likely than average to have or be able to develop expertise in any given use of computers.
Careful there. Being good at math---being capable of learning higher level math concepts---is not the same as having taken the time to do so. A lot of very people don't bother going beyond a certain point simply because their primary interests lie elsewhere. And to some degree, being too analytical can actually hurt your ability to write good software.
Writing software is not an entirely analytical process. It has some analytical components, particularly in understanding how the parts fit into the whole. However, creating the code itself is also an artistic process in many ways. You must consider all the different ways of doing something and choose the best one, based not just on the current needs, but also on a general feeling about what you might want to do with the code in the future without going overboard.
Overly analytical people often over-plan and over-design, resulting in code that is too complex to maintain, is too slow, or takes too long to finish. Getting everything perfect the first time is too important, so nothing ever gets done.
Overly artistic people tend to not plan enough, painting themselves into a corner. The result is that the entire project gets thrown out and redesigned every couple of years because they need to add a new feature and the design can't readily accommodate it.
Thus, good programming requires a very delicate balance between analytical abilities and creative/artistic abilities. Analytical skills are necessary, but not sufficient.
I would actually argue that programming skills tend to be more strongly correlated with musical ability than math education. Good musicians are generally good at analytical tasks, including math, but also have the artistic ability needed to take that critical step back and pay attention to the system design, the UI, etc.
I've always found it staggering how many of my coworkers are musicians. In my department alone, it's at least one in three, and many of the people who aren't musicians have kids who are. Whenever we have a department party, we usually get together a group of people and jam. And my previous employer was the same way.
One other problem. You would have to use a 110VAC mechanical switch to drive an additional transformer-based power circuit to provide the initial control voltage. You can't use a low-voltage switch because then you would have a power supply generating that low voltage constantly, so you would have so-called "vampire draw". A 110VAC switch is large, expensive, and failure-prone, a mechanical relay doubly so.
The electronics industry moved away from mechanical switches for very good reasons.
I assumed that the device detected not only the absence of a phone, but also its reattachment. A latch circuit occurred to pretty much all of us; the idea of the consumer manually tripping it didn't. I suppose pushing a button to start is slightly better than pushing a button to start and stop (a mechanical switch), though not a lot, and certainly not a lot when you consider how much less efficient it is. It doesn't really solve the problem. Well, it does, but only if you don't care how much more current it drains when not idle.
Assuming you can even find an electronic relay circuit that can handle 110VAC, the lowest-current 5V electronic relay circuits I've seen (which still can't handle the switched voltage required) draw on the order of 2 mA+ for the "coil" current (not counting any dissipation from the 110VAC lines you're switching). That's 10 mW, which is equal to the maximum total power that the new EU rules allow for cell phone charger standby power when plugged in and unused. Thus, for most people (who unplug their cell phones when they leave for work and plug them in when they get home), this actually is worse than a normal charger.
If you use a mechanical relay (e.g. a reed relay) instead, you're looking at about 10 mA coil current minimum, 50 mW power minimum, which means that the average person is more than 5x worse off than with a standard charger.
Now maybe they've found a way to do the switching more efficiently, but even if they did, this is still a pointless gimmick. Even if it were perfectly efficient (e.g. a mechanical switch), it would save a mere 10 mW of idle power when compared with a new charger that complies with the new EU rules. If you left such a charger plugged in 24x365, you would save a whopping 0.0876 kWh, which is less than three cents annually even at our exorbitant $0.33/kWh PG&E rates, or 0.85 cents ($0.0085) at the national average power cost. Thus, this circuit, even if it used precisely zero additional power, cannot realistically pay for itself over the expected lifetime of the product or even over the lifetime of the end user even in the most expensive retail power markets in the world.
Slashdot Mirror
They fall into the same DMCA exemption, 512(a) as ISPs that merely pass traffic. Good luck getting that changed.
Well, it might work in the short term. All content protection, whether through DRM, laws, takedown notices, or any other mechanism is fundamentally founded on the principal that "we're smarter than you are", which in the long term is always an untenable position merely because of the scale involved. For every one person they employ to defend their copyright, there are a thousand people looking for ways to break whatever measures they put in place.
For example, it is possible to design a P2P system that does not rely on trackers (e.g. the DHT scheme that TPB uses). With such a system, content is not hosted anywhere that can get a takedown notice. Combined with onion routing (crypto), you can also make it highly infeasible to determine who is actually seeding the content, nearly guaranteeing that anyone you attack is an innocent victim, thus making the courts take progressively more negative attitudes towards your attacks. Put simply, the harder they try to clamp down on P2P, the greater the security measures that will be put in place to thwart it.
You cannot compete with P2P by attacking it. You can only compete with it by providing a better experience (or at least a comparable experience) through legal channels for a price that the market is willing to bear. Start by reducing the price of Blu-Ray movies to the same price as their DVD counterparts. That alone will take a huge chunk out of P2P.
Good to know. I can't say I've paid that much attention to Cell after the rather underwhelming first version.
The original poster was me, and I thought it was obvious that I would also occasionally use it to play games. If I just wanted a MythTV front end, there are other ways to achieve that for significantly less money.
Actually, you really can't build a machine with better specs for less money, or at least not much less. A critical spec for a machine that goes into a media center is "small and quiet". Just dealing with the "small" part (nano-ITX, for example) is hard to do for significantly under $300 even without an optical drive, and that will get you a VIA CPU with VGA output. Want DVI? You're pretty much forced into the pico-ITX form factor and a $250 motherboard. And you still get a little toy VIA CPU.
If you can go as big as micro-ATX, you can get a real CPU and motherboard and case and come in just under $300 ($50 motherboard, $60 case, $50 HD, $60 CPU, plus probably another $50 for RAM), but you still have no Blu-Ray playback, no console gaming, etc.
Uh, you do realize you just replied to the "he" in your post, right? I never said I wanted to use it exclusively as a MythTV front end.
Yeah, but that's like buying a pickup truck because you need to haul stuff around town and then being told, "After next month, you won't be allowed to drive it on the highway unless you permanently fill the bed with concrete." Sure, I could keep running the old firmware, but if I'm not going to also get a fully functioning gaming console out of it, I might as well use an AppleTV instead. It's about about 70 bucks cheaper, and it doesn't lock me in with any encrypted bootloader bullshit.
Terrifying that they thought this was a good idea. That said, AFAIK, Cell was never part of the POWER architecture in any way; their mainframe integration amounted to a coprocessor card to which specially-written apps could offload work.
No surprise that it got few takers; most code probably ran faster on the POWER6... with vector optimizations turned off... and the CPU scaled back to half its normal speed... and all but one core disabled....
Not to mention that IIRC, Cell basically only does one thing well: single-precision floating-point math. For certain tasks, that's great, but then again, my GPU does a good job of that, too, and I can stick several beefy ones in a computer for a whole heck of a lot less than the cost of an IBM mainframe.... :-)
The funny thing about this is I actually saw a pile of PS3 boxes in Fry's yesterday and seriously considered buying one on impulse to run Linux as a MythTV front end, but my bad experiences with past Sony products held me back. Now I'm really glad I didn't pick one up. I would have returned it first thing tomorrow.
Actually, what am I saying? I kind of wish I had bought one the other day so that I could have returned it tomorrow... stick it to the Man and all that.
The same reason Apple supports NPAPI, and in fact, has been a major contributor to the modernization of NPAPI recently---so that they can point to documentation and say, "Tell the developer to code their page right" instead of saying, "Sorry, that doesn't work in our browser. Use FireFox for that site." As for Internet Explorer, the only reason they're not in the same position as Apple is that they still have the dominant position. Give them a few more years of continuous market share losses, and I'm pretty sure you'll see them coming around to the importance of standards. They are already showing some indication that they "get it" inasmuch as they are supporting the <video> and <audio> tags in IE 9.
No, it really doesn't. For non-default codecs (e.g. Theora), the Opera scheme just forces the users to go out and search for the codec themselves, then download it as a system codec, and then decide whether to trust it or not. Moving the trust problem around a little does not eliminate it in any way.
Further, the design I would suggest for this programming interface is such that the user shouldn't have to care whether that plug-in from girlswithbigtits.cn is safe in the first place. The JavaScript you got from loading the page itself could do more damage. The plug-ins would not talk to the GPU. They would perform operations on blocks of data, which the browser would compile into either native CPU or GPU functions that operate on the actual data. This makes the risk of them interfering with anything else your CPU or GPU is doing fairly minimal, and the total exposed surface far, far smaller than the main JavaScript engine, or even the HTML parser or PNG renderer....
Put another way, yes, it would be a bit of an added security risk, but orders of magnitude lower than any native plug-in or codec, which is what people will end up using in the absence of such a feature. :-)
Since I'm commenting anyway, I'd like to add that such an API should also allow for "container" plug-ins (a.k.a. demuxing plug-ins) for specific container formats, which output multiple streams and tag them with a particular MIME type and provide an optional URI for a decoder plug-in for that MIME type (which the browser is allowed to ignore if it already has a built-in decoder for that type). Now, to address your points.
As far as I can tell, mobile hardware is gradually moving away from using custom ICs for decoding and towards small general-purpose vector engines. For example, iPhone 3GS uses a PowerVR chip as best I can tell from a quick Google search. As such, I don't think that issue will be particularly important in the long term. Also, any such system whose CPU and GPU aren't fast enough to do a software decode would be incapable of ever supporting any other codecs anyway, making the argument moot. Ideally, the language design should be such that the code can be compiled and executed on the CPU or on a GPU, whichever is more capable. This obviously puts limits on what you can do in the language, but also greatly enhances the ability of mobile devices to tune the efficiency of playback to maximize battery life.
Sure, throw in some wavelets. I wasn't trying to give a compete list of transforms that should be included, just the first few examples that popped into my head. Working out which math ops should be included is the sort of thing standards bodies are good at doing, so long as those mathematical transforms are not patented. Besides, if you use compiled JavaScript as I suggested, there shouldn't be a huge performance difference between a native code library and a JavaScript port of that library anyway except in the amount of time it takes to download the codec (which was the whole point of providing more math functions).... You might have to limit the use of certain JavaScript constructs, but you'd probably have to avoid those anyway to compile for a GPU, so that's probably a moot point.
Such a design would be inherently a lot more secure than installing native code. For one thing, bugs in the JavaScript engine notwithstanding, you can't generate out-of-bounds memory accesses or call arbitrary native code functions using JavaScript. The ability to restrict the developer to a very limited set of calls (with no developer-accessible pointers, per se) means that they can't, for example, read and write arbitrary files on your hard drive, change random preferences, or open a port 25 connection and send a death threat to the President. Any security problems caused by bugs in the engine are likely to be present in the engine even if you don't expose this additional use of the engine, making any argument about whether this is a good idea based on that rather moot.
Besides, the point of using JavaScript was not security. The point was to create a CPU-agnostic (or even GPU-agnostic) codec API designed as a simple filter (compressed data in, uncompressed frames out). The security bit basically comes for free in such a design; it's hard for code that can only call specific functions and shares no variables (two ring buffers notwithstanding) with any other running code t
Also, maybe in some mega ISPs or some insanely complex intranet environment, you might have a DNS server that queries something other than the root server, but I suspect you could count all such installations worldwide on one hand if you used base 2. In practice, the only servers that support recursion are client-facing servers at ISPs.
And the root servers never recurse. They didn't even recurse back in the mid 1990s when I was first learning this stuff. As best I could determine, the last root server had its recursion turned off way back in 1995, five years before they moved COM to the GTLD fleet, which AFAIK have never supported recursion.
Right. Sorry, forgot that they stopped serving COM. That only changed a few years ago.
*does Google search*
Yikes. Ten years ago. I'm suddenly feeling very old. :-D
The request your DNS server sends to "ns1.google.com" may be iterative relative to the request to the root server, but it is still recursive relative to the original request. Thus, my original statement was completely correct. You just misread it.
Sure, you can learn the syntax pretty easily, but the syntax still makes it a pain in the backside every time you use it no matter how well you know it. It's just too clumsy. I mean you have:
insert into foo (bar, baz) values ("x", "y");
update foo set bar="x", baz="y";
What kind of crack do you have to smoke to come up with a query language where two of the three most common operations have a completely different syntax for no good reason? Pick one style or the other. And to a lesser degree:
create table foo (foo bigint bar bigint);
alter table foo add column foo_column bigint after bar
Why not standardize that:
alter table foo add column (foo_column bigint, baz_column bigint, ... ) after bar
And so on. Pretty much everywhere you look in the SQL syntax, the inconsistencies stick out like a sore thumb.
For that matter, having relationships between a single table and multiple columns in another table are the exception rather than the rule, so why not design the tree structure into the database itself so that for the 99% case, you don't have to specify all that crap in the syntax. Imagine something like this:
select fullname, subject, body from comments, users, docs where path=/path/to/foo.html;
instead of
select fullname, subject, body from comments, users, docs where path=/path/to/foo.html and comments.doc_id=docs.id and comments.user_id=users.id;
And in the case of ambiguity,
select fullname, projectname from users, projects related by project_owner;
select fullname, projectname from users, projects related by project_members;
Oh, yes, and allow array data types. Having to create a separate table to associate projects with users for the above many-to-many relationship is absurd. Sure, it would probably be implemented as a table internally, but there's no reason for such an ugly implementation detail to be exposed in the syntax.
Finally, given that security in SQL is a perpetual problem, why not design a syntax in which data values cannot be specified in the syntax and must be passed out of band? If you need to enter a query manually, the client could prompt you for the values.
Odd, from what i've seen, most physicists write the worst code of all. Scientists and mathematicians gave us COBOL, BLAS, and LAPACK. They gave us functions with names like xerbla and sgemm. And so on. They tend to create code that is so brilliant that nobody can understand it except the person who wrote it, and after a few weeks, not even that person. That may not be your experience, but the experience is far from uncommon. :-)
And just to be clear, I didn't say that all musicians would be good programmers. I said that more of the good programmers that I've known are musicians than math majors by a large margin, at least among recent grads. If you look far enough back, everybody who learned programming did so in a math department, but that's just a historical artifact arising out of computers having been created originally to solve math problems. Among recent grads in computing, math is certainly a common minor, but it's not a very common major at all.
I also strongly disagree with the Wikipedia article's assertion that any significant amount of music doesn't involve problem solving. Well, maybe singing to a limited degree. Beyond that, though, that's a pretty absurd argument, IMHO.
Even basic performance involves a lot of creative problem solving, from realizing that a particular fingering doesn't lend itself to playing a given passage on piano or choosing an alternate fingering on flute for trills to listening to everyone else and choosing the right volume to blend or stand out as needed, staying with them in tempo, etc. Every single technical skill involves creative problem solving, and playing any musical instrument is necessarily a technical skill. More to the point, it's continuous creative problem solving for long periods of time in which a single mistake wrecks things.
And once you get into composition, that's doubly true. Whether you're coming up with good voice leading that avoids parallel fourth/fifth motion, ending up on the same note, or other awkwardness, dodging cross-relations between voices, creating countermelodies that obey good rules of counterpoint, or handling transpositions for different instruments (which admittedly most people just let software handle now), you're doing creative problem solving at a very high level. I actually think that composing good music is in many ways harder than writing software in terms of the amount of problem solving that you have to do (either intuitively or deliberately) at every step of the process. Try juggling 20+ independent voices in your head and you'll understand what I'm talking about.
So both composing music and performing it involve a not insignificant amount of problem solving and analysis. There's no such thing as purely artistic music, really. I have a hard time understanding how anyone who really knows music could even suggest such a concept.
Simply put, a root DNS server serves one or more root zones such as .com, .org, .cn, etc.
DNS is hierarchical. When you look up a hostname such as "www.google.com", your computer goes to a DNS server. If it happens to know the IP number for that hostname, it returns it. Otherwise, it asks a root server.
The root server, in turn, looks for "google.com" in a giant file (well, I think it's actually a database now) called a root zone and figures out which servers know how to return IP information for that domain. It then returns something along the lines of "ask ns1.google.com". Next, your local DNS server (the one your computer asked) recursively asks ns1.google.com for the IP number of "www.google.com". The ns1.google.com server could theoretically tell you to "ask ns1.www.google.com", but usually it will simply respond with an IP number.
Aw, man! And I was hoping he had written a codec as a shell script! That would be freaking awesome. (Of course, he'd also probably have to write a shell that precompiles shell scripts into native code, but....)
Ooh. I know what I'm going to do today. :-D
MP3's licensing is also not too draconian, and thus, there was no reason to innovate around it.
It's all well and good standing around hinting at what a huge compression ratio you have, but sooner or later, you're going to have to open up the throttle.
Happy?
Here's a novel idea. How about the browser vendors get together and standardize on a single bytecode and API for compression codecs similar to the way they standardized the Netscape plug-in API all those years ago.
Provide a very limited API that takes a stream of data in from the browser and writes out a series of audio and video frames to a buffer, with a bunch of common math operations (FFTs/DFTs, DCTs, etc.) provided as library calls into native code. Allow the codec to provide a vector version and a non-vector version if needed.
Allow the codec (in bytecode form) to be downloaded from a web page and executed without being stored locally as a plug-in in much the same way that JavaScript is loaded now. Heck, given that most browsers compile JavaScript to native code anyway, it could even be a JavaScript codec API, so long as you provide a sufficient library of transforms so people don't have to write their own in JavaScript....
And this, ladies and gentlemen, is what happens when you edit code too many times without a regression test.
IIRC, it originally was a completely different sentence that started with "a lot of very good programmers". I ditched the original sentence and added a totally new last half and missed the extra word in the recombining process. My bad.
Careful there. Being good at math---being capable of learning higher level math concepts---is not the same as having taken the time to do so. A lot of very people don't bother going beyond a certain point simply because their primary interests lie elsewhere. And to some degree, being too analytical can actually hurt your ability to write good software.
Writing software is not an entirely analytical process. It has some analytical components, particularly in understanding how the parts fit into the whole. However, creating the code itself is also an artistic process in many ways. You must consider all the different ways of doing something and choose the best one, based not just on the current needs, but also on a general feeling about what you might want to do with the code in the future without going overboard.
Thus, good programming requires a very delicate balance between analytical abilities and creative/artistic abilities. Analytical skills are necessary, but not sufficient.
I would actually argue that programming skills tend to be more strongly correlated with musical ability than math education. Good musicians are generally good at analytical tasks, including math, but also have the artistic ability needed to take that critical step back and pay attention to the system design, the UI, etc.
I've always found it staggering how many of my coworkers are musicians. In my department alone, it's at least one in three, and many of the people who aren't musicians have kids who are. Whenever we have a department party, we usually get together a group of people and jam. And my previous employer was the same way.
One other problem. You would have to use a 110VAC mechanical switch to drive an additional transformer-based power circuit to provide the initial control voltage. You can't use a low-voltage switch because then you would have a power supply generating that low voltage constantly, so you would have so-called "vampire draw". A 110VAC switch is large, expensive, and failure-prone, a mechanical relay doubly so.
The electronics industry moved away from mechanical switches for very good reasons.
I assumed that the device detected not only the absence of a phone, but also its reattachment. A latch circuit occurred to pretty much all of us; the idea of the consumer manually tripping it didn't. I suppose pushing a button to start is slightly better than pushing a button to start and stop (a mechanical switch), though not a lot, and certainly not a lot when you consider how much less efficient it is. It doesn't really solve the problem. Well, it does, but only if you don't care how much more current it drains when not idle.
Assuming you can even find an electronic relay circuit that can handle 110VAC, the lowest-current 5V electronic relay circuits I've seen (which still can't handle the switched voltage required) draw on the order of 2 mA+ for the "coil" current (not counting any dissipation from the 110VAC lines you're switching). That's 10 mW, which is equal to the maximum total power that the new EU rules allow for cell phone charger standby power when plugged in and unused. Thus, for most people (who unplug their cell phones when they leave for work and plug them in when they get home), this actually is worse than a normal charger.
If you use a mechanical relay (e.g. a reed relay) instead, you're looking at about 10 mA coil current minimum, 50 mW power minimum, which means that the average person is more than 5x worse off than with a standard charger.
Now maybe they've found a way to do the switching more efficiently, but even if they did, this is still a pointless gimmick. Even if it were perfectly efficient (e.g. a mechanical switch), it would save a mere 10 mW of idle power when compared with a new charger that complies with the new EU rules. If you left such a charger plugged in 24x365, you would save a whopping 0.0876 kWh, which is less than three cents annually even at our exorbitant $0.33/kWh PG&E rates, or 0.85 cents ($0.0085) at the national average power cost. Thus, this circuit, even if it used precisely zero additional power, cannot realistically pay for itself over the expected lifetime of the product or even over the lifetime of the end user even in the most expensive retail power markets in the world.