Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Stop claiming supposition as fact (Score 1) 412

Nobody has ever said that the threshold is 100 GB! Verizon reps specifically danced around saying the exact number in every statement they've made.

The article claims the 100 GB figure as fact, which is extremely intellectually disingenuous.

In fact, there are compelling rumors (but still not facts, so please don't update the article claiming this as the truth) that only users with 500 GB or more data usage per month (on average, per-line) will be disconnected or forced to go metered. The original guy who leaked the info on Reddit is now saying he heard from Verizon management that the threshold is 500 GB.

But until people start getting letters and we can collect a representative sample of who did and did not get letters and chart that against their monthly usage, STOP claiming that you know any number to be true and accurate. This is the first step in being an ethical journalist and Slashdot can't even do this.

Comment Re:Time and place (Score 1) 284

I forgot to mention that the next "step" in the cat and mouse circumvention / anti-circumvention arms race is to ban encryption as well as any traffic that the DPI firewall can't "understand". This is the Brave New World of universal surveillance that we are headed towards. Countries like China, Australia and the UK are leading the way, and the US is going there too, just perhaps a little bit slower because organizations like the EFF and ACLU exist to try and gum up the works of the process.

It may take a few decades, but it will be within the lifetime of millennials that you will see encryption banned, and any traffic you try to send over the Internet that isn't fully understood by your ISP (regardless of whether you're on a home, work, or free hotspot connection) will be automatically rejected. So no VPNs or anything of the sort.

Comment Re:Time and place (Score 2) 284

The protocol negotiation and setup routines of a VPN are extremely easy to detect. When it's your "ISP" -- the network gateway providing your uplink -- that is trying to prevent you from getting on a VPN, it is extremely trivial for the gateway to block most VPNs because they have such well-known, "overt" setup/negotiation protocols.

Even OpenVPN on TCP port 443, which by all counts looks a helluva lot like a standard HTTPS connection, has just enough of a "tell" that it can be blocked while the gateway still allows normal HTTPS connections over the web.

While it's true that *endpoints* on an already established VPN tunnel cannot tell that the traffic is being handed to another client over a VPN, it is very easy for a *gateway* to detect all but the most stealthy VPNs.

That's why I said that specific mitigations (in terms of traffic shape and protocol "appearance", using steganography if required) are required if you want to bypass this kind of "anti-VPN" restriction on the gateway you are connected to (for instance, a free WiFi hotspot that's trying to block porn, and then tries to block VPNs to prevent people from using them to circumvent the block).

It's not even about setting up your own server. I could give you a description of a certain sequence of packets that will identify OpenVPN connections (even over TCP) 100% of the time, and never false positive on anything else. You could safely implement that rule on *all* remote IP addresses on a stateful firewall gateway and prevent people from using OpenVPN, regardless of the port.

Comment Re:Time and place (Score 3, Interesting) 284

That's why you just need to make your VPN traffic look like normal web traffic. There are various protocols out there that are so obfuscated that even a deep packet inspection firewall couldn't tell that it's not ordinary web traffic.

It adds overhead and latency, but it's really not that difficult to do. Somewhat ironically, it is based on the exact same principle as terrorists use to infiltrate countries they want to blow up: you become really, really good at looking exactly like the sheeple. You don't stand out. You look perfectly ordinary just like the rest of the law-abiding citizens. Except that the *semantics* of the data you're transferring -- which no firewall or DPI could possibly understand -- are such that porn content (or whatever) is being delivered to your computer.

Blocking is for deterring casual use, not for actually preventing something from being done. See: Great Firewall of China.

Comment Prices HAVE come down (Score 1) 729

In absolute terms of the cost per teraflop of GPU compute performance, prices have taken a nosedive this year. The release of the GTX 1080 and 1070 drove down the price of the 980 Ti, 980 and 970 which are still more than adequate for all gaming at 1080p (even on very high settings). The AMD Radeon RX480 has given a huge boost to the $200 price point as well, providing 5-6 TFLOPS at a price point that could net you *maybe* 3 TFLOPS if you shopped sales, before around Q2 2016 (with the release of the 16nm FinFET TSMC process cards).

There are extremely few games that will really bottleneck on the GPU if you have an RX480 or similar level of performance (with max or nearly maxed settings and 1080p60). In 5 years, even AAA games will still run smoothly on Low-Medium detail on the same card.

The only reason you'd need a beefier card, or SLI/CF, is if you go above 1080p60 (which is distinctly in enthusiast territory at this time, not because of the cost of the monitor but because of the additional load that imposes on the GPU(s)) or if you want to keep playing the latest AAA titles on the highest possible graphics settings over the next half-decade.

The only game I can think of right now that gives these cards a run for their money is a 150-million-dollar, crowd-funded, tech demo.

Comment Re:Please don't kill 32-bit Wine (Score 1) 378

Unless those libraries are shipped by Ubuntu, though, you'd have to either use a prior release or run a non-Ubuntu OS in your container in order to handle this. A lot of people would like to use the versions of libs shipped by Ubuntu on their 64-bit system, but compiled for 32-bit, to do their 32-bit work (e.g. Wine).

So yeah, it would do a lot of harm to many use cases and workloads if they stopped providing 32-bit libraries at the very least. If they want to drop 32-bit kernel support, it would affect way fewer people, because there aren't many systems still in use today that only run x86 and not x86_64.

Comment Re:Colour me skeptical... (Score 1) 298

True, but the pilots of the plane taking off could have, hypothetically, possibly taken off and avoided the collision by flying over the top of the other aircraft, if they were able to near-instantaneously dump most of their mass. Certainly the V1 for any aircraft is a lot lower if it's lightly loaded vs. fully loaded.

However -- I think what the "Funny" post above was referring to (facetiously) was that just jettisoning the cargo and economy passenger mass would be enough to reduce the V1 to the point that the plane trying to take off could do so before slamming into the other plane.

This isn't actually possible, though, because most of what makes a loaded aircraft heavy is its fuel, especially if it's going any significant distance. You'd have to have a way to safely jettison all but a few minutes worth of fuel, *and* the cargo, in basically a second or two, in order to successfully climb over the top of the plane directly in your path, in fog, with a very large jet like a 747 (and those older generation 747s had significantly less powerful engines relative to the aircraft mass compared to today, so it would be harder due to the engine technology as well).

Of course, modern radar, communications, computers and human vigilance are designed to prevent the type of runway incursions and collisions that occurred in Tenerife. The best solution to this problem is to control the situation, such that the one plane never incurs on the runway takeoff path of the other in the first place. Then things like ability to jettison cargo/fuel or take off suddenly become de-emphasized, the more certain you become that runway incursions won't happen.

Sadly, airports like LAX continue to have frequent runway incursions and quite a few near misses. There are a few airports that really make me nervous because they are simply too busy, and the sheer number of moving planes, ground vehicles and people makes it very risky as an operating environment for commercial aviation, even though the planes themselves would be perfectly fine when they're up in the sky, and perfectly fine taking off or landing at less busy airports.

Comment Please don't kill 32-bit Wine (Score 5, Interesting) 378

We at least need enough 32-bit packages available in the 64-bit distro (whether by dpkg --add-architecture i386, or by installing "lib32" packages like we used to do) to install and run Wine.

You see, to run Win32 programs, your Wine emulator binary needs to be a 32-bit Linux/ELF application. I suppose it could emulate cross-architecture, but wine prides itself on *not* emulating native code generation (for performance). Otherwise it would be as slow as a software virtualization solution like Bochs or (non-KVM) qemu.

Wine, in turn, depends on a number of system libraries for core services. It then implements common Windows APIs "in terms of" available platform libraries. Direct3D in terms of OpenGL; DirectSound in terms of libasound2 or libpulse; etc. These libraries, linked into a 32-bit binary, must also be 32-bit.

I agree that there's no point in testing 32-bit *hardware* any longer, but I hope they continue to ship 32-bit *builds* (even if they stop making 32-bit installation CDs). There's just too much software on the Win32 platform that needs to run on Linux (desktop OR server; see game servers) to abandon this segment of the market.

Comment Re:Devil's Advocate (Score 1) 595

1. Shielding - Never had any problems in any phone I've ever owned. If shielding is an issue in the "new & improved iphone", then add a damn 1/10th of a mm and put some shielding back in. I'll trade a bit of imaginary interference for bluetooth
                drops & pairing difficulties any day.


I guess you never sit your headphones on a busy desk with cables, laptops, etc. then. I had Sennheiser HD-25 II wired studio monitoring headphones with one of the best-shielded cables made for headphones (steel and very thick) and the EM emissions from the IGP on my laptop (a Westmere i5; this was years ago) would be very audible over the music streaming from my MP3 player (this was before I got a smartphone with enough storage and CPU to play music). Newer Intel procs are better at reducing EM, but cheap headphone cables will still pick up emissions several inches away from a desktop with a Skylake i7 in my limited testing. These CPUs will happily spew harmless electromagnetic emissions that get converted into arbitrary sounds by your headphones when the conductor in your cable picks them up.


Also, the only bluetooth drops and pairing problems I've had in recent years were all on Android. I moved from buying Android phones (numerous, from 3 different manufacturers, all had the same problems with BT) to an iPhone 6S Plus, and I have not had a single BT dropout, not a single one in like 9 months. And pairing always succeeds immediately.


For my desktop and Windows laptop I use an Imperial BART 1 bluetooth transceiver (with aptX Low Latency) as an intermediary, with the sound being sent to the BART 1 from the motherboard's S/PDIF digital (TOSLINK) port. So the entire audio path is digital. 24-bit 48 kHz, too, which is better than the 16-bit 44.1 kHz that 99.9% of the people are using, and not audibly distinguishable from even higher bitrates and sample rates in most studies (the law of diminishing returns).


This allows me to have two pair of headphones, total -- one I keep at work and one I keep at home -- for all my headphone needs across desktop, laptop and smartphone. And both headsets double as a serviceable mic to take phone calls, either over Skype or the cellular network. And I never have to tangle with cables.


2. Finicky jacks - this is perhaps one of only two points that I think has some credence. I've had a couple of finicky jacks myself but you know what--a quick squirt of contact cleaner solved the problem perfectly. Want to talk about finicky? Bluetooth
                pairing on some devices. You know what's even more finicky? When your BT headset battery starts to wear out and you can't replace it. Wired headsets have a much longer lifetime than BT headsets.


I only buy BT headsets with user-replaceable batteries. What kind of junk are you buying that doesn't? Beats? People actually think Beats BT headsets are good, you know? It's embarrassing and a disgrace to actually good bluetooth headsets, like the BeoPlay H8.


                BT pairing issues are basically non-existent if both devices support BT version >= 4.0. Latency is not a problem if both ends support aptX Low Latency (it sits around 30-ish ms with very low jitter, and it's not detectable by most users, even when gaming, even while focused on it.) Not all BT versions and not all BT equipment is created equal, though. Android is an absolute cesspool of crappy BT stacks. Avoid it like the plague. Literally anything else is better.


Also, I've had plenty of wired headsets fail me over the years. Cables break; connectors come loose from the cable; pads start to peel off; and on and on. You can argue that only shitty wired headsets break like that, but I argue that only shitty BT headsets break the way you say they do.


3. Universal plugs - While it's true that there are variations of the 3.5 mm plug, I cannot remember a single time in the past 15 years a time when I plugged a 3.5 mm headset into an apple or android phone and it failed to work. I can remember plenty
                of times when I couldn't get bluetooth to pair.


Stop living in the past. BT pairing issues are dead unless you buy products released to market 4 or more years ago. Buy modern kit and the problem is 100% GONE.


4. Unencrypted data - The second fair point. However, device manufacturers like square have started encrypting their data and this is only applicable to a tiny fraction of phone users.


Just because not all digital alternatives to 3.5mm are encrypting now, doesn't mean that staying on a protocol that will always (by design) be unencrypted is necessarily a good thing. Crypto used with the purpose of providing users greater privacy and protection is a good thing. We just have to take back control from manufacturers and media cartels trying to use crypto against us (DRM). That's a political battle, whereas analog vs. digital is purely technical.


5. Cheap DAC - This may be true, but my wired headsets are unequivocally better audio quality than any of my bluetooth headsets.


Sounds like you haven't invested in great bluetooth headphones, then. And besides, we're not talking JUST about Bluetooth. Bluetooth audio (with aptX or even AAC) should be high enough fidelity to satisfy the vast majority of consumers, and will sound as good as or better than the cheap 3.5mm analog headphones they bought for $40 at Best Buy, depending on how much they spent on their BT headphones (generally speaking, to get BT audio of the same quality as a wired headset, just add about $100 to the price tag). But for the real pros who want super high fidelity, there's Lightning, USB-C, and other RF-based (non-Bluetooth) wireless protocols that are available at varying degrees of support. Don't worry; the industry should eventually start to standardize or at least offer cheap dongles to ensure wide compatibility. It'll just take some time.


Now sure, you could say you don't want to have to pay $100 extra for your headphones. But you also get a freedom of movement and freedom from cables (which, when they bump into things, make very audible and irritating noises interfering with your music) that you don't get with wired, so it's not purely a replacement of one thing with another with no advantages.


6. Thickness - I don't need a thinner phone. I want a phone with better batter life. Hell, increase the thickness and give me some more battery life.


I agree with this. Buy a Moto Z Force when it comes out. Those things are shaping up to be very thick, and can be made even thicker by snapping an external battery onto the back. But it's still a valid argument that by removing the 3.5mm port, you're opening up some room inside the phone for more battery in the same space.


Net net--I will not upgrade to a phone that is missing a 3.5 mm headphone jack anytime soon. I am sure it will happen int he future, but not in my near future.

Since I'm completely converged on the bluetooth revolution already, the lack of a 3.5mm jack will not be a barrier at all to my next smartphone purchase. Rather, quality of the OS's bluetooth stack will factor in tremendously. Until Android fixes their broken bullshit, I basically have no choice but to buy iPhone.

Slashdot Top Deals

Quantity is no substitute for quality, but its the only one we've got.