How would they discriminate between adverse and beneficial changes? A shutdown of global ocean currents, as was the state (IIRC) roughly 10,000-14,000 years ago, will screw the world as we know it hard. Such a shutdown is believed to be a likely effect of a global increase in temperatures. The mechanism is roughly: temperatures rise causing ice packs to melt. This in turn desalinates the ocean. Lower salinity shuts down the deep ocean "salt pumps" which are the major force driving the currents. Once the currents shut down, they no longer act as powerful climate moderators, returning us to a time when radical and rapid climactic swings were the norm. Around the same time the current ocean currents formed, bringing that relative climactic stability, modern agriculture started. I.e. it became possible within a region to predict what crops could be planted and flourish year-over-year.
Beyond general scientific data collection, monitors such as this are useful to determine whether major changes in the newly discovered current are in progress and to track those changes against climactic effects. I know all this sounds passe compared to making up conspiracies based on oversimplifications and stereotypes, but it's a hell of a lot more useful.
other operating systems should be able to adopt similar features quickly! Doubtful. This is more than a case of "just software"; it's a sophisticated collaboration of hardware plus software. Apple bought a company called Fingerworks, founded by Wayne Westerman and his Ph.D. advisor based on his doctoral research[1]. They sold mouse-pad sized touchpad devices with gesture recognition as well as zero-force keyboards with integrated mousing/gesturing. These multi-touch devices effectively do low-resolution EMF imaging of the hand near the surface. No "mis-touches", the keyboard didn't generate false hits from "resting" on the surface, etc.
Fingerworks vanished off the face of the internet a couple of years back. Apple quietly bought the company, its patents, and and the key researchers and engineers. Since then, they've been puting the Apple shine on their technology since then. Much to the likely delight of the "Fingerfans" the iPhone is the first product to ship with this technology since Fingerworks' was bought.
It *might* be possible to hack something together with a synaptics pad, but the hardware itself is likely deficient to do full-on multitouch. See section 1.3 of Westerman's thesis, linked below, esp. the pre-Fingerworks prototype hardware "producing a 50 frames per second (fps) stream of proximity images." I note that the Fingerworks devices connected via USB, but had on-device processing and firmware notably richer than what's in a simple touchpad. That alone may spell death to attempts at pure host-side multitouch with a "dumb" touchpad.
The reason a sdk isn't available is because they'd never planned for one originally. Yes, you're a troll. But let me be clear about the kind: you have identified yourself as a gum-flapping moron who's never shipped code worth a damn in your life, especially an SDK for external developers. (And before anyone asks, yes, I have done both. In the same product, even.)
It's VERY hard to ship a new embedded platform in a timely manner with an SDK that supports arbitrary third-party development for a new product. So hard, that it's almost never the right answer to hold off ship to wait for an SDK. An organization is much better off shipping the working, robust 1.0 product into customer's hands and use that experience to build a quality SDK and toolchain. The platform itself is a sea of unknown problem domains ("arr, here be dragons!") for a "version 1.0" product like the iPhone.
That's their job. I call bullshit. It may be a natural result of human greed combined with the rules of corporate operation, but that doesn't make it "their job". Fucking over "the other guy", writ large, is not a socially acceptable way of life. Simply put, there is no room for faceless ignorance of human needs and social good in constructs such as corporations. Period. Everyone must come to expect, and demand, better behavior. This thinking essentially shields corporate management from responsibility, law and precedent effectively shields shareholders from responsibility... leaving a huge ethical loophole wherein the people to get screwed. At least until the damage is already long-done and someone sues.
When hardware companies try to make software, the result is almost inevitably shit. There are some exceptions, but big hardware companies tend to see software development as a 'cost center,' an afterthought to be minimized as much as possible, rather than a critical and major part of their product. Actually, even when the problem isn't one of a cost-center mentality, the technical staff and technical management in hardware companies often doesn't really understand software development from any of design, lifecycle, or team process viewpoints. I've seen this cultural assumption that software somehow just naturally derives from the existence of the hardware.. that because hardware design can be difficult, that software must be trivial. This blindness in turn costs the company money for two reasons.
The first is hardware engineers who don't see their work as providing clean, semantically sound "APIs" against which the software must operate. Worst case I've seen of this was a chip maker that had to scrap a set of new masks and tape-out again. Oops. We didn't need that 1,000,000 USD anyways.
The second, a generalization of the above, is that the product of a hardware company is almost always a synergy of hardware and software. This applies even when the hardware company isn't the producer of the software. E.g. a general purpose CPU design won't succeeed if it has flaws that make it difficult to compile correct or performant sofware; a video card without drivers and/or specifications is useless; and so forth.
So what are the waste products of the sugar based process, and what are the issues (disposal/reuse/energy to manage) surrounding dealing with the non H2 byproducts?
If it was any other way, then a crooked merchant could literally sit there defruading the government/credit card co. This is only true for unverifiable payment methods, such as cash or credit cards. Note that the CC authorization only covers the issuer's end of things, but does nothing to ensure that the card holder authorizes the transaction.
A payment system that verified the transaction with both the issuer and the card holder would have to be resistant to merchant tampering.
Ahem. The normal userbase of a bug tracking program is not composed of coders and engineers? Sure, but expecting coders and engineers to be good interface designers is like expecting lumberjacks to all make violins like Stradivarius. After all, the violin's just made of wood, right?
Now if only Apple notebooks had two mouse buttons instead of hacks around it.:) IMO, on the Intel-generation Apple notebooks, the two-finger + click is better than having a second button. Two-finger scrolling is awesome, and once you're used to that, it's so much easier to just put down two fingers and click to get the context menu. No contorting hand positions to hit that button. Heck, if it's a long menu that scrolls, you can open it with two-fingers+click then scroll around it quickly. Very sweet.
If you know where and how to use [GOTOs], they actually are a sensible choice. For folks lacking the historical background: Dijkstra's stake in the ground against GOTOs has a number of positive merits. First, higher-level control constructs, now ubiquitous, such as the various loops, if-then-else, etc. are much better at explaining the programmer's intent than GOTOs. This makes it easier to write and maintain correct code, and had substantial impacts on the ability of compilers to optimize that code.
The parent's example is a good one, and has been addressed by various exception handling control structures in post-C languages. One useful case that has made it into very few languages is multi-level break: a break statement that accepts a parameter, the number of levels of control to escape. A break(2) call would thus exit two levels of containing loops. It's not an incredibly common situation, but it can be very handy for certain kinds of data structure traversals, some nested state machine implementations, etc. Alas, out comes that ugly GOTO.
And exactly two of them have a chance in hell of actually being elected. And THIS is exactly why it is imperative that single-option voting be banished from the U.S.A. There are a number of voting systems of interest, such as Instant Runoff Voting (IRV) and Condorcet. In these systems, voters rank all candidates in order of preference instead of casting a single yes-vote for one candidate. In such a system, a voter never has to fear to vote their conscience because a despised candidate might win due to a fragmentation of the voter base.
Over time, this would enable viable third parties and independent candidates to 1) exist meaningfully and 2) eventually flourish. Why? Once voters are free to vote their view on all candidates, serious candidates can contemplate a non-Democrat, non-Republican affiliation without fear of being completely stonewalled at the voting booth.
Alone, rank-based voting may not be sufficient to increase political diversity in the US, but it's almost certainly necessary.
We can leave the motivation of non-companies to another discussion, since your question did not touch upon it, but they often have reasons to want a sharing with rules (GPL) license over a gift (BSD) license. One notable instance where creators (companies or no) often prefer a gift license over a sharing with rules license is when the software promotes a standard, where adoption of the standard (and a uniform reference platform for same) is often more important than the implementation itself.
Thunderbird, the only desktop client I can stand using ??? I use Thunderbird at work, primarily because it's been a choice between it and Outlook. But Thunderbird's mail editor is possibly the worst of any of the modern apps. It suffers from a flaw I thought was confined to the stupidity of MS Word: it is possible to delete invisible formatting marker, mangling the document's formatting. Backspace, backspace, OOPS, your document formatting is hosed. Even worse, sometimes this flaw causes the editor to expose underlying HTML/XML gunk in the editor.
You might think you could get around all this via editing in plaintext mode, eh? No dice. There is effectively no first-class plaintext mode in Thunderbird's mail editor. E.g. you can change to "plaintext" mode, but all it does is hide the formatting bar.. any fonts in the document remain, but now you can't change them, even to make them fixed width. Pasting into a "plaintext" editor preserves the original formatting -- including the big fonts and glaring colors from that web page you just copied from. So much for WYSIWYG -- there's no way to actually see what the mailer will send out with plain text formatting. You just have to smack it all to "fixed width" and hope for the best.
Aside from that, Thunderbird's mail filtering is fairly functional and does what I want. It seems to handle large email boxes allright, but its search is pretty slow.
Expecting phone companies to protect your records from the government is like trying to get a home loan without revealing your credit history. Good luck with that one. In the case of getting a home loan without revealing credit history, that's asking another entity to take one hell of a financial risk on you without any knowledge of your financial reliability. That's rather unreasonable.
While I do agree about the here-and-now practical circumstances of the phone companies in the US, that doesn't change the fact that it is reasonable to expect that government must go through due process to acquire private information about its citizens. Likewise, phone companies (and other non-gov't entities) should be held accountable for participating in any breaches of due-process access to private information.
He's not trying to "preach" in any sense of the word. He has no political or social agenda. He's not even asking that anyone accept his words on faith alone.
Here's a deeper difference: if someone went so far as to experimentally prove this idea right OR wrong... it's a sure bet that Hawking would be content with that, if not downright happy! (Neglecting any issues of personal Khunian revolution the good doctor might need to overcome first...;-)
Why is this (especially in the wrong case)? Because his goal isn't to spread this meme he's come up with, somehow earning more 'belief' in the meme. His goal is to learn more about the universe. An experimental proof or disproof would be a substantial step forwards in that regards.
Portable Music Players will play whatever it's cheapest to get hardware for.
Which is exactly why iPods all use software decoders on general purpose embedded cores. Having a codec-specific chunk of silicon fails to be a solution the instant you want to do anything other than decode (or encode) one specific format. As soon as you need to handle a number of different encoded formats or do both decode and encode, that codec-specific hardware doesn't look so spiffy anymore.
And that is precisely the reason why we have courts.
Indeed. Though what I really want is sev-1 bug filed on the damned legislature when a horridly written statute segfaults and The Law dumps core. Page their sorry asses out of bed at 2am.
Followed by The People asking harsh questions as to why the test suite wasn't run before Passing said statue into Production.;-)
Re:Maximizing Composability and Relax NG Trivia
on
Tim Bray Says RELAX
·
· Score: 2, Informative
That's an awful lot of cutting and pasting just to take a worthless jab at the Java language.
For many problem domains, it often doesn't matter what language you throw up against Haskell -- the Haskell program will often be smaller by one or more orders of magnitude (for a sufficiently rich/interesting program, anyways). The grandparent poster didn't even craft the example in question; Java was just the vicitm-elect of this particular case. I'll observe that even if the Java program there could be made shorter by an order of magnitude (!!), it would still be an order of magnitude larger than the Haskell implementation.
Although it's a bit long in the tooth now, Paul Hudak and Mark Jones wrote a paper that surveys the results of a Naval Surface Warfare Center prototying study comparing a number of different programming languages. See Haskell vs. Ada vs. C++ vs. Awk vs.... An Experiment in Software Prototyping Productivity. It's a fascinating read if you aren't already familiar with how different programming in Haskell is from many currently popular languages. I highly recommend delving into Haskell for any dedicated developer. Even if you don't find yourself developing in Haskell on a daily basis, the experience will positively impact how you think about code, and bring new conceptual models and patterns into your toolbox.
Not to be a completely insensitive asshole, but who exactly do you expect to pay for you child's care?
It's called risk distribution. Not that the rest of society pays for your care -- that's impossible if applied to everyone, because then no one pays anything. Rather, society bands together so that no one individual/family is overburdened by extraordinary health care needs and to ensure equal access to health care. The rest of it (private vs. government or some combination) are implementation details.
Considering health insurance in this light, I increasingly think that insurance companies in the U.S. should be required to treat their entire customer base as a single risk pool. No more discrimination to individuals or small companies, no favoritism to large customer groups/companies.
Revolutions happen by accident if at all, not on purpose.
I disagree. Technological revolutions most often happen because of the vision of a small group of people, or sometimes just one person -- and it's often very purposeful. They succeed or fail due to a whole host of other factors. The history of Un*x (and its varied offspring) is rife with examples along these lines.
Put another way, revolution virtually never happens because of committee decision. The most telling thing in TFA that guarantees mediocrity is the complete disconnect between the project, individual authority, and individual responsibility. Consider:
and of those twenty four there were exactly zero with final say in how the feature worked.
Any organization that creates the above situation has a problem. One of two things will tend to happen. Either someone will emerge who has leadership talent sufficient to herd the stakeholders into closure, or you'll get a drawn-out least common denominator solution as happened in this case. The leader solution sounds fine, until you realize that the leader only needs people skills, and need not have the slightest clue regarding good design, or even how to determine which crafted design of those present is the best.
It's much better for an organization to set itself up to succeed in such situations by hiring and deploying the appropriate expert(s). These might be skilled software architects, or experts in user interaction design -- people trained to have vision and clue for such situations. The really important thing is this person (or occasionally team) must have authority and responsibility to make key design decisions when needed. They must be able to solve the classic creative conundrum: deciding when it's time to to call it "done" and move on. Otherwise the org hires expensive talent only to frustrate them to the earth's end...
The fact that software is almost always a cost center, not a profit center, for those who need it. Everyone needs an operating system, but how many companies make money from selling a proprietary operating system? Very, very few. When there's broad need for some infrastructure software that's a cost center, it makes zero sense to keep that as in-house proprietary IP. The meme of the (hypothetical) threat of lost future earnings is gradually giving way to the leverage that participating in a commons gives. You (personally, or as in "your company") are better off putting it in the commons where others who share the same needs can help distribute the costs of maintenance, feature upgrades, etc. Put simply, there are economic forces that encourage this sort of collaboration.
This thinking applies in a different and more interesting way to developers. Developers (good ones, anyways) often have that spirit of invention/tinkering at heart. They want to build things. When others provide tools to help them, that rocks. This, in turn, tends to encourage a return in kind. It's a more direct sort of collaboration. A currency of keyboard sweat, as it were.
And frankly, it's because of people like you who don't understand why anyone would participate in a commons that the GPL sometimes kicks ass. The GPL pretty much enforces pay-to-play in the commons. If you take from the GPL commons to build a derived work that you want to redistribute, you have to give back to the commons. If you don't like it, then pay the $$ to build it all over again from scratch. (To put it old school: if you won't help out with your neighbor's barn-raising, why should he help you?)
Agreed. IIRC, bundling cell phones with service contracts is actually outlawed in Denmark. The carriers don't get to interfere with phone features and performance, and are forced to compete on an even price footing not muddied by the "deal" you're getting for that fancy phone.
This all reminds me of the bad old days of Ma Bell. For the young 'uns (or just plain forgetful...) the phone company used to own not just the phone line, but the phone, the phone jacks, and the wires in the walls of your house. The end of that stupidity brought vast improvements in price, selection of features, quality and design -- such as would never have happened under a lethargic monopoly.
I would love to see a similar revolution in today's US cell phone market. Let phone makers compete amongst themselves for consumers' good will, and the same for the carriers.
There are a few interpretations of "beauty" available here. The superficial one is, as the/. tag says, "eyecandy". I'd argue that this alone is useless. We've had all manner of shiny eyecandy in Linux for ages. If eyecandy alone were enough, Enlightenment would have taken over the world long ago. Even arguing the merits of a particular visual design isn't enough -- the Linux world needs to move beyond that into systems that both look good and have great interaction design.
If one process deletes a file that is opened by any process, then that file will be unlinked from the filesystem, but remain useable to the process that was already using the file. The file is not actually deleted from disk until all processes stop using it.
This model also leads to the Unix idiom of a process creating a temporary file, then immediately unlinking it (deleting it) itself. The temp file is still usable to the creating process, but no other process can see or get access to it via the filesystem. Now when your process exits, whether normally or because it crashed/was killed, the temp file is automatically freed. Nifty, eh?
Our ears are only capable of hearing up to about 20Khz (less than that for most people) and 16-bit samplings are enough that most people cannot hear the difference with anything more. Thus CD-quality is, if not perfect, then good enough that further improvements are ignorable for most people.
And before anyone steps in and notes that there's audio hardware and software that deals in higher sampling rates (e.g. 88.2kHz up to 192kHz) and higher dynamic ranges (e.g. 24-bit vs. 16-bit fixed, or 32-bit float)... these rates are targeted at quality improvements during the production process, not so much at improved quality of distributed music.
Slashdot Mirror
Beyond general scientific data collection, monitors such as this are useful to determine whether major changes in the newly discovered current are in progress and to track those changes against climactic effects. I know all this sounds passe compared to making up conspiracies based on oversimplifications and stereotypes, but it's a hell of a lot more useful.
Fingerworks vanished off the face of the internet a couple of years back. Apple quietly bought the company, its patents, and and the key researchers and engineers. Since then, they've been puting the Apple shine on their technology since then. Much to the likely delight of the "Fingerfans" the iPhone is the first product to ship with this technology since Fingerworks' was bought.
It *might* be possible to hack something together with a synaptics pad, but the hardware itself is likely deficient to do full-on multitouch. See section 1.3 of Westerman's thesis, linked below, esp. the pre-Fingerworks prototype hardware "producing a 50 frames per second (fps) stream of proximity images." I note that the Fingerworks devices connected via USB, but had on-device processing and firmware notably richer than what's in a simple touchpad. That alone may spell death to attempts at pure host-side multitouch with a "dumb" touchpad.
[1] PDF: Hand Tracking, Finger Identification, and Chordic Manipulation on a Multi-Touch Surface.
It's VERY hard to ship a new embedded platform in a timely manner with an SDK that supports arbitrary third-party development for a new product. So hard, that it's almost never the right answer to hold off ship to wait for an SDK. An organization is much better off shipping the working, robust 1.0 product into customer's hands and use that experience to build a quality SDK and toolchain. The platform itself is a sea of unknown problem domains ("arr, here be dragons!") for a "version 1.0" product like the iPhone.
The first is hardware engineers who don't see their work as providing clean, semantically sound "APIs" against which the software must operate. Worst case I've seen of this was a chip maker that had to scrap a set of new masks and tape-out again. Oops. We didn't need that 1,000,000 USD anyways.
The second, a generalization of the above, is that the product of a hardware company is almost always a synergy of hardware and software. This applies even when the hardware company isn't the producer of the software. E.g. a general purpose CPU design won't succeeed if it has flaws that make it difficult to compile correct or performant sofware; a video card without drivers and/or specifications is useless; and so forth.
So what are the waste products of the sugar based process, and what are the issues (disposal/reuse/energy to manage) surrounding dealing with the non H2 byproducts?
A payment system that verified the transaction with both the issuer and the card holder would have to be resistant to merchant tampering.
The parent's example is a good one, and has been addressed by various exception handling control structures in post-C languages. One useful case that has made it into very few languages is multi-level break: a break statement that accepts a parameter, the number of levels of control to escape. A break(2) call would thus exit two levels of containing loops. It's not an incredibly common situation, but it can be very handy for certain kinds of data structure traversals, some nested state machine implementations, etc. Alas, out comes that ugly GOTO.
Over time, this would enable viable third parties and independent candidates to 1) exist meaningfully and 2) eventually flourish. Why? Once voters are free to vote their view on all candidates, serious candidates can contemplate a non-Democrat, non-Republican affiliation without fear of being completely stonewalled at the voting booth.
Alone, rank-based voting may not be sufficient to increase political diversity in the US, but it's almost certainly necessary.
You might think you could get around all this via editing in plaintext mode, eh? No dice. There is effectively no first-class plaintext mode in Thunderbird's mail editor. E.g. you can change to "plaintext" mode, but all it does is hide the formatting bar.. any fonts in the document remain, but now you can't change them, even to make them fixed width. Pasting into a "plaintext" editor preserves the original formatting -- including the big fonts and glaring colors from that web page you just copied from. So much for WYSIWYG -- there's no way to actually see what the mailer will send out with plain text formatting. You just have to smack it all to "fixed width" and hope for the best.
Aside from that, Thunderbird's mail filtering is fairly functional and does what I want. It seems to handle large email boxes allright, but its search is pretty slow.
While I do agree about the here-and-now practical circumstances of the phone companies in the US, that doesn't change the fact that it is reasonable to expect that government must go through due process to acquire private information about its citizens. Likewise, phone companies (and other non-gov't entities) should be held accountable for participating in any breaches of due-process access to private information.
Here's a deeper difference: if someone went so far as to experimentally prove this idea right OR wrong... it's a sure bet that Hawking would be content with that, if not downright happy! (Neglecting any issues of personal Khunian revolution the good doctor might need to overcome first...
Why is this (especially in the wrong case)? Because his goal isn't to spread this meme he's come up with, somehow earning more 'belief' in the meme. His goal is to learn more about the universe. An experimental proof or disproof would be a substantial step forwards in that regards.
Which is exactly why iPods all use software decoders on general purpose embedded cores. Having a codec-specific chunk of silicon fails to be a solution the instant you want to do anything other than decode (or encode) one specific format. As soon as you need to handle a number of different encoded formats or do both decode and encode, that codec-specific hardware doesn't look so spiffy anymore.
Indeed. Though what I really want is sev-1 bug filed on the damned legislature when a horridly written statute segfaults and The Law dumps core. Page their sorry asses out of bed at 2am.
Followed by The People asking harsh questions as to why the test suite wasn't run before Passing said statue into Production.
For many problem domains, it often doesn't matter what language you throw up against Haskell -- the Haskell program will often be smaller by one or more orders of magnitude (for a sufficiently rich/interesting program, anyways). The grandparent poster didn't even craft the example in question; Java was just the vicitm-elect of this particular case. I'll observe that even if the Java program there could be made shorter by an order of magnitude (!!), it would still be an order of magnitude larger than the Haskell implementation.
Although it's a bit long in the tooth now, Paul Hudak and Mark Jones wrote a paper that surveys the results of a Naval Surface Warfare Center prototying study comparing a number of different programming languages. See Haskell vs. Ada vs. C++ vs. Awk vs.
It's called risk distribution. Not that the rest of society pays for your care -- that's impossible if applied to everyone, because then no one pays anything. Rather, society bands together so that no one individual/family is overburdened by extraordinary health care needs and to ensure equal access to health care. The rest of it (private vs. government or some combination) are implementation details.
Considering health insurance in this light, I increasingly think that insurance companies in the U.S. should be required to treat their entire customer base as a single risk pool. No more discrimination to individuals or small companies, no favoritism to large customer groups/companies.
I disagree. Technological revolutions most often happen because of the vision of a small group of people, or sometimes just one person -- and it's often very purposeful. They succeed or fail due to a whole host of other factors. The history of Un*x (and its varied offspring) is rife with examples along these lines.
Put another way, revolution virtually never happens because of committee decision. The most telling thing in TFA that guarantees mediocrity is the complete disconnect between the project, individual authority, and individual responsibility. Consider:
Any organization that creates the above situation has a problem. One of two things will tend to happen. Either someone will emerge who has leadership talent sufficient to herd the stakeholders into closure, or you'll get a drawn-out least common denominator solution as happened in this case. The leader solution sounds fine, until you realize that the leader only needs people skills, and need not have the slightest clue regarding good design, or even how to determine which crafted design of those present is the best.
It's much better for an organization to set itself up to succeed in such situations by hiring and deploying the appropriate expert(s). These might be skilled software architects, or experts in user interaction design -- people trained to have vision and clue for such situations. The really important thing is this person (or occasionally team) must have authority and responsibility to make key design decisions when needed. They must be able to solve the classic creative conundrum: deciding when it's time to to call it "done" and move on. Otherwise the org hires expensive talent only to frustrate them to the earth's end...
The fact that software is almost always a cost center, not a profit center, for those who need it. Everyone needs an operating system, but how many companies make money from selling a proprietary operating system? Very, very few. When there's broad need for some infrastructure software that's a cost center, it makes zero sense to keep that as in-house proprietary IP. The meme of the (hypothetical) threat of lost future earnings is gradually giving way to the leverage that participating in a commons gives. You (personally, or as in "your company") are better off putting it in the commons where others who share the same needs can help distribute the costs of maintenance, feature upgrades, etc. Put simply, there are economic forces that encourage this sort of collaboration.
This thinking applies in a different and more interesting way to developers. Developers (good ones, anyways) often have that spirit of invention/tinkering at heart. They want to build things. When others provide tools to help them, that rocks. This, in turn, tends to encourage a return in kind. It's a more direct sort of collaboration. A currency of keyboard sweat, as it were.
And frankly, it's because of people like you who don't understand why anyone would participate in a commons that the GPL sometimes kicks ass. The GPL pretty much enforces pay-to-play in the commons. If you take from the GPL commons to build a derived work that you want to redistribute, you have to give back to the commons. If you don't like it, then pay the $$ to build it all over again from scratch. (To put it old school: if you won't help out with your neighbor's barn-raising, why should he help you?)
Agreed. IIRC, bundling cell phones with service contracts is actually outlawed in Denmark. The carriers don't get to interfere with phone features and performance, and are forced to compete on an even price footing not muddied by the "deal" you're getting for that fancy phone.
This all reminds me of the bad old days of Ma Bell. For the young 'uns (or just plain forgetful...) the phone company used to own not just the phone line, but the phone, the phone jacks, and the wires in the walls of your house. The end of that stupidity brought vast improvements in price, selection of features, quality and design -- such as would never have happened under a lethargic monopoly.
I would love to see a similar revolution in today's US cell phone market. Let phone makers compete amongst themselves for consumers' good will, and the same for the carriers.
There are a few interpretations of "beauty" available here. The superficial one is, as the /. tag says, "eyecandy". I'd argue that this alone is useless. We've had all manner of shiny eyecandy in Linux for ages. If eyecandy alone were enough, Enlightenment would have taken over the world long ago. Even arguing the merits of a particular visual design isn't enough -- the Linux world needs to move beyond that into systems that both look good and have great interaction design.
This model also leads to the Unix idiom of a process creating a temporary file, then immediately unlinking it (deleting it) itself. The temp file is still usable to the creating process, but no other process can see or get access to it via the filesystem. Now when your process exits, whether normally or because it crashed/was killed, the temp file is automatically freed. Nifty, eh?
And before anyone steps in and notes that there's audio hardware and software that deals in higher sampling rates (e.g. 88.2kHz up to 192kHz) and higher dynamic ranges (e.g. 24-bit vs. 16-bit fixed, or 32-bit float)... these rates are targeted at quality improvements during the production process, not so much at improved quality of distributed music.