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


Forgot your password?

Comment Yeah it's terrible, but it's Windows (Score 2) 149

> How would a properly secure and safe password system know if you new password is only slightly different than your old one?

it wouldn't. A sane system would store a salted hash of the password, so a bad guy can't download ALL of your damn password.

> If it can tell a minor change then it is not a good password setup

Right, it's a Windows password setup. *nix systems were more secure than that in the 1970s.

Comment I call those exceptions "rights" (Score 5, Insightful) 364

> Surely one can find exceptions to the rule.

I believe those exceptions are called rights, or human rights. An individual or group may do as they please, but should not infringe on anyone's rights.

If you only have the "right" to say things everyone agrees with, that's no right at all; that's just agreement.

Note that the US Constitution and others modeled on it do not by their terms create rights, they bar the government from *infringing* on the rights. It also says "the right of free speech", not "a right of free speech" - the framers recognized that human rights *already* existed and said shall not infringe rights.

Comment Great intent. You *want* your voip packets delayed (Score 1) 136

Yeah that's the intent, and that's great.

Unfotunately, legislators don't know why users WANT their VOIP packets delayed.* They don't know network jitter from doing the jitterbug. So their chance of writing a law that a) Comcast can't find giant loopholes in and b) doesn't completely fuck up proper flow management is about 0%.

* If you deliver each VOIP packet as quickly as possible, when you say "do not call me" the person on the other end might hear "not me, do call".

Comment That's the point of packet switching, of digital (Score 1) 136

Multiple flows over the same peice of copper is the entire POINT of digital communication and packet switching.

You realize of the packets and flows leaving your house don't go to the same destination. So why the *hell* would they be put into the same queues or policed the same way? Most of the work is done on flows (roughly tcp connections), not on physical network ports. So to use your example:
> concurrently play a streamed game, stream a movie, and make a VoiP call, how does that ISP

The game has probably at least two flows, control and content. The control flow is all about latency. It requires nearly no bandwidth, the gamer doesn't care about jitter, they want the lowest possible latency above all else. Reliability definitely counts - packets should be retried. So you put that flow through the low-latency, low-bandwidth path. "Lowest possible latency" implies high jitter, and that's okay.

The voip call again uses damn little bandwidth, but this time jitter is the most important thing. Reliability doesn't count -
  undeliverable packets should NOT be retried. Retrying would actually make the connection worse. For best voice quality, you want the ISP to *delay* each voip packet to make to take just as long as the last one. Otherwise you say "automobiles" and the person on the other end of the line hears "smoautobile". That's easily done by moving your game packet ahead of the voip packet, so that the voip packet doesn't arrive early.

Then you have the Netflix flow. For the Netflix flow, neither latency nor jitter matter. Reliability requirements are moderate - only retry recent packets. Only bandwidth really matters. So those go in the "high bandwidth, high latency" queue, to be delivered after your gaming and voip packets are delivered.

Comment Some (most) http isn't video streaming (Score 1) 136

> Port throttling for all sources does that just fine. And if Comcast throttle http video, they either throttle their own VoD stream too, or they're committing a crime.

I think you just answered your own question. Most http requests, most port 80 flows, aren't video on demand. Therefore treating all http as if it were video means handling most of it *wrong*, creating a worse experience for the user. The delivery of a text-based site such as Slashdot has opposite performance metrics as pre-recorded video, and live video has different needs depending on if it's one-way of video conferencing.

Also, I guess it would be illegal for an ISP to store/cache their own videos at their POP for better efficiency and performance, since they can't possibly store every video from every web site at the POP? Unfair advantage to store the frequently-accessed stuff close to the users and make it faster, right?

It's possible to work toward net neutrality as a principle. As a law, I don't see how you could possibly write a law that didn't have major unintended consequences. Network optimization is just too complex for law makers to decide how it must be done five or ten years later, using technologies that don't even exist at the time they write the law.

Comment Good question. Perhaps "not" tests, securit review (Score 1) 200

That's a good question. Perhaps, if you managed to create an environment where tests are expected and used in useful way, one could add an expectation to have an equal number of "not" tests, of tests showing what happens when input is not good, that the software does not do things when it shouldn't. That may get developers more into that frame of mind. The famous "goto fail" might have been avoided.

Mature software development includes peer review followed by QA testing. Perhaps mature software development should include security review and security testing. Just as you do peer review, have a security-focused person look over the code and run a test. Not just to catch issues, though it'll do that, but so the feedback helps developers think about those types of issues in the future.

Comment More specifically (Score -1, Redundant) 136

There is some truth to that. The thing is, while the *concept* of net neutrality is certainly good, and the *intent* is right, modern networks are extremely complex. Therefore writing a network neutrality LAW that is effective but doesn't seriously mess with the very useful management of complex networks is very difficult.

Cisco knows, because it's their entire business to know, that some flows need low jitter, and bandwidth isn't an issue (voip for example, 64Kbps bandwidth is plenty, any significant jitter is unacceptable). Other flows require high bandwidth, and don't care about jitter or latency (Netflix for example). Other flows need low latency, regardless of jitter (gaming for example). ISPs pay Cisco billions to deliver the type of flow you'll want for each aapplication. To the extent that new laws restrict how ISPs can manage flows, the user experience gets worse for everybody.

I don't know a single CCNP or CCIE (network expert) who supports any proposed network neutrality *law*. Most support the *concept*, but it's darn near impossible to write a law that does what we'd want it to do, without criminalizing proper network optimizations.

As an example, one early draft of network neutrality legislation actually made it illegal to refuse to accept spam. Later versions are slightly more sophisticated, but a networking expert certification requires roughly 12,000 pages of reading - ISP networks are really complex. Legislating technical details of routing and queuing is quite unlikely to work.

Comment Want the low jitter path or bandwidth or latency? (Score 1) 136

Cisco knows, because it's their entire business to know, that some flows need low jitter, and bandwidth isn't an issue (voip for example, 64Kbps bandwidth is plenty, any significant jitter is unacceptable). Other flows require high bandwidth, and don't care about jitter or latency (Netflix for example). Other flows need low latency, regardless of jitter (gaming for example). ISPs pay Cisco billions to deliver the type of flow you'll want for each application.

You can do almost nothing about any of those metrics on your local network. Its up to the ISP to route, queue, drop, and police packets in order to provide you the right flow parameters for each application.

Comment Lack of negative testing - extremely common (Score 5, Interesting) 200

This much more common mistake than one might think. A *lot* of applications will accept an empty password. It's one of the more common of the 90,000 or so vulnerabilities that we test for.

Programmers get so focused on making things work, 95% of the testing they do is geared toward that, toward doing whatever is supposed be used for, given correct input. They forget to test the negative - what does it do with incorrect input? If a program retrieves a web page, what if it's empty? What does a searching or sorting program do when asked to aort or search an empty list, or a list of just one item? That stuff doesn't get tested much.

Comment TFS only said Windows six times (Score 3, Insightful) 236

It was easy to miss if you haven't heard of ReactOS any time in the last 19 years, so I don't blame you for missing it, but ReactOS is an alternate implementation of WINDOWS. The summary only mentioned that six times, so it was easy to overlook.

Of you've used FreeDOS (or more properly, if you were AWARE that you were using FreeDOS), it's like that. ReactOS has nothing whatsoever to do with Linux. The only relationship I can come up with there is that it's for people who don't want to use Linux, or can't, and don't want to use Microsoft Windows (or can't). It's non-Microsoft Windows.

Comment That's the problem with systemd, not just an init (Score 2) 122

> Rather than forking ALL OF DEBIAN so you can keep sysvinit, why not fork systemd to use only the init?

That's the entire problem with systemd - it forgot it was supposed to be an init. Systemd has consumed more and more of the OS, and in ways that require *applications* to have dependencies on systemd.

If it were just a bad init system, people would complain, but most would deal with it. Some would use a different init. Systemd doesn't work that way. Like a particularly nasty rootkit, you have to replace half the system to get rid of systemd.

Comment Next they'll start asking people's names (Score 1, Troll) 76

> very invasive (phone number's often as good as a street address)

Yeah I bet the next step is when Syrians and Iranians try to fly into the US, the US government will start asking for their name and address! It's just like Hitler!

Damn we *must* do something about our schools. We spend twice as much on schools as other countries, yet we're raising a generation of idiots.

Comment UAE has many different types of desalination plant (Score 1) 350

Yes, they have many desalination plants, using several different technologies, and invest heavily in researching new desalination technology.

Desalination takes a lot of energy aka money. It should cost maybe 50% or 70% to tow the ice than to desalinate seawater.

Comment I might like it. They already know what we buy (Score 1) 106

The stores' computers ALREADY have the data on which items were purchased with which debit/credit card. They *already know* what we buy.

I know that at some stores, if you don't have your receipt handy for a return, they can look up the purchase by swiping your credit card. Which proves that they do store the data, they are *already* saving the data about who buys what. They already know that we buy two gallons of milk from them every week.

They know that we buy product X every 4-8 weeks. The only additional information they'd get is whether I need to restock this week or next. Given that fact, it might be useful if, when I walk into Walmart, their app popped a notification saying "don't forget milk."


Slashdot Top Deals

Genius is ten percent inspiration and fifty percent capital gains.