Tom: "Vomit sprays out in a beautiful technicolor dream."
(later)
Crow: "I don't like the circus any more. I want to go home!" Tom: "Shut up and watch the deer get slaughtered, it's fun."
And that was before the main event, Monster a Go-Go...Lord almighty, that movie was bad. The end segment featuring Joel talking the bots off the proverbial ledge didn't seem like too much of a stretch; I wanted to bang my own head against the wall afterwards. Having to actually watch that dreck multiple times to come up with lampoon material...{shudder}
Amen to that. Sylvester McCoy nearly killed off the series for me and probably would have had Eccleston not been cast in the next series I saw (yes, I know there was someone else between him, missed out on that.)
While lampooning the short "Circus on Ice", a scene featuring...well...skaters skating around an ice rink with some incredibly cheesy-Lawrence Welk-ish-muted-trumpets-and-strings-music playing, Tom(I believe) starts singing:
These two girls they are quite a pair They have come from your worst nightmare They will haunt you for forever, and so when you see pink, you're gonna think 'we're doomed.'
They are agents of Satan...
at which point he's mercifully cut off. Snarfed out half a beer out my nose after hearing that.
That whole episode was classic...a action figure contest followed by the above-mentioned Circus on Ice, followed by Monster A Go-Go. Nothing else came close after that, not even Manos.
Oh, they're still trolling the bars, absolutely, and that won't change anytime soon. What the greenlighting people _are_ doing differently now, for certain, is closely qualifying what "breakout" means to them, in terms of risk of the act. As many others have noted, it's a lot harder these days to get signed and nobody, no one, is given any development runway anymore--disc #1 needs to sell {x} units minimum or your toast. It's a sad loss all the way around.
To your point...the recruiting/packaging you mention does take place, as you describe. And it won't change. And it's a sad addition all the way around. {grin} But a quick scan of the iTunes storefront shows a lot more than just the boy/girl band du jour. Plenty of other acts and genres and reducing them down to one level 98 Degrees of Boys to 'Sync isn't going to happen.
Seems you've read the Albini essay as well.... {grin} True, if you're desperate enough to be "broken", the labels can play you in precisely the way you write.
I do think more unsigned acts are becoming savvier in general these days regarding the mechanics of their business. If nothing else, they're certainly aware that there's more than one label in town to ply their services to. My point was Universal would just be putting themselves at a disadvantage with this, compared to their competition. And all it's going to take are a couple cases of some act being broken big through a competitor and that will be all the other bands hear/see in the short term.
I don't really get what benefit they'd realize from pulling out, unless this is just a negotiating tactic (which certainly could be the case.) Even then, though, iTunes is probably approaching a scale at which they could weather the loss of revenue (albeit with difficulty).
Unsigned Band with break-out potential: "So, we sign with you...and our record won't be up for sale on iTunes?" Universal A/R dude/dudette: "Yep, that's right." Unsigned Band with break-out potential: "So any unit sales revenue we see from you will be from Wal-Mart and Best Buy sales, nothing else?" Universal A/R dude/dudette: "Uh huh." Unsigned Band with break-out potential: "Losers. Next!"
But 3 years running of net income roller-coastering down while revenues have been rising doesn't fill investors with a lot of confidence in one's operational management oversight.
Not that I'm sure what Jerry Yang will be able to do differently, other than possibly re-moralize the troops...
Unfortunately Matthew 28:19-20 appears to muddy the waters a bit in that regard. Consistency is a bit much to ask of a creed held to be infallible, I guess...
You apparently assume that the integration team will be taking stock hardware and putting a vanilla build of RedHat on top of it for these machines. Not hardly, I'd think...
These machines will (in all likelihood) have very lean customized kernels built for specific hardware device profiles. Wouldn't surprise me to see customized drivers written specifically for said hardware. I can't speak for the HP team, but the SIAC dev teams have some damn smart and capable folks on them. They'll be able to get done what they need to get done, possibly better with Linux because its (and its components) source is freely inspect-able and modifiable.
I wouldn't be surprised to see them use a grid architecture as well...would seem to address the response-time constraints of their settlement processing, plus lets them scale up pretty much as far as they'd need to.
Big risks, for sure, on this, but containable risks given adequate money and expertise (no lack of either in this case), and big rewards as well...
As for virtualized Linux on big iron...I don't think virtualization even enters a discussion with their team, regardless of host hardware, not with the response time requirements they have.
I would be interested in comments from any lawyer-types on whether the duty to mitigate applies now that Microsoft has publicly announced knowledge of alleged patent violations. If they don't pursue specific action now, but defer it to some later time, could a defendant mount a defense based on Microsoft's failure to address the violation in a timely fashion? Or does this not apply in IP law?
I'm not optimistic about an OO port to native Mac, regardless of who is on board with it. Why should I be, given the legendary code cruft of OO, the lousy relationship relationship dynamics between the Mac- and non-Mac developer leads on OO, the well-intentioned-but-ghastly-performance object lesson of NeoOffice?
OO is very decent office suite on Linux and Windows. So leave it there, where it is working acceptably. I think any effort to take that code base and reconcile it to an acceptable UI and functional level on the Mac will be the definition of a trip down the rabbit hole, taking years to realize and resulting in a UI compromise that annoys users on all platforms.
Time to cut bait on this, accept that it never will be workable on the Mac, and free its development team to focus on improving it in the Lin/Win world. Better to spend development time and effort developing a Mac-specific office suite that uses the various Open*** file formats as its native storage, while providing a real Cocoa-based UI experience that actually integrates into OS X the way Mac users expect an application to. Not that Sun will come within a mile of such an initiative, but it's a great opportunity for frustrated Mac developers looking to solve a real practical problem...
The FlexSDK includes a basic XML more or less RESTful transport capability.
Depends upon which structure you're speaking of...
If you're talking about the native <mx:XML> tag/object type, nope, at least not in my experience, not for anything larger than a modest-size DOM. Certainly not for large or even medium-size result sets--parsing performance is awful; one, sometimes two orders of magnitude slower than remoting, slower even than SOAP calls. YMMV of course, but I wouldn't put it into anything that's time- or volume-sensitive.
If you're talking about HTTPServer (which apparently is included in the SDK now, according to at least one other post), maybe. One of the things that would be nice to see in the newly open-sourced code is why in heaven the HTTPService XML->JSON object parser is so much faster than the 'native' <mx:XML> datatype parsing. Never understood that.
Most excellent, and hopefully its maintainers recognize a publicity opportunity when it's presented to them. Sorry I can't mod this up...someone else, please do.
As I said, if you're one of those people who doesn't mind rolling a service call/result parser/object creator by hand, sure, call whatever you want on the backend. I don't think that's a real attractive option for bigger shops trying to search/update/manipulate large data sets thought.
Another reply to my post mentioned that HTTPService apparently is available as part of the SDK, so that might work fine for shops with a REST-ful or XML-RPC-focused interop approach.
Regarding data services...if you're talking about LCDS 2.5...the current beta is being offered for free download and it is time-limited, so that doesn't strike me as a "free" solution by any stretch. We'll see what happens when it goes GA--my bet is that Adobe is still going to want serious coin for it.
Good to know and actually this isn't bad, since it would make REST and XML-RPC-style interactions do-able at least....but you're absolutely right; where is the love for RemoteObject? SOAP service calls are screwed as well w/out the gateway.
Well, actually the GP has a point...Adobe isn't open-sourcing any of the server/data access/interop components. So while you might be able to freely assemble a great-looking webpage-embeddable UI, what use will it be without the ability to access/manipulate data stores and services? And if you can't do that...what's the point of using Flex in the first place? Wasn't it targeted at corp developer types? If all you want are pretty apps, wouldn't you be using the web designed-focused Flash tools in the first place?
Sure it's great the SDK code will be freely available and inspectable; I'm all for transparency in software and its licensing. But Adobe has still locked up the middleware and will continue to charge an astronomical amount of money for it. And the tool won't be terribly useful without it, unless you're one of the wildman-types who rolls his own data access remoting. So the GP isn't that far off, at least in my opinion.
What would be helpful for the dev community would be an FOSS interop gateway/platform where the remoting headaches have already been solved. Maybe it exists somewhere; if so, now would be a great publicity opportunity for it.
(And yes, I've done Flex development before, so spare me the snarkiness...)
Through means best left uninvestigated, I've obtained a copy of the following note, the contents of which should set everything to rights. It will be presented formally to the appropriate Congressional and Justice Department staff sometime in the next few days--in the meantime, consider yourselves in the knowlegeable elite!
Dear Congresspeople:
Please excuse George Bush from any requirements of responsible behavior, accountability or public honesty for the rest of his term. His friends and co-workers too.
Sincerely,
-George Bush's Mother-
Everybody happy now? Good, now get back to work...
Re:How will this affect other VoIP providers?
on
The End for Vonage?
·
· Score: 1
From re-reading some of the related articles, the infringement appeared to be centered on technology that actually switches/connects the VOIP traffic to the traditional land-line carrier network. In other words, I don't see that this is a general-purpose club for Verizon to throw around.
I'd say your provider's exposure would be driven by the actual gateway technology they're using to route onto the old RBOC copper wire infrastructure. New switches for all!
A proper lawyer's opinion would be more useful than mine, of course--but this is Slashdot after all, so here it is; take it for what it's worth. Any patent/IP attorneys care to comment?
(Extra-credit for same folks: it would be nice if someone monitoring this case posted a technology-focused description of the specific infringing technology, in non-patent attorney-speak.)
Slashdot Mirror
All good ones, and so many more...
Tom: "Vomit sprays out in a beautiful technicolor dream."
(later)
Crow: "I don't like the circus any more. I want to go home!"
Tom: "Shut up and watch the deer get slaughtered, it's fun."
And that was before the main event, Monster a Go-Go...Lord almighty, that movie was bad. The end segment featuring Joel talking the bots off the proverbial ledge didn't seem like too much of a stretch; I wanted to bang my own head against the wall afterwards. Having to actually watch that dreck multiple times to come up with lampoon material...{shudder}
Amen to that. Sylvester McCoy nearly killed off the series for me and probably would have had Eccleston not been cast in the next series I saw (yes, I know there was someone else between him, missed out on that.)
at which point he's mercifully cut off. Snarfed out half a beer out my nose after hearing that.
That whole episode was classic...a action figure contest followed by the above-mentioned Circus on Ice, followed by Monster A Go-Go. Nothing else came close after that, not even Manos.
Good times...
Ladies and gentlemen, presenting the latest, greatest Slashdot meme!
It is funnier, at least, than imagining a you-know-what cluster of them...
Oh, they're still trolling the bars, absolutely, and that won't change anytime soon. What the greenlighting people _are_ doing differently now, for certain, is closely qualifying what "breakout" means to them, in terms of risk of the act. As many others have noted, it's a lot harder these days to get signed and nobody, no one, is given any development runway anymore--disc #1 needs to sell {x} units minimum or your toast. It's a sad loss all the way around.
To your point...the recruiting/packaging you mention does take place, as you describe. And it won't change. And it's a sad addition all the way around. {grin} But a quick scan of the iTunes storefront shows a lot more than just the boy/girl band du jour. Plenty of other acts and genres and reducing them down to one level 98 Degrees of Boys to 'Sync isn't going to happen.
Seems you've read the Albini essay as well.... {grin} True, if you're desperate enough to be "broken", the labels can play you in precisely the way you write.
I do think more unsigned acts are becoming savvier in general these days regarding the mechanics of their business. If nothing else, they're certainly aware that there's more than one label in town to ply their services to. My point was Universal would just be putting themselves at a disadvantage with this, compared to their competition. And all it's going to take are a couple cases of some act being broken big through a competitor and that will be all the other bands hear/see in the short term.
I don't really get what benefit they'd realize from pulling out, unless this is just a negotiating tactic (which certainly could be the case.) Even then, though, iTunes is probably approaching a scale at which they could weather the loss of revenue (albeit with difficulty).
Unsigned Band with break-out potential: "So, we sign with you...and our record won't be up for sale on iTunes?"
Universal A/R dude/dudette: "Yep, that's right."
Unsigned Band with break-out potential: "So any unit sales revenue we see from you will be from Wal-Mart and Best Buy sales, nothing else?"
Universal A/R dude/dudette: "Uh huh."
Unsigned Band with break-out potential: "Losers. Next!"
Shouldn't we do that anyway, supernova or not?
Nice point-in-time numbers, sure.
But 3 years running of net income roller-coastering down while revenues have been rising doesn't fill investors with a lot of confidence in one's operational management oversight.
Not that I'm sure what Jerry Yang will be able to do differently, other than possibly re-moralize the troops...
Unfortunately Matthew 28:19-20 appears to muddy the waters a bit in that regard. Consistency is a bit much to ask of a creed held to be infallible, I guess...
Rather, I think he's saying: "verifiable history -- accept it or find someplace your delusions are acceptable".
You apparently assume that the integration team will be taking stock hardware and putting a vanilla build of RedHat on top of it for these machines. Not hardly, I'd think...
These machines will (in all likelihood) have very lean customized kernels built for specific hardware device profiles. Wouldn't surprise me to see customized drivers written specifically for said hardware. I can't speak for the HP team, but the SIAC dev teams have some damn smart and capable folks on them. They'll be able to get done what they need to get done, possibly better with Linux because its (and its components) source is freely inspect-able and modifiable.
I wouldn't be surprised to see them use a grid architecture as well...would seem to address the response-time constraints of their settlement processing, plus lets them scale up pretty much as far as they'd need to.
Big risks, for sure, on this, but containable risks given adequate money and expertise (no lack of either in this case), and big rewards as well...
As for virtualized Linux on big iron...I don't think virtualization even enters a discussion with their team, regardless of host hardware, not with the response time requirements they have.
I would be interested in comments from any lawyer-types on whether the duty to mitigate applies now that Microsoft has publicly announced knowledge of alleged patent violations. If they don't pursue specific action now, but defer it to some later time, could a defendant mount a defense based on Microsoft's failure to address the violation in a timely fashion? Or does this not apply in IP law?
Just downloaded the Win client and Jabber does not appear to be available as an account type. Did the team drop this? Jabber was supported in 1.5.
I'm not optimistic about an OO port to native Mac, regardless of who is on board with it. Why should I be, given the legendary code cruft of OO, the lousy relationship relationship dynamics between the Mac- and non-Mac developer leads on OO, the well-intentioned-but-ghastly-performance object lesson of NeoOffice?
OO is very decent office suite on Linux and Windows. So leave it there, where it is working acceptably. I think any effort to take that code base and reconcile it to an acceptable UI and functional level on the Mac will be the definition of a trip down the rabbit hole, taking years to realize and resulting in a UI compromise that annoys users on all platforms.
Time to cut bait on this, accept that it never will be workable on the Mac, and free its development team to focus on improving it in the Lin/Win world. Better to spend development time and effort developing a Mac-specific office suite that uses the various Open*** file formats as its native storage, while providing a real Cocoa-based UI experience that actually integrates into OS X the way Mac users expect an application to. Not that Sun will come within a mile of such an initiative, but it's a great opportunity for frustrated Mac developers looking to solve a real practical problem...
Depends upon which structure you're speaking of...
If you're talking about the native <mx:XML> tag/object type, nope, at least not in my experience, not for anything larger than a modest-size DOM. Certainly not for large or even medium-size result sets--parsing performance is awful; one, sometimes two orders of magnitude slower than remoting, slower even than SOAP calls. YMMV of course, but I wouldn't put it into anything that's time- or volume-sensitive.
If you're talking about HTTPServer (which apparently is included in the SDK now, according to at least one other post), maybe. One of the things that would be nice to see in the newly open-sourced code is why in heaven the HTTPService XML->JSON object parser is so much faster than the 'native' <mx:XML> datatype parsing. Never understood that.
Most excellent, and hopefully its maintainers recognize a publicity opportunity when it's presented to them. Sorry I can't mod this up...someone else, please do.
As I said, if you're one of those people who doesn't mind rolling a service call/result parser/object creator by hand, sure, call whatever you want on the backend. I don't think that's a real attractive option for bigger shops trying to search/update/manipulate large data sets thought.
Another reply to my post mentioned that HTTPService apparently is available as part of the SDK, so that might work fine for shops with a REST-ful or XML-RPC-focused interop approach.
Regarding data services...if you're talking about LCDS 2.5...the current beta is being offered for free download and it is time-limited, so that doesn't strike me as a "free" solution by any stretch. We'll see what happens when it goes GA--my bet is that Adobe is still going to want serious coin for it.
Good to know and actually this isn't bad, since it would make REST and XML-RPC-style interactions do-able at least....but you're absolutely right; where is the love for RemoteObject? SOAP service calls are screwed as well w/out the gateway.
Well, actually the GP has a point...Adobe isn't open-sourcing any of the server/data access/interop components. So while you might be able to freely assemble a great-looking webpage-embeddable UI, what use will it be without the ability to access/manipulate data stores and services? And if you can't do that...what's the point of using Flex in the first place? Wasn't it targeted at corp developer types? If all you want are pretty apps, wouldn't you be using the web designed-focused Flash tools in the first place?
Sure it's great the SDK code will be freely available and inspectable; I'm all for transparency in software and its licensing. But Adobe has still locked up the middleware and will continue to charge an astronomical amount of money for it. And the tool won't be terribly useful without it, unless you're one of the wildman-types who rolls his own data access remoting. So the GP isn't that far off, at least in my opinion.
What would be helpful for the dev community would be an FOSS interop gateway/platform where the remoting headaches have already been solved. Maybe it exists somewhere; if so, now would be a great publicity opportunity for it.
(And yes, I've done Flex development before, so spare me the snarkiness...)
Actually, the word I was using last night was "goniffs"....
Everybody happy now? Good, now get back to work...
Mau. Muito mau
([grin])
Try this instead:
"c:\program files\internet explorer\iexplore.exe" http://www.ubuntu.com/getubuntu/download
Hope this hepls....
From re-reading some of the related articles, the infringement appeared to be centered on technology that actually switches/connects the VOIP traffic to the traditional land-line carrier network. In other words, I don't see that this is a general-purpose club for Verizon to throw around.
I'd say your provider's exposure would be driven by the actual gateway technology they're using to route onto the old RBOC copper wire infrastructure. New switches for all!
A proper lawyer's opinion would be more useful than mine, of course--but this is Slashdot after all, so here it is; take it for what it's worth. Any patent/IP attorneys care to comment?
(Extra-credit for same folks: it would be nice if someone monitoring this case posted a technology-focused description of the specific infringing technology, in non-patent attorney-speak.)