
How did this get filed under Bootnotes?
Oh wait, you don't have a Bootynotes section (yet).
18 publicly visible posts • joined 3 Jan 2008
Here in the states, You know what the nicest thing about subscrtpion internet TY is (from services like Netflix and Amoxon is? No Bloody Comercial Breaks!
Sorry M$, if you think you're going to make a mint, because people would rather have free stuff subsidized by advertising, you're doomed.
At this time, streaming TV over IP in the US is hot because A) we pay a small fee monthly or it, sans advertisiing, B) We aren't endure endless commercial breaks for products we'll never buy, if we can possibly help it, and C) we aren't required to pay a flat rate subscription fee for the right to view to a truckload of advertiser subsidized content we don't want to watch anyway. (Take Note Cable and Satillite TV Co's - I'm talking about YOU here!)
So why does M$ think they can make $ here through advertising subsidies, when the subscriber base hates and barely tolerates advertising? Seriously, isn't this a bit of trying to feed in the shallow and depleted end of the revenue pool?
/gds
Cade,
The "SJ is a megalomaniac and slowly going insane" theme may be fun, but it's tired. Move on, you've left too many other questions unanswered here.
1) Apple included Flurry's toolkit in their SDK. In the Windows world, Flurry's toolkit would be classified as _SPYWARE_ (and we'd have at least a week's worth of gratuitous and emotionally satisfying M$ bashing).
No mention of the spyware angle in the article. It looks like we're having an Apple bashing party, but for every possible reason except SDK embedded spyware. Odd.
2) Since it's pretty much an industry standard practice, one would expect Apple to have required an SDK contributor, such as Flurry, to sign a non-disclosure agreement. NDA's typically include some pretty broad language prohibiting disclosure of proprietary information, including that which is unintentionally exposed by either party.
Clearly, Flurry went off the reservation back in January, in a shameless bid for self promotion. Are they being sued for disclosing what was clearly Apple's confidential and proprietary data to the general public? If not, why not? Details please.
3) Apple has been, /or should have been, aware of the full capabilities of Flurry's toolkit since it was first submitted for inclusion in the iPhone SDK, so they should have made the judgment call w.r.t. Apple's Privacy Policy way back when. So Apple's argument for banning the Flurry kit from the SDK is just PR BS and doesn't hold water. The real reason is clearly Apple's own corporate embarrassment at being caught helpfully(?) including a DIY spyware toolkit in their own iPhone/iPad SDK.
Lastly, you neglect to mention that Apple's banning of Flurry's toolkit is actaully somewhat of a small victory for the "require the user to opt-in" privacy cause. Looks like they did the right thing for all the wrong reasons.
When Joe Luser downloads an app from iTunes, I'm sure he's not thinking "was this built using the Flurry Analytics tools in the iPhone SDK?". Nah, this is Apple after all, and he can trust Apple to keep the bad stuff out of their store. Right?
Yeah, right.
-GS
Given this sort of behavior, one would guess their "Linux" patents were as about as valid as George Selden's "Road Engine" patent, granted roughly 125 years after Nicholas Cugnot built his steam powered wagons.
http://www.bpmlegal.com/wselden.html
As the article explains, after being granted the patent in 1895, Selden sold it to a holding company (patent trolls), the ALAM, who used it to bully a number of smaller manufacturers into paying a royalty on every automobile they built. In 1903, they sued Henry Ford and his company, which refused to cave, and eventually defeated the patent in court in 1911, overturning earlier rulings in favor of ALAM.
If your patents are vague and their applicability is uncertain, it's wise avoid having the details go public. Looks like MS knows this, and stay away from those who are strong enough to mount a serious legal challenge. So they pick on HTC and others, not Google. I for one wish they would pick on Google. It would be a great spectacle.
In other news, SCO reaches out of the grave in an attempt to grasp Novell's ankles. Has MS been giving them transfusions again?
"i'm not very penguin experienced.. if i want to improve how the front end looks, what's the best thing a nonce can do to improve it and make it a look little more impressive?"
Check out the art and themes pages under http://www.gnome.org. See http://art.gnome.org/themes for desktop customizations you may want to try out. You may want to create an extra local user id on Ubuntu for testing these out, rather than taking the risk of hosing the gnome desktop config for your primary user id.
Granted, Ubuntu's brown is looking a bit tired after a some years. But purple and orange? Yecch. I think I'll keep my boring old shades of blue and grey.
If it's got a compiler, EMACS can be built from source. Even if it doesn't have a compiler, there's probably a fairly current build of gcc and the bintools around in binary form.
Assuming it doesn't have X, EMACS can function as a basic window manager, in addition to being an editor. And I think there are text-based web browsers
The network connectivity story isn't real clear though, yet it's essential to making the thing into a useful device for those who enjoy being contrary.
/gds
Could someone from M$ explain why all of M$ suggested retail prices here in the US contain the same numerical values as their UK prices? The only difference that I can see, is that instead of a dollar sign prefix, all of their UK prices are prefixed with the UK's pound sign. So why is M$ Office for students priced at $109.-, but the UK price is 109 pounds? (Sorry, this is typed on a US keyboard.)
Last time I checked, the exchange rate would make the UK price 1.75x to 2x the US price.
M$ = wankers.
El Reg, We need a frying egg icon, because just like crack, With Windows, users become lusers.
This is a side effect of the exportation of chip manufacturing technology by the US semiconductor industry during the 1970's and 1980's, which continues to this day, because they've forced themselves into their current situation. Create a new chip die today, and there are lots now lots of people out there who can clone it - and build it more cheaply than you can.
The US semi-conductor industry literally committed a form of slow industrial suicide back in the '70's and 80's, by outsourcing all of the manufacturing. To this day, our corporate titans are still too dense to realize that you can't offshore the manufacturing without also offshoring nearly all of the engineering expertise required to design and manufacture the device in the first place.
So no, nothing in this article surprises me.
Bleah!
Does this mean the software development industry can go back to the heady days of yore, producing bloatware as usual, secure in the knowledge that Moore's law will cover most, if not all, of their sins?
After all, cleaning up sloppy coding, ridding the application architecture of unnecessary middleware, or excessive levels of abstraction caused by the choice of language and development frameworks is real work. Boring, nasty business.
Without hardware resource constraints, we can allow developers to explore their "creative horizons" in interesting and sometimes exotic ways, without worry that the thing will hit the wall once you put a real-world peak user load on it.
I can almost hear the cheers already.
Nicely presented, but CTIA's proposal is still dog crap.
"The CTIA argues that modern set-top boxes are so armoured against receiving bounced ghost signals that they can cope with one coming from a different transmitter. Modern boxes accept the strongest signal and are capable of disregarding the others.
That assertion is the weak point,..."
Now there's a massive understatement. Having gone through the US conversion to DTV, I can tell you that the biggest (and as yet, un-addressed) problem with the DTV receiving equipment available in the US, is that the current equipment is extremely susceptible to losing sync with the packet stream due to multi-pathed signals.
During the change over to DTV, for a time we had simulcast analog and digital versions of the same broadcast channels back to back. We found that for best DTV reception, you had to use the analog channel to position the antenna so that ghosts (multiple signal paths) were effectively eliminated, and this would also produce the best DTV reception, as a clean single-pathed signal would not confuse that packet clocking logic the way a multi-pathed signal would.
So their contention that multi-pathing is not an issue for DTV reception with current equipment is simply a blatant lie, a fiction to sucker supposedly gullible FCC regulators into doing CTIA"s bidding.
"...but if the CTIA has its sums right then there's little reason why the system wouldn't work. The group reckons it will cost less than $2bn to built the new transmitter network"
I suppose the CTIA will underwrite the installation of this $2bn worth of repeater infrastructure on their towers? Yeah, right.
More likely, these s**tweasels will probably expect either the local broadcasters or the local and/or federal taxpayers to fund their repeater build-out. Then they'll find a way way to charge us all subscription access fee's to their repeater network, by helpfully providing DTV equipment, that "solves" all of those nasty multi-path issues which were so conveniently created by the presence of the CTIA sponsored repeater networks.
Of course, CTIA members would sell such a service in the same way they routinely sell cell phones in the US. The equipment will be provided at low or no cost, under a minimum 2 year contract, with easy payments of "only" $19.95 per month. As with their cell service contracts, early termination fees of $250 or more will apply. (No need to change an existing, lucrative, and proven business model, right?)
Time to do some research and write some letters to the FCC.
"There's a viral aspect to this attack. As new SSH keys are stolen, new machines are potentially vulnerable to attack."
Bunk! That's the mark of a worm, not a virus. The biological behavioral analog of this attack is a bacterial infection, which is what defines a worm, not a virus.
Kindly remember that a computer virus is a malware code fragment that emulates a biological virus by embedding itself in an executable to activate it's payload and/or replicate itself, often using some of that executable's code as a means of getting control of machine functions.
The attack here is clearly a worm, because it spreads itself using the classic bacterial model - break in by compromising a well known authentication mechanism, copy in a tool kit, and consume the host system's resources primarily to replicate itself and install backdoors for later use.
Another clear sign that this is a worm, is that the rootkit uses hidden directories to hide in plain sight, rather than burrowing into the bodies of executable files, which is a much more difficult way to hide. File size & checksum scanners have been around for years, and will find that sort of thing if not properly done. Also increasing the difficulty level, most OS binaries on *nix are writable by root, so you have to compromise root before you can hide there.
I don't believe I'm explaining this stuff to Reg writers :-(
/gds
Eventually they'll discover what every other corporation that's taken this path during the past 8-10 years has already figured out - what ever engineering projects they were working on (IT or otherwise), once outsourced, will take at least three times as long and will require at least three time as many many man hours (read warm bodies) as the same projects would have required if they'd kept the project(s) in-house.
i.e., ultimately, a Net lo$$
You'd think after all this time they'd have bothered to at least look into the experiences of those who've trod this well worn path before them. But no! We're a high-falutin oil company, we don't need to pay any attention to others mistakes!
Sorry Royal Dutch Shell, I can't have any sympathy for you - you took the ID10T's solution on this one.
/gds