Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Reminds me of "Napster for long-distance calls" (Score 1) 240

This reminds me of a late-90s first-dotcom-boom service that was planned to be like Napster, for long-distance phone calls. The general idea was that you'd run a server program on your pc that made your winmodem and phone line available for others to use for making phone calls that were long-distance for them (over the internet), but local and free for you.

It was a great idea, until assholes started using it to make anonymous bomb threats using other people's phone numbers. I think the service lasted for maybe 2 months before it shut down.

Comment Re:It's 2010 again (Score 1) 217

Right... they don't... and it's their single biggest drawback and design flaw.

Feeling a tactile click is no guarantee that anything will happen, but the knowledge that your action was unambiguously communicated to the device gives you a few seconds to cool off before angrily blaming the OS. Touch-only virtual buttons deprive users of that sense of satisfying closure, increase frustration, and harm the user experience.

That's why elevators quit using all-touch virtual buttons in favor of clicky, tactile buttons -- the clicky, tactile buttons don't get vandalized as often, and they can take a lot more punishment without expensive repairs when it happens. People who press a real button and feel the click will automatically assume their action was noticed by the device. With virtual buttons, uncertainty rapidly snowballs into rage and abuse. The physical motion and click provides a brief sense of reward and partially neutralizes what would otherwise be an urge to punch or smash the non-responsive control.

Comment Re:Properly designed (Score 2) 308

And clamping diodes & fuses pretty much eliminate any possibility of ultra-ultra-ultra high-speed serial ports, so kiss Thunderbolt, USB 3, and everything else goodbye. And probably wouldn't help much, anyway, since everything downstream from the port will likely be fried by the time the fuse finally melts & opens the circuit back up. If, by some miracle, a MOV wouldn't screw up gigabits-per-second-per-balanced-pair data transmission, most users are STILL looking at what's effectively a total loss because those MOVs rarely are easily-replaceable without at least intermediate-level electronics skills.

Comment Re:Try the British model (Score 1) 149

That's how it used to be about 10 years ago in many parts of the US.

The main thing that killed it was higher speeds. The way it worked just wasn't scalable to VDSL:

* The ISP had to colocate HIS OWN DSLAM at each central office where he wanted to serve customers AND make his own backhaul arrangements.

* AT&T leased a pair of copper wires to the ISP... and getting them to actually do a truck roll and send out an outside lineman to troubleshoot problems almost required divine intervention. And 99.8% of the time, it was ultimately AT&T's fault... usually, old loading coils.

The problem is that with VDSL2 speeds of 50-100mbps, the distance limit isn't a couple of miles... it's about 500-1000 feet. There's no way on god's green earth that Mom & Pop ISPs can afford to put their own VRAD cabinets within a thousand feet of every customer... even if they could afford it, having THAT MANY refrigerator-sized boxes would be a major blight. One AT&T VRAD? Ugh, but necessary. A half-dozen VRADs in a line, each owned by a different ISP? Never, ever going to happen (or even be allowed to happen). And remember, each of those VRADs needs fiber, air conditioning (in Florida, at least, to keep the equipment from overheating or corroding from humidity), and backup power.

The only way shared last-mile service is practical with VDSL2 is if the company who owns the wires provides TCP/IP carriage between the customer and their central office (with a VRAD/DSLAM and lots of fiber along the way), then hands it off to the ISP *there*. Which, I believe, is the way it's done in Britain.

Comment Re:What About DSL Routers? (Score 1) 149

What REALLY sucks is that the NVG589 actually HAS a place to stick a backup battery, but the modem's firmware shuts down literally EVERYTHING except the ability to make and receive voice phone calls (using U-verse's VoIP, of course) when it's on battery power. Disable WiFi? Maybe. But Jesus Christ, how much fucking power are they actually saving by powering down the goddamn ETHERNET PORTS? Especially considering that they STILL have to maintain the VDSL connection and router for VoIP to work?

Hell, if anything, I wish they'd give me two spare copper pairs and let me backfeed 48v into them to power enough of their VRAD back up to keep MY internet access working during an extended power outage (My generator gets fired up 10 minutes after the last radar-indicated rain band likely to hit for a few hours passes over... THEIR generator might not get fired up for a few days after a slow & sloppy tropical storm). Yeah, I know it's fantasy, but it really sucks being without service due to a power outage despite having abundant backup power of my own.

Comment Re:DVB-C (Score 1) 149

IMHO, SiliconDust was INSANE for not just asking Microsoft to sell them the sourcecode and IP rights to Windows Media Center in exchange for equity in SD and an agreement to license PlayReady from Microsoft going forward. Microsoft would have had nothing to lose, since they've basically abandoned WMC anyway, and it would have enabled SiliconDust to have a version working under Windows 10 (with full DRM support) in a matter of months. And it would be an epic win for Microsoft, because you'd still have to buy a copy of Windows to use it.

Alternatively... they should have written the core DVR first as a collection of scriptable commandline apps with full DRM support for COPY_ONCE-flagged channels. The idea isn't that end users would record and play shows via commandline, but rather that someone ELSE could then write a front end using Java (or C, or Python, or whatever) that launches SD's Recorder or Player app & opens a network socket to it to query for things like "current position" and send commands like "pause", "skip 30 seconds", "new position: 00:24:13", etc.

As it stands, SiliconDust has basically spent a year writing a mediocre DVR app that does nothing the free Linux DVR apps can't ALREADY do better. They just don't seem to get it... without DRM support and the ability to record & play COPY_ONCE channels, their DVR app is POINTLESS and has no reason to even exist.

Comment Samsung deserves it for non-removable battery (Score 4, Insightful) 63

I hope Samsung takes one HELL of a financial beating over this, because most of the cost will be well-deserved punishment for taking away removable batteries. Had the N7 allowed batteries to be swapped, they could have given anyone who agreed to surrender their defective battery two or three free replacements (total cost to Samsung: about $5-10 at eBay Chinese battery prices) and used customers as a vast, unpaid labor force to do the battery swaps. Instead, Samsung is going to have to eat the cost of a recall (including shipping) AND pay employees to swap the batteries & re-package the phones.

Comment Headphone jack vs waterproofing... BULLSHIT! (Score 3, Informative) 551

Apple is claiming they did it to make the phone waterproof. Apparently, they didn't bother to spend about 12 seconds with Google searching for "ip67 headphone jack", because if they DID, they'd have found countless IP67-rated headphone jacks like this one:

For those who don't know, the "7" in "IP67" means "waterproof to a depth of 1 meter for 30 minutes". I didn't have time to search further, but I'd be shocked if there wasn't at least one company that makes IP68 ("waterproof to a depth guaranteed by manufacturer, generally 1-3 meters, for some period of time also guaranteed by the manufacturer"). Note that IP ratings for things like headphone jacks don't guarantee that the jack itself won't end up with gunk in it if you drop it into mud, only that the jack ITSELF won't allow water to pass through to the interior of the phone case.

Comment Re:DRM ahoy :( (Score 1) 551

No, it's NOT "single-purpose". It might be MARKETED as "a headphone jack", but it's REALLY 3 raw GPIO lines plus a ground (or at least, two waveform outputs and one waveform input) constrained to specific sample rates).

Headphone jacks are a great way to hack up cheap circuits to do simple, analog(-ish) things, like sense the state of a switch or sample a resistive analog value (generate power from the mic port, then use the resistive sensor with a simple oscillation circuit to generate something you can analyze via FFT). Yeah, you can ultimately achieve most of this using the USB port (Android ADK, IOIO, etc)... but a bare headphone plug and a soldering iron is a hell of a lot cheaper AND smaller than the electronics you'd otherwise need to do even the most trivial i/o over USB. The ADK in particular is HUGE (quite possibly bigger than the phone itself), and even IOIO is the size of a USB flash drive.

Want to power something using the phone? Output a high-frequency sine wave at max volume. Feed it into a transformer, then regulate its output if necessary. Assuming you can't just drive it with a looping waveform of 0x7FFF at max volume to generate enough DC.

Want a serial port? OK... DB9 port, level-shifter IC, and a headphone plug. Some Samsung (and possibly HTC) Android phones actually shipped with kernel-level support for such hardware (I know the Galaxy S family did, and I'm pretty sure the Galaxy S2 family did, but I think Samsung quit building it into the stock kernel starting with the S3).

And let's not forget cool, useful things like thirdparty IR blasters and credit card readers that plug into the headphone jack.

An Android phone might begin its life as a phone and only get used as such for a year or two, but having useful i/o greatly increases the opportunities to repurpose old Android devices and give them a second life as security webcams, pet door monitors, touchscreen remote controls, etc. So yeah, the current villain might be Apple, but it's imperative that Android owners fight Apple's abandonment as hard as the iPhone community, and to come down HARD condemning any Android phone that does the same thing to keep other companies from blindly following Apple and eliminating headphone jacks on their top-shelf ANDROID devices, too.

Comment Re:DRM ahoy :( (Score 5, Interesting) 551

You can definitely make a tiny sensor array with higher technical resolution than traditional ISO 400 print film grain... maybe even ISO 100. The catch is, you'll have to light up the scene to retina-searing brightness levels like a color movie set from the 1930s, because your effective f-stop will be insanely high and/or your dynamic range will be unacceptably low & have too much random noise.

Big lenses and/or large-format film/sensors allow you to capture more photons and take pictures with less light.

Comment Re: Fragmentation (Score 1) 154

Except the fact that JavaScript absolutely SUCKS ASS on mobile platforms. Go ahead, just TRY going to using Chrome under Android to see whether a store near you has something in stock. It'll choke, stall, and metaphorically flop around on the ground like a soon-to-be-deceased fish.

Anybody who makes a web site that's entirely generated via JavaScript and ajax & consists of pages with nothing besides a single placeholder html tag deserves to get beaten to a pulp.

Comment Drivers (Score 1) 164

At the VERY least, Google ought to commit to releasing unsupported "best-effort" automated builds of binary kernel modules for proprietary hardware for at least 5 years. It's something that would take only a tiny bit of effort (or arm twisting) by Google, and would go a LONG way towards neutralizing the misery caused by Linux's lack of a stable kernel ABI by doing the ONE THING for us that we genuinely can't do ourselves -- build proprietary drivers from source so they'll work with a new kernel.

Alternatively, Google should come up with a slightly better alternative to loadable kernel modules that enables some reasonable degree of compatibility between kernel builds. Or just fork Android's kernel outright, and commit to keeping the kernel ABI stable (absent some really, REALLY good, compelling, and urgent reason) from release to release.

The really fucked up thing is, ten years ago you could do a guerrilla upgrade of a Windows Mobile 5 phone to Windows Mobile 6 by doing little more than copying .exe and .dll files from a newer phone. Thanks to Linux's total lack of kernel ABI stability, we can't even do THAT anymore (at least, not unless the kernel from that newer phone can ALSO run verbatim on the older one)

Slashdot Top Deals

Nature always sides with the hidden flaw.