Become a fan of Slashdot on Facebook


Forgot your password?

Comment Re:Not to undermine the enthusiasm but... (Score 2) 180

Apache does not require release of source AND does not have the advertising clause of the "older" BSD licenses, so I'm not sure what about this project might be violating the Apache license. Overall Apache is pretty permissive and it's hard to violate except by providing source code but claiming said source code as your own (e.g. removing copyright notices and replacing them) - strangely, releasing a binary-only Apache component with no advertising (e.g. every Android device on the market except for Nexus devices) is more legal than releasing source for the component that removes all original author credit. I do recall the Android-x86 guys were pretty unhappy about RemixOS being effectively a for-profit kang, but the nature of Apache was such that there wasn't much they actually could do about it.

GPL is a whole other story. If they are failing to provide sources in compliance with the GPL then they can burn. (Technically they have to provide sources themselves, but I will let someone slide who says "We used unmodified upstream sources which can be found at X" when there is no evidence to the contrary.)

Comment Re:Another good idea that will get shut down (Score 1) 180

Yeah, as much as I like Android, it is not suitable for desktop systems except for a few special niches.

I can see it making sense for someone to do an HTPC build that was Android-based in order to run Android games. But to be honest a SHIELD Android TV would be an easier/better/likely cheaper solution for Android games, especially since many of them only have ARM native components and have a severe performance hit on x86.

It makes no sense as a desktop/educational OS right now - which is why the Pixel C has been slammed by so many for having an OS inappropriate to the type of product.

Comment Re:First world problems... (Score 1) 227

It's pretty clearly specified that if you enable Binge On with your account, your data gets throttled.

The only hole seems to be that there are certain cases where having Binge On enabled results in a throttle but not "free" data from the sounds of it.

I have zero problems with this since you, as a user, CAN TURN IT OFF. (TFA indicates that the issue is users who have Binge On enabled causes throttling in cases of providers not part of Binge On.)

Comment Um... WTF? (Score 1) 44

"Writing VLC in JavaScript and other Web technologies, as Chrome OS requires, is not an easy task by any stretch."

No... ChromeOS has ways to write native and semi-native apps:

NaCL - and PNaCL

That said, if you already have a functional Android app, ARC is probably easier. Works great for Quasseldroid if you remove one socket configuration call (TCP_KEEPALIVE socket option) currently not supported by ARC.

Comment Re:No mention of the ISP "Netflix box" (Score 1) 181

That's probably part of it. The Netflix Connect box eliminates much of an ISP's backhaul costs.

In T-Mobile's case, their backhaul costs are probably not nearly as much as their spectrum/tower costs. (Although I know in the early LTE transition days, tower backhaul WAS an issue, but I think Netflix's solution was more of a provider core network thing...) So perhaps I should treat "backhaul from Internet to core network" as different from "backhaul from core network to tower". This system helps them manage the backhaul from the core network to towers and then on to the phone, as that's where most of their costs lie.

The things that have triggered many of the big NN debates have been providers throttling their connectivity to the rest of the world - "core-to-Internet" backhaul. Many of these providers have more than enough core-to-customer bandwidth.

Comment Re:Bennett Haselton is so SMRT (Score 1) 181

That doesn't seem to be the case for Binge On, since T-Mo states their criterial in a public document:

In some ways, the way I read it is that T-Mo will effectively spend money (in terms of engineering resources/staffing) in working with a content provider to come up with a proper solution.

It sounds a lot like how some people have described our wired Internet infrastructure in large hubs works - frequently engineers from multiple providers would work together to come up with the optimal solution, sometimes with one provider loaning equipment to the provider connecting to them. At least - that's the way it worked until Verizon or Comcast started pulling their shenanigans. (There was a really good writeup 1-2 years ago shaming one of the providers that was trying to extort Netflix by intentionally not upgrading any link to one of Netflix's backbone providers, which would also punish anyone ELSE on the same provider. Verizon said it was too expensive, the backbone provider replied along the lines of, "bullshit, it requires $20k of equipment we're happy to provide ourselves that we have sitting on a shelf 10 feet away from where it needs to be, we just need permission to install it."

Comment Re:Kickbacks? (Score 1) 181

The "kickbacks" could be in the forms of "technical support".

While the theory posted in the article (that automatic rate adjustment) indicates that this should be OK with any content provider, the truth is, rate detection of some providers (think in 2014 for example, and SlingTV at all times) is REALLY horrible.

Let's face it - you're going to get much better rate detection (for example, not even bothering to try a 720p stream) if you can explicitly tell the content server - this connection will NEVER go above X mbps.

One use case they could be specifically trying to avoid is: Server automatically attempts 720p. User gets stuttery/buffering video for a few seconds before the ratelimiter detects the actual bandwidth of the connection and drops down. Some ratelimiters (just like TCP's congestion control) may be very aggressive and might drop to 360p before going to 480p after some period of reliable 360p video. If the carrier (I'm guessing they're implementing a proxy in this case based on how they're describing it...) explicitly states they have a ratelimit of X mbps, the streaming server can automatically choose a quality setting just under this limit, rather than spending 10-20 seconds or more trying to determine what it is.

Comment Re:Zigbee is at fault (Score 1) 358

Yup. I've always been surprised at how a proprietary and closed standard (Z-Wave) provided superior interoperability to an open one (ZigBee Lighting Link).

ZLL interoperability is rare. I purchased the Hue specifically because it had the capability to add "other" ZLL lights such as Cree's bulbs. I also 100% ditched Greenwave's crap because it had zero interoperability with anything and they broke the ability for any other HA system to command their gateway.

Comment Grumble... Time to sell my Hue? (Score 1) 358

I tried a few "Connected by TCP" lights (actually made by Greenwave IIRC) and had them working well with my Vera.

A firmware update for the controller rendered them unusable with anything but Greenwave's own app.

So I bought a few Cree smartbulbs to replace them and use with my Hue system - they have been working great for over a year.

Now Philips is going to block these perfectly-functioning lights? FU Philips. The only reason I use your products is that they integrated well into my home system. If you force me to use your products separately from the rest of my home control systems - you'll force me to ditch your products.

Comment Re:Wait a minute (Score 1) 91

You just (mostly) described the Dexcom G4.

Sensor wire that effectively acts as a fuel cell powered by glucose is embedded under the skin for 7 days. (measures interstitial fluid glucose concentration instead of measuring blood directly). On top of the sensor wire is a small clip that a transmitter clips into. This periodically samples data and transmits it with a very low-power RF transmitter (TI proprietary protocol) every 5 minutes. 6 months battery life for the transmitter.

The new G5 system uses BLE, which takes battery down to 3 months despite being physically larger. :(

Getting a sensor to last past 7 days is possible, but it becomes a game of chance. Past 7, risk of infection/scarring/biofouling increases. Longest I've ever worn a sensor was 13 days and honestly I'm not doing that again (that site is healing more slowly than I'd like...)

Comment Re:As a diabetic (Score 1) 91

CGM's such as Dexcom's G4 are pretty close to this. The main disadvantage is you need to insert the sensor under your skin once every 7 days... But then fingersticks are only needed for calibration purposes after that.

Well technically you're not supposed to make treatment decisions without a confirmation fingerstick, but... Most diabetics including myself will go for the carbs if there's any possibility the CGM is correct when it says 55.

Comment Re:As a diabetic (Score 1) 91

As a diabetic, I'm actually not too impressed. Remember needleless injectors? Yeah, they do exist and are still in use in cases where people want to give mass vaccinations in an assembly-line fashion, but they're actually much more painful than needles. This patent sounds a LOT like a needleless injector. All of that mechanical complexity is going to make it significantly larger (and hence less convenient) than a traditional lancing device.

Its benefit is minimal since fingersticks are on their way to being relegated to being a calibration source for CGM systems. I believe Dexcom's goal is to reduce from 2 calibrations per day to 1 with the G6. Admittedly, I still usually do 3-5 fingersticks a day, but I used to do 5-8, more if I suspected my bloodsugar was being wacky.

From one diabetic to another - under the assumption you're Type I - the Dexcom G4 was a life-changer for me. I would absolutely recommend it to any Type I diabetic. Being able to see my bloodsugar simply by looking at my watch (xDrip + NightWatch + Moto 360) is amazing.

Slashdot Top Deals

10.0 times 0.1 is hardly ever 1.0.