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


Forgot your password?

Comment For some reason this reminds me (Score 1) 468

a joke about a Soviet news report:

(copy&paste) "A friendly communist agricultural tractor was intercepted by enemy group of seven Chinese battle tanks, while performing its everyday works on wheat fields along Soviet-Chinese border. Tractor has returned fire and after destroying all tanks it flew back to its base."

Comment Mozilla should care a LOT more about privacy (Score 1) 125

Performance, portability, openness aside (there are many contenders here today), the main reason I use Firefox is because guys at Mozilla Foundation *seem* to care about my privacy *a bit* more than others. Or rather, they haven't designed Firefox from ground up to suck as much information about me as they can get away with.

Unfortunately, even though the potential is clearly here, Firefox does very little to actively protect my privacy. All the killer privacy features are pushed out to extensions. In 2015 there is no excuse for not shipping Adblock as a built-in component. I would really love to see filters being maintained and distributed within Mozilla - if nothing else, that would be a great way to engage the community.

Another extension which is "a must" for me, and badly suffers from integration issues, is Multifox. It lets me open several windows, each presenting a different identity to web servers. I believe it was designed to allow multiple simultaneous logins to services like Gmail but it has a nice side effect of being the most effective way of blocking trackers. They can get all the information about Youtube videos "I" watch, or what online banking "I" use, but they cannot easily connect these patches of information into a single consistent picture of "me". I bet such function will never make its way into Chrome or Safari, yet Mozilla chose to ignore the potential killer feature again.

So, why many of such essential privacy features are still not part of Firefox? I used to think it was because of Google founding but times have changed and Mozilla still does very little on that front (no, DNT really doesn't count).

Submission + - Default Xfce wallpaper cases physical damage to LCD monitors

An anonymous reader writes: SanjaytheToilet filed a critical bug report (https://bugzilla.xfce.org/show_bug.cgi?id=12117) against Xfdesktop, one of core Xfce (http://www.xfce.org) components. As graphically demonstrated in the report, the default wallpaper indirectly causes physical damage to the user's LCD monitor(*). Xfce developers seek advice from Slashdot community on how to properly handle such issue. And, yes, we treat it (somewhat) seriously.

*) We assume this bug also affects other desktop environments using similar wallpapers. A temporary workaround is to switch to a CRT monitor.

Comment Re:2 Words (Score 1) 810

Good point, pure EVs are currently unsuitable for apartment dwellers, or people commuting 100km to work. But, no one is talking about a market dominance. If only 5% of people decided to buy an EV that would already be a major success. Infrastructure and technology would follow and several years down the line we would find there are more of us falling into the "can buy" category.

The biggest problem at the moment is the price - ultimately it will have to go down because there is no reason why a mass produced EV has to be more expensive than an ICE. But for now, Tesla is doing it right, by targeting the premium market and selling a car that appeals to early adopters.

Comment Re:For non-Americans (Score 1) 174

The sources say it is 500km/h. That's the problem with unit conversion - on one hand there is always accuracy loss (500km/h310mph), on another it paints a false picture. "310" (two significant digits) sounds like a maximum speed they have managed to achieve, "500" tells you they have reached a milestone or a design target. Bloomberg did it right - they provided original numbers with translations in parentheses for casual readers. Slashdot, which supposedly serves geeks and technical audience, hasn't been any better than a popular magazine.

Comment Re:Hyper TEXT (Score 1) 566

Does supply of precious metals vary? Sure. Can it be ramped up 1000x, 1000000x or 1000000000x as easily as typing this line? Hell no!

Guys, you are of course right that there is no black and white choice here. Gold is only an approximation of a commodity with a stable price and therefore it can be used as money. Binary formats can be specified as clearly as text ones. But then, the *scale* is what sometimes makes all the difference.

Comment Re:Hyper TEXT (Score 1) 566

The first has to remain compatible with millions of LOCs like:
s.write('GET / HTTP/1.0\n\n')
which in practice prevents anyone (good willed or not) from extending the format in an incompatible way.

The other one can be arbitrarily extended by upgrading libhttp.2.so and a handful of other most commonly used implementations.

The second option is tempting if you want more control over the specification. Which raises the question: why would anyone need or want to change HTTP2 once it is deployed? Or, will IETF turn evil once they get power in their hands?

Comment Re:Hyper TEXT (Score 2) 566

I agree with you that it is technically possible to define a text format that is more obfuscated than the binary one. Yet, it almost never happens.

Text formats are designed to be open and humanly readable (that's why they are *text* formats). This encourages writing multiple implementations of parsers and formatters, often partial or ad-hoc ones (perl one-liners etc). At some point the critical mass is reached and no one, not even the original author, can fiddle with the format, effectively preventing any embrace, extend, extinguish efforts.

Binary generally do not generally reach this level of standardization. On purpose - people want to control the format and the handful of its implementations. There are some exceptions, like TCP or IPv4, (which BTW proves your point that a binary format *can* be open) but they are considered a failure in terms of extensibility specifically because they escaped the control.

Finally, in case of HTTP there is exactly *zero* benefit from switching to binary representation. Bandwidth utilization is negligible and has never been smaller, parsing has to be robust to errors for security reasons so you cannot save much processing power either. These things were important in early 1990s (yet we chose to communicate in plain text anyway) but not now. The only place where HTTP could be improved is latency as it scales slower than network bandwidth but that has nothing to do with the format.

Comment Re:Hyper TEXT (Score 1) 566

"Peg rates", "certificates"? Pegging fiat currencies to precious metals is just like assuring that binary protocols will always be 1:1 convertible into equivalent text representations. Over the time, the ratio becomes 1:2, 1:5,..., 1:1000. It will, because there are no technical obstacles preventing that, and organizational ones are never effective (drugs, child porn and terrorism will justify about anything).

And no, 1g of gold will always be worth 1g of gold. It my become diluted in new coins, or replaced with paper certificates. But your existing savings are as safe as you are.

Comment Re:Hyper TEXT (Score 0) 566

Text protocols are a guarantee of openness, just like precious metals are a guarantee of sound money. In theory, there is nothing wrong with binary protocols or fiat currencies, they may even be better performing or more convenient. But as we all know by now, promises "we will keep this protocol open" or "we will never print money out of thin air" are *always* broken.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (7) Well, it's an excellent idea, but it would make the compilers too hard to write.