Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re: There's a semi-good reason (Score 1) 161

And *you're* missing the fact that you aren't going to get 50-100mbps over more than about a half-mile of copper with any current technology.

Uverse runs fiber to the node because it's the only practical way to *PUT* a VRAD with enough backhaul capacity to handle thousands of users streaming HD Netflix within ~2000 feet of those customers.

It's not a question of statutory law... it's a matter of PHYSICS. The fact that ADSL2 can achieve 12mbps up/1.5mbps down is borderline-miraculous, considering that 20 years ago, most RBOCs wouldn't even let you sign up for 1.5mbps/256kbps ADSL if you were more than a mile or two from the nearest CO.

There's no organized lobbying to force RBOCs (and their direct delegates, like AT&t Uverse & CenturyLink Prism) to let independent ISPs use existing copper from neighborhood nodes because there's nobody for whom it would actually be a viable business model.

If ${ISP} had to pay U-verse $60/month wholesale-rate to VPN traffic from one of ${ISP}'s customers to ${ISP}, and Uverse ITSELF charged $70 to directly provide the same level of Internet access, how many independent ISPs could genuinely provide comparably-fast Internet access without going broke with only $5-10/month?

Remember: Antitrust law exists to protect consumers, not competitors or business models. Within the constraints imposed by VDSL2, it's hard to argue that consumers with 25-100+mbps service are being harmed by the lack of competition... any viable alternative involving access to RBOC assets and comparable high speeds would cost more than anyone would willingly pay.

The only consumers who *might* benefit are those who'd be content with cheap, slow (say, G.Lite-speed) internet access (who are currently told, "our cheapest service is $50/month for 12/1.5", but for only a few dollars more, you can get 2-8x that speed). Frankly, I'm glad my senior-citizen and poor neighbors are forced to buy expensive service that's faster than they "need", because it subsidizes the infrastructure required to let *me* have fast internet access at semi-affordable prices. If I could get gigabit fiber for $100/month by forcing everyone to pay $50/month in 'fiber fees' (regardless of whether or not they actually USED, or even WANTED to use, their fiber), I'd do it in a heartbeat.

Comment Re: Scheduling - It depends! (Score 1) 121

Exactly. An Android developer might know something is 'easy', but forget that it's only easy due to a new API that came out 3 years ago, but is STILL 1 or 2 versions ahead of the minimum version of Android for which the customer demands compatibility. Sometimes, it might be merely 'hard' to achieve something with an older version (ex: pdf-rendering, which didn't exist as an Android API until Lollipop). In other cases, it might be borderline-impossible to achieve with older versions... for example, low-latency audio (Marshmallow... on *some* devices... kind of...), or programmatically manipulating the appearance & location of the arrow pointer that appears when you attach a bluetooth or USB mouse (impossible without a custom ROM prior to Nougat!).

In the Android realm, estimation is even harder because "mainstream" Android devices are usually 2-3 entire releases behind the "current" one (and developers tend to have devices at the newer end of the spectrum), in which case we're talking about the loss of API functionality that's been present in newer versions for 3 or 4 YEARS. To Android developers, that's a *major* and frustrating mindfuck... it would be like being asked to estimate a Java project (in 2017) where you weren't allowed to use anything newer than JDK 1.5 (1.5 is ancient history, but the gulf between Java 5 and Java 8 is probably *less* than the gap between Kitkat and Nougat is today. I've been writing Android software since 2009, and I *still* get caught off guard by discovering that some core functionality that's been part of Android seemingly *forever* is *actually* post-Kitkat.

Comment Re:There's a semi-good reason (Score 1) 161

ADSL has a range of a few miles, but as you observed, it maxes out around 13mbps. VDSL2 is another matter entirely.

ADSL was viable for CLECs to lease wires, because they could rent rack space in the RBOC's CO and serve thousands of customers. VDSL2 blows that whole business model out the window... the only practical way CLECs could be accommodated with VDSL2 (due to short distance limits) is if the RBOC provided the VDSL2 network connectivity to the customer, then routed that customer's traffic over to the CLEC... and there's no way a CLEC (besides *maybe* Verizon, operating outside its home market) could actually make money doing that. And with U-verse, it would be largely pointless... the RBOC's customers would be paying more, and getting slower internet connectivity in return.

Comment There's a semi-good reason (Score 2) 161

With ADSL, you can upgrade one CO and spread the costs among rich AND poor areas. With VDSL2, your meaningful service area is about 1,000 feet... and deploying a new VRAD in an area without existing fiber within a mile or so isn't cheap. Unless they can find enough rich people within a thousand feet who can't get service through an existing VRAD, those poor areas aren't going to get faster service.

God, it hurts defending AT&T... but even if they were actively benevolent, VDSL2's short range makes it really hard to cost-effectively serve poor areas UNLESS those poor areas have lots of people willing and able to buy premium internet service.

Going back to the rural electrification argument, yes, you can force the power company to provide you with power almost anywhere adjacent to a public road or right-of-way... but if you decide to build an Aluminum-smelting plant in the middle of nowhere (Aluminum-smelting uses a STAGGERING amount of power), you can't legally (or reasonably) expect the power company to upgrade 100+ miles of wiring for free, even if they WOULD provide you with up to 500A service for free.

The best way California can get Uverse into poor neighborhoods? Find all the properties in the area owned by the city/county/state due to unpaid liens, and offer one per ~2,000 feet to AT&T for free (waiving those liens) as a neighborhood VRAD site. Most poor areas have vacant properties that can't be sold, because the liens exceed its value. Making some of them available to AT&T as VRAD sites would make it easier for AT&T to justify the cost of deploying 50mbps+ VDSL2 into those areas.

Comment Re: I thought Linux was supposed to be secure? (Score 1) 108

Insecurity isn't a necessary component of corporate data-harvesting... it's quite possible to make a device with robust, impenetrable security that encrypts & transports vast quantities harvested data to its corporate masters.

These are the REAL problems with most IoT devices:

1. Devices with 8-bit MCUs that treat the internet like a UDP-implemented serial port & have no meaningful security of their own.

2. Linux's (intentional) lack of a stable kernel ABI, which makes it all-but-impossible for end users to take control of their own destiny and upgrade devices long after they've been abandoned by their manufacturers.

3. The lack of meaningful public documentation of the underlying SoC. If MediaTek, Qualcomm, etc. doesn't make proper datasheets available to the public, reverse-engineering some generic nameless webcam is going to be *really* hard unless you have access to the hardware & software tools usually owned only by companies or universities.

If somebody can name a sub-$60 IP camera with official open-source firmware, I'd *love* to be proven wrong, but the fact is, sub-$60 IP cameras are practically large-scale integrated circuits *themselves*. Seven times out of eight, not even the nominal *manufacturer* of the camera has access to the full sourcecode to its firmware... they buy some SoC, assemble it into a camera based on some generic reference design, and get all the firmware & drivers verbatim from the SoC's manufacturer (like the thousands of knock-off "Foscam-type" IP webcams).

Comment Re: "Destroyed" is such a harsh term... (Score 1) 88

plus, "JTAG" is very implementation-dependent. AFAIK, for example, you can't use an Atmel JTAG-Ice200 to reflash anything besides specific Atmel MCUs. Want to reflash a PIC? You need to buy yet another proprietary JTAG programmer. And so on, for every common microcontroller family. And if some third-party (Keil?) DOES make a multi-platform JTAG, it will be (a) mind-blowingly expensive (like almost every 'pro-grade' tool for non-hobby embedded development), (b) suck, or (c) both.

Comment Re: 24 cans (Score 1) 223

If you consumed 24 cans of Diet Mtn Dew or Diet Pepsi per day, you'd spend the NEXT day with horrific, explosive diarrhea and a pounding caffeine-withdrawal headache... assuming you didn't die from cardiac arrest first. At the VERY least, the cardiac arrhythmia would be pretty unpleasant. 24 cans has about 1.2 KILOGRAMS of caffeine (24 cans * 50mg/can).

Comment Re: Neat--until... (Score 2) 218

Though they weren't really relevant to PCs or Windows, the Coldfire chips are a good example of this kind of design change. Though they were marketed as having a m68k heritage, they basically took away most of the instructions and addressing modes that made the original 680x0 so incredibly convenient to program in assembly language.

RISC processors were developed to be efficient and cheap. The m68k was developed to be convenient for assembly-language programmers. The 680x0 family indulged programmers in ways that would be almost *inconceivable* today (it even had a instructions for manipulating binary-coded decimal... they weren't terribly useful on computers like an Amiga, ST, or Mac, but apparently were a Very Big Deal(tm) back when programmers had to routinely deal with legacy BCD-encoded data from mainframes. Being able to directly manipulate BCD values meant not having to go through the trouble of converting them to and from 8/16/32-bit values first.

Examples of things Coldfire took away:

* the "decrement and branch conditionally" instructions. Sure, behind the scenes, they were basically two simpler instructions automatically glued together and executed back to back from a single opcode... but damn, they were nice to have.

* most of the immediate addressing modes not involving a register as the source or destination. On a 680x0, you could stuff a specific byte value into an arbitrary memory location by doing something like, "MOVE.B #$69, $dff000" (storing hex 0x69 in address 0xdff000 in a single gulp). On a Coldfire, you have to load-then-store (load $69 into a data register, then store that register's value at the desired target address).

* and of course, all the BCD-related instructions (ok, losing THEM didn't really bother me much, as you probably guessed... but I probably would have loved them if I'd been born about 10 years earlier).

Comment Re: Nope. Bought a Nexus years ago; disappointed. (Score 1) 119

OK, fine. Try this: name one real phone available for purchase today by end users with the following features:

* full-speed compatibility with at least one American phone network. This is a hard one, because thanks to bastardized American LTE, even our nominally-GSM carriers have become as de-facto proprietary as Sprint & Verizon.

* 2GHz+ CPU, 3+ gigs of RAM, and 64+ gigs of fast flash. Bonus points for microSD, removable battery, and/or the ability to charge quickly.

* 2160x1440 or better display.

* Released with all the sourcecode, build scripts, and documentation necessary for knowledgeable end users to independently implement support for later releases of Android, even without the active blessing or cooperation of the vendor.

The problem isn't that Linux EVER breaks binary compatibility... it's the fact that it routinely and casually breaks binary compatibility up, down, left, right, diagonally, and with "three snaps in 'Z' formation" with every single new build (let alone version).

The fact is, end users are powerless to exert any kind of meaningful market influence or economic pressure over Qualcomm, because they have a de-facto monopoly over American LTE. If you want full-speed LTE on an American network, it's basically "Qualcomm or nothing". At least if we had some degree of meaningful binary kernel module compatibility, we could limp along with the original binary drivers when a new version of Android gets released and the phone's manufacturer has abandoned it because it's no longer a current model.

Comment Re: Nope. Bought a Nexus years ago; disappointed. (Score 1) 119

> Seemed to contradict yourself there, son.

Not really. There's no contradiction between, "they have the institutional knowledge and resources to do it" and "Google's management isn't interested in dedicating their best senior developers for several months to take leadership of Android's binary kernel-driver problem".

The fact is, if it weren't for Android, Linux's device driver issues would be mostly irrelevant, because they'd meaningfully affect *maybe* a few thousand actual users. Google is the entire reason why roughly 97% of the Linux-running devices on earth actually RUN Linux, and it's high time they took responsibility and assumed leadership for fixing its driver and bootloading mess for the sake of Android's own users. Because god knows, there just about the only ones in a position to actually DO it. Gnu would rather have everyone rot in Tivo-ized hardware hell for all eternity than concede defeat to Qualcomm for the sake of empowering end users to make the best of a situation with only bad and worse alternatives.

The biggest single problem with Android phones and tablets is the fact that, with the POSSIBLE exception of Intel-based Chinese devices capable of dual-booting Windows and Android, there's no direct equivalent to a PC BIOS (and even with dual-boot devices, it's iffy). On a PC, there are well-defined universal standards for making an operating system bootable from fixed and removable storage media that have evolved in compatible ways since the 1980s. Everyone agrees upon where the boot sector goes, where in RAM it should be loaded, and how it should be interpreted during the first moments after powering on the device. With Android devices, there's no such thing... every single vendor does it differently, and most of them take advantage of the opportunity to lock down the device and exercise control the owner's experience long after its purchase by the end user.

Comment Re: where's the PC of Mobile Computing? (Score 1) 119

Actually, I developed software for Windows Mobile for work back around 2006-2008. ;-)

One feature I really, really miss from dotnetCF -- it didn't force you to bend over backwards and write explicitly-asynchronous code when you were trying to implement some blatantly-linear activity (like "display a form on the screen", "submit its contents to a server and wait for the response", "deal with its response", "display the next form", "submit its contents to a server and wait for the response", and so on). You could literally just wrap it in a dotnetCF class that allowed you to write it as a faux single-threaded sequential task, and let dotnetCF itself do the UI thread-juggling for you. It wasn't the OPTIMAL way to write an app like that, but it made implementing a simple sequence of submitted forms absurdly easy to do. I wrote my first server-submitting dotnetCF app in about 3 hours (most of which was spent reading a few chapters of a book)... I think my first Android app that did something comparable took the better part of a week to write. It amazed me how complicated Android managed to make things that were absolutely TRIVIAL to do with Windows Mobile.

The biggest single weakness of WinMo was the fact that it was LITERALLY impossible to develop a custom WinMo 5 or 6 "phone/dialer app" using dotnet compact framework... you could only do it in C, using (semi-)private APIs with minimal documentation and no example code to speak of. But from what I recall, that was actually one of the new features that were supposed to be in Windows Mobile 7.0 (before Microsoft abandoned it).

Comment Re: Nope. Bought a Nexus years ago; disappointed. (Score 1) 119

Another major annoyance: no Android phones -- not even NEXUS phones -- allow you to use the stock rom as a STARTING POINT for further modifications (by furnishing a build script with complete source and any binary blobs required to build the stock ROM). Instead, you're forced to throw the baby out with the bathwater, and reimplement the phone's functionality in its entirety (since AOSP itself usually has major stock features missing, even for a Nexus).

For YEARS, I've been wanting to make a slightly-modified kernel that acts like you have the display orientation set to "manual", BUT reads the accelerometer and sets the orientation ONE TIME immediately after the user toggles the display off and on by pressing the power button twice. Basically, offering a compromise between "auto" and "manual" -- "semi-automatic". Toggling the power button twice is a quick & easy gesture, and IMHO setting the orientation immediately (but ONLY) after turning on the display is just common sense. It blows my mind that anyone at Google thinks the way auto-orientation has worked ever since we lost slide-out keyboards is actually acceptable. At the very least, Google's auto-orientation-setting routine should have enough logic to notice the user violently rotating the phone (and maybe listen for an angry "God DAMN it!") in the immediate aftermath of an auto-orientation change... especially when the phone's display is angled downwards (ie, the user is lying in bed holding the phone above his face).

I'd also love to implement what I call "CrashCam Mode" -- Crash, as in "you see a jet about to crash (or some other newsworthy event, like a police officer beating the crap out of a 95 year old woman in a wheelchair) and only have a second or two before it'll be too late to film the million-dollar video for CNN". Basically, if the user presses the power button four+ times within 400ms, instantly disable autofocus, set focus it to infinity, and start capturing video at the maximum resolution and framerate while launching the camera app itself. For good measure, if the camera supported 120fps, you could have the odd frames be set to some exposure suitable for either indoor lighting or morning/late-afternoon daylight, then alternate the even frames between under-exposed and over-exposed (to ensure that you'd end up with at least 30fps of usable video if the lighting were really dark or bright).

Oh... and I'd also remove the 911 emergency-dialer-without-unlock that seems to be the new norm, and make it impossible for the dialer screen to activate unless I've either fingerprint-unlocked the phone, or done a complex gesture like the Donut/Eclair/Froyo-era "deliberately slide the dot along a precise arc to unlock". Frankly, I'm more likely to die from an aneurysm in a moment of rage after hearing DTMF tones coming from my pocket (when the phone is SUPPOSED to be locked) than I am to die because some random onlooker couldn't use my phone (instead of their own) to call 911.

Comment Re: Nope. Bought a Nexus years ago; disappointed. (Score 5, Insightful) 119

The difference is, "desktop" Windows has historically given us compatibility with drivers written for older versions (sometimes, as old as NT4) -- imaging drivers being the one notable exception due to TWAIN's brain-dead pre-WDM architecture).

In contrast, Linux only abstracts its ABI for *applications*, not the kernel itself. For example, suppose I have a 4.10.10 kernel compiled for AMD64 using gcc, and a loadable kernel module built for that kernel. Now, suppose I have an identical computer running a 4.10.10 AMD64 kernel compiled with Visual Studio (just to give another widely-used compiler as an example). In most cases, the .ko file built for the "gcc" kernel will die a horrible death on the "Visual Studio" kernel... or possibly, even another 4.10.10 kernel compiled with gcc using slightly different options.

Basically, Linux doesn't even *try* to maintain driver binary compatibility, even within THE SAME KERNEL VERSION, while Windows bends over backwards to maintain driver compatibility more or less "forever". AFAIK, it's an ideological decision... Linux's developers *want* to punish users of binary drivers & inflict the maximum possible pain, totally ignoring the reality that end users (or at least, users of cell phones capable of doing LTE on American mobile phone networks) have ZERO influence on Qualcomm or Nvidia's licensing policies... ironically, empowering VENDORS over end users in the process.

Riddle me this: why could Linux use binary wifi drivers built for fsck'ng WINDOWS (via NDISwrapper), but can't even maintain binary compatibility between two sequential kernel releases with only minor differences? It's insane. I don't even blame Linus... I blame Google. Google has some of the best Linux kernel experts on planet earth. They could EASILY add an abstraction layer that preserved binary .ko compatibility across at least a few releases (think: a stable, open-source thunking layer that Android-certified drivers were required to use instead of directly referencing kernel structures... new release of Android? Just compile a new thunking layer for old binary drivers to use instead.)

Comment Re: Flash another ROM (Score 3, Informative) 119

It might be a Verizon S4... VZW takes bootloader-locking 'evil' to creative new heights (lows?).

Apparently, when the Note 4 came out, Verizon actually paid extra to Samsung for them to protect the Sprint version's bootloader the same way (Sprint itself was indifferent) just to make sure there wouldn't be another CDMA model with easy-to-unlock bootloader. From what I recall, the Verizon model of one of Samsung's earlier phones could be cracked by flashing a Sprint bootloader to the Verizon phone... it temporarily bricked the phone (or at least disabled the radio modem), but then you could unlock the easy-to-unlock Sprint-version bootloader & reflash it with a second bootloader that was basically a Sprint Android bootloader w/ripped Verizon radio modem firmware to give you a working, bootloader-unlocked Verizon phone. Verizon was determined to keep it from happening again.

Slashdot Top Deals

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce