Is there actual case law supporting the notion that I can be party to a contract on the basis of a bunch of legalese buried in a manual I'll never read, for a product I purchased through a third party?
I paid for a product, I own it. If Sony wants ridiculously extended protections that turn the arrangement into some kind of conditional rental, they'd damned well better force the Walmarts of the world to have us sign documents to that effect at the point of purchase. This implicit agreement stuff is nonsense.
I'd be interested to know why a contrary opinion honestly held and expressed deserves your downvote (or the 2+ it did get), or your pointless comment.
There is an HN Two Minutes Hate aspect to the steady march of "MS platforms stagnant / not supercool like the flavour of the week we're putting into production" posts getting voted into the front page. News about actual open source projects and cool stuff on C#/F#/.NET/Mono tends to languish / fail to hit front page, consistently. It's fair to call this out.
I'm not saying that open source is staggeringly vibrant and healthy on .NET, though it is making steady progress. I simply try to keep in mind that there is a whole wide world of workaday devs who punch a clock out there, and .NET has big reach into that world.
You wanted volume licensing, but decided to be clever about it and 'test' the vendor. You inferred from their unwillingness to give John Q Random Customer a single pro version at the basic price that they would be 'inflexible' in an enterprise purchasing context, which is where your error starts and ends: it's an absurd leap to make, and you make a lot of assumptions to get there. You also manage to conclude from this that they "do not have a competent pricing structure".
Asserting that you gained any real insight into their business acumen or their suitability for your real purchasing needs with your strange test seems deeply misguided. And your delivery makes it entirely understandable if people take away from your post a reading that you are simply self-satisfied at having wielded that purchasing power so capriciously.
Now, after some initial rounds of criticism (and the consequent derail of much of this thread), you've stooped to repeatedly decrying the decline of HN and its devolution into slashdot (although you are apparently finding posts that agree with you to be restorative of hope on that front).
Wow, does this unassuming post really constitute an appropriate venue for the old axe-grinding platform snark? Find something better to do with your Sunday afternoon, gents.
Marius, we're a small shop with 4 apps on the marketplace, and we'd be happy to help - will drop you a line.
Schemas are an optional part of Solr. Pretty sure that the default schema.xml has an example of a catch-all field definition, if you use that it will automatically deal with any key you want to throw at it.
Of course you need to specify one field type (analysis stack) to apply to all, but I don't know how you expect to avoid that - gonna have to express that metadata somewhere if you need more complex behavior.
Personally I think the _d, _i approach is ok, suffixes aside - complex field analysis options w/o a schema.
I've been using Solr for some pretty heavy lifting, and it's incredibly impressive. Rock solid, extremely advanced analysis and search capabilities, and the performance is amazing if it's on suitable gear. Time invested in learning it pays off big.
I'm familiar with the enterprise black boxes you're talking about - I probably know the specific one you're tormented by. I've seen the licensing fees alone lead large companies to drop rows from their front-end stores to avoid going into a new pricing tier (takes balls of steel to charge by the record, I must say), and I've seen competitors fold at least in part due to the expense of paying for the thing.
A lot of startup folks getting excited about NoSQL seem to have passed over Lucene/Solr completely, and I think it's worthy of much more consideration than it gets. It's mature, it's fast, and the people working on it live and breathe the problem space.
There are undoubtedly devs out there badly needing powerful analysis and search to execute on their vision, but who will end up suffering with half-baked solutions for lack of even hearing about Solr, much less giving it a try.
Most mainstream manufacturers do seem to put Swype on at least some of their models - HTC, Samsung, Motorola at least.
No doubt this works out nicely for Swype (strictly volume deals is pretty lucrative, I'd imagine), but it really puts me off them as a company - I'd hate to see this kind of model proliferate.
It's too bad that Swype persists with their bizarre OEM-licensing-only model. Would love to try it on my N1, but they can't be bothered to provide it to the unwashed masses as a normal purchased download.
Many, many young devs are in love with the idea of developing games. Many more than the industry actually needs. It follows that you're less likely to land such a gig, and that you're more likely to get underpaid and be burned out by overwork if you do - there's always someone else who still has stars in their eyes, waiting to take your place.
If gaming is really a dev's passion, they should already have compelling work they've done on their own, a substantial portfolio, some contacts developed, etc. If not, it's probably an unrealistic flight of fancy, and it should be recognized as such and discarded.
My understanding is that anything that allows the user to choose what specific tracks they want to hear is deemed "interactive" by the industry, and costs an awful lot more than "non-interactive". "Non-interactive" appears to mean streams which the user can only broadly determine the content of (i.e. genre or like-artist 'stations'), can't allow skipping over tracks too aggressively, and who knows what other restrictions.
I don't have any idea as to how big of a difference in licensing fees we're talking about here, and I know it's very hard to make a buck in this sphere with so many vampires in the picture. But not paying up for interactive seems like a really bad call on last.fm's part (and/or suggests that they are in pretty rough shape as profits go). The list of things they're removing is essentially a list of "all the reasons why I might be interested in using last.fm".
>This isn't about whether Android is open or not; it's about whether the way it is open is at all consistent with the way it's openness is marketed to end consumers.
I keep hearing this, but can you demonstrate where Google has represented Android as the product of some vibrant and continuous interplay between the wider open source community and their own engineering teams?
Interestingly enough, there's more of that going on than you're giving credit for. http://android.git.kernel.org/ isn't an iota of what it could be, but it's certainly more than an "occasional tarball of source".
Look, I think what Google is doing with the periodic drops is pretty lame - but the Android software is open. More than that, they've tried to spur on some pretty radical freedoms - like my Nexus One which they convinced HTC to provide fully unlockable: a simple command and a warning screen away. This was unthinkable not so very long ago, certainly in smart phones. Frustratingly enough, the market wasn't interested, but they tried. And may well try to keep pushing that bar forward. But you'll give them no quarter - they are damned for not reshaping things to your preferred standards in one fell swoop, they are responsible for both the hardware and the regressive policies of every idiot vendor whose usage of the platform they bless.
It's a bit overdone to say that "the openness is primarily for the benefit of handset makers and carriers who can use those tarballs". I'm interested in where you've acquired this insight into Google's treacherous true motivations, and I'm surprised to learn that it's so hard to take those "tarballs" and get them running on arbitrary hardware. That damned linux kernel, so notoriously hard to get running on variant hardware.
When you get down to it, your real problem seems to be that Android strikes a fairly neutral deal, allowing the carriers and manufacturers to keep their freedoms too. They're free to try to turn back the clock, release terribly gimped phones, and just generally be the dicks that we have always known them to be. We're free to reject it, and should.
So you're now taking the position that how open Android is can depend upon how they have marketed their openness, and how misleadingly they may have done so? That's nonsense. At the end of the day, "fork it, mod it, build it, deploy it to any device that will run it" still applies. That's unavoidably and factually open. Radically so, given where this particular market was just 3-4 years ago.
I'm astonished at how muddled and downright bizarre the argumentation on these threads gets. Yes, they don't develop future platform versions in the open, they just make delayed code dumps. Annoying. But hardly "open"-negating. The process may not be open - the deliverables are. And all of the usual advantages of that open are in full effect with Android and its many, many active mods.
Yes, carriers are free to add unremovable shovelware, to try and prevent flashing with the aid of the hardware manufacturers - all that nasty stuff they are free to do with any apache/bsd-licensed codebase. It's very hard to understand how this is Google's fault, or why it somehow renders the underlying platform "not open". Should they have stridently disallowed such behavior from day 1? I'm guessing that would have left them with a lot fewer partners, and a go-nowhere platform, but hey, at least they would have been pure as the driven snow ideologically.
Saying with a straight face that Android is "not open", "not meaningfully more open than iOS", "nothing like what we would traditionally call open-source", and so on is ridiculous hyperbole. The only interest I take out of these instant train wreck threads is in playing a game: guess at what horses individual commenters have in the mobile race, that their perceptions can become so severely distorted.
My recollection is that Patti Schmidt ran a more rigidly structured ship: 1 hour of broad and relatively palatable stuff, 1 hour artist profile, and then 2 hours of miscellanea, with the final hour often being the really out-there installation stuff. Even when that last hour was unlistenable chin-stroking stuff, though, I still greatly appreciated that a show that would play it existed on the dial.
But yes, things were much simpler then. The demise of BNW seems to have coincided with the transition to satellite / podcasts / streaming for the CBC, at which point I can only assume that navigating licensing issues got a great deal more difficult. Even the single archival clip of BNW that CBC offers for streaming, from 1984, bears the notice Due to copyright issues, there are no songs in this clip.. That's just dismal.
You seem to be missing that the CBC buys One Big Library (APM), and thus isn't in the business of talking and negotiating with individual artists at all.
I'm not going to defend that kind of approach to radio - particularly not taxpayer funded radio which has the potential to have far more breadth and depth in its content than commercial radio - and I suspect it is a relatively new innovation, inflicted by the current clueless management at CBC.
Like many Canadians I still mourn the loss of the amazing Brave New Waves (http://en.wikipedia.org/wiki/Brave_New_Waves), and there's no way that all or even most of the obscura that was being played on that show was in some giant pre-licensed library of music. I suppose that cancelling one-of-a-kind shows like that is an aid to 'getting greater efficiencies out of the content management pipeline' or some such nonsense.