Follow Slashdot stories on Twitter


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Summary is wrong, as usual (Score 1) 72

by ThePhilips (#49326545) Attached to: World's Largest Asteroid Impacts Found In Central Australia

Long time ago I have read about. The crater was known about for many years now. But for it to be registered officially as an impact crater, they had to find the impact center and let other scientists review the work. When I read about it, they found the suspected impact center and were preparing for drilling. From the TFA, it seems that they have finally dug up the evidence, but I see no mention of it being officially confirmed.

Crater wasn't found. They have just dug up and analyzed the first samples. No mention of it being "confirmed". Though Wikipedia still lists it as unconfirmed.

For more info see: (excluding the "unconfirmed structures") List of impact craters on Earth, Earth Impact DB , (uncluding the unconfirmed ones) impact craters in Australia.

Comment: Re:Plug-ins were scapegoats but now we can't go ba (Score 1) 237

The problem is not the size per se.

The problem is that every time you open a slashdot page, 1.1MB of (minified) JS code has to be parsed by the browser. Every damn Time.

No managed language (especially of the "everything is an object" garbage collected ones) are capable of parsing that in a reasonable time below 1s.

In dial-up times everything was slow because the "last mile" was slow. These days it is slow, because "web designers" effectively became a synonym to "mentally retarded hipsters".

Look at the slashdot. It would take probably 50-100 lines of PHP (or Perl/CGI) to create the main page and comments page(*) each, which would (A) take fraction of RAM/CPU resources and (B) load effectively at the speed the DB needs to fetch the data from disk (if they are not cached) (because disk is the slowest link in all that). Another smallish CGI for the login/logout. Throw in 50-100 lines of the CSS for the visual style. And probably 50 or so lines of the JS for the comment form. And another CGI for posting the comment in DB. And that's about 99% of the Slashdot I ever use. Now compare with the unmanageable clusterfuck we have. Or worse: compare to the beta.

(*) The tree organization of the comment might take bit more code.

Comment: Re:Plug-ins were scapegoats but now we can't go ba (Score 1) 237

I see where you coming from and actually I do not disagree with you.

Basically we just have different priorities.

Firefox has been hanging more for us in recent months than it has for years. This appears to be due to a couple of popular add-ons we use rather than Firefox itself, but the fact that a failing add-on can take out the entire Firefox process is itself a damning indictment of Firefox's basic process isolation and security model, which is still fundamentally flawed many years after every other major browser dealt with this issue.

Add-ons have literally unlimited access to the FireFox innards. That's by design. That's why FireFox add-ons are actually useful, compared for example to their castrated and harmless Chrome counterparts.

If you want to blame something, blame FireFox' rolling releases strategy. It's basically a cat and mouse game: browser changes, add-on authors has to change the add-ons, by the time they are finished, browser changes again.

That's a fair example, though my immediate question is why these plug-ins ever had direct access to things like keyboard input in the first place, given the obvious stability and security issues you mention.

Because plug-in requires at least a GUI widget. And a GUI widget has access to the event queue. On Mac and Linux that can be coded around - but on Windows you are stuck.

We've been running Java applets embedded within web pages for around two decades, and it's kind of absurd that in all that time and despite the rise and fall of other plug-ins like Flash and Silverlight along the way, browsers and operating systems haven't come up with a better model.

There is no better model currently which satisfies the performance and integration requirements. Plug-ins are black box binary libraries with hooks, allowing browsers to hook the plug-in into the browser. (That's why the browsers do the land grab they do, integrating everything possible or not inside them: they try to make out of the black boxes the white boxes. The obvious issue that leads to is the overstretching of the limited development resources. A team can handle only so much.)

Browsers already do the only effective thing they could do: run plug-ins in their own isolated processes.


The only major browser that does not have major crash/hang bugs with any project I work on today is actually IE, which gets a bad rap for historical reasons but objectively has been vastly better in quality than Firefox, Chrome or Safari for several years now according to our bug trackers.

The greater irony (or more like "WTF" moment) is that some Google services actually work better in IE than in Chrome.

Rolling releases my ass. Everybody knows how IE works/doesn't work - stagnation is another word for stability. - nobody can be ever sure about the Chrome. Apparently even Google. Because its version number changes sometimes every day. (Well, it is easy to spot Chrome installing the updates: instead of the usual ~15s to fully start, it takes more than 30s.)

Comment: Re:Plug-ins were scapegoats but now we can't go ba (Score 4, Informative) 237

Slashdot is pretty "lightweight" and yet:

The size of JS embedded on this page I'm replying from is 33K in about 890 lines of code.

Externally loaded libraries are (most minimified):

Total size: 1147446 bytes, aka 1.1MB.

You are welcome.

Comment: Re:Plug-ins were scapegoats but now we can't go ba (Score 1) 237

So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second?

It's not as if I have a handy JS engine implemented in every safer language to benchmark, but there are plenty of them out there that compile down to speeds close enough to C that the difference is mostly academic.

Benchmarks in studio.

All comparisons I have seen so far were about executing JS code. But performance of data parsing is still largely sucks in all managed languages. And the modern web is overloaded by the ridiculous amount of the code. Parsing the JS nowadays takes more time than executing it. Because execution can be optimized to the bare necessary minimum, while one still has to parse the whole thing to know what to execute.

The trouble is, every one of them is currently in the range of "obscure" to "extremely obscure" and lacks the surrounding ecosystem to be a viable alternative today.

This is a highly specific task, really. And browsers have already literally excluded themselves from the rest of the software ecosystem. They come with their own network libraries, DNS libraries, security libraries, video/audio decoding libraries, GUI libraries and so on. Yes, on Linux, they can be configured to use the system libraries, but that wasn't the default behavior for many years now - distro devels have to activate that manually, and potentially deal with the incompatibility quirks.

Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.

But going back, say, a decade, all of the major browsers integrated with all of the major plug-ins just fine.

Nope. Your memory is playing tricks with you.

Browser crashes due to plug-in bugs were the most often cause for browser crashes. And I have followed not one bugzilla ticket (in the times when "bugzilla" still was a term specific to Mozilla's Bugzilla) which involved lots of fingerpointing between Mozilla and Java/Flash developers.

The problems have been caused by deliberate decisions to drop support for various long-standing mechanism and/or an obvious lack of concern for even testing basic integration works. I don't for a moment believe that this was all done purely for technical reasons.

Here is a simple technical reason: keyboard input. There is no established interface, and generally the interface is highly OS specific, for a plug-in to pass an unhandled widget event (for example keyboard input) to the browser. That's why in some browsers still, if you open a tab with flash video, click inside the video and press ^W to close the tab, nothing happens. Because plug-in are the ^W and browser never seen it. Worst part: that is also a security concern: one can not let plug-ins simulate user's keyboard input, since that makes silent web-based keyloggers trivial to implement.

Comment: Re:Plug-ins were scapegoats but now we can't go ba (Score 5, Insightful) 237

[...] they are also trying to write secure software in unsuitable programming languages like C++.

Right. So tell me, what "suitable" language would allow the browser to parse 200-500K of minified JS code in under 0.5 second? (200K == JQuery + few JQ plug-ins, 500K - JQuery + lots of JQ plug-ins.) Anyway, browsers already do resort to optimizations in assembler, because even C++ is not fast enough for what the web has become.

So now we can't use tried and tested plug-in technologies to actually make stuff, and we all have to use HTML5+JS instead, even though in some areas they are still far inferior to what we had before with Flash or Silverlight or Java applets.

Integration with 3rd parties is a bitch. That was and remains the main reason why plug-ins suck.

Portability is another big reason. Windows, iOS and Android do things in starkly different ways, making portable plug-ins even harder.

The problem are not plug-ins per se. The problem is that Google steers development of the Web toward its own goal which is to make the OSs obsolete. The short-sighted strategy resulted in overbloated browsers, with all the consequences for the security. Worse, they keep "optimizing" the browsers instead of e.g. integrating the JQuery/etc right into the browser to avoid repeating the loading of the same every time user clicks a link.

Comment: Re:For all of Uber's Faults (Score 2) 366

by ThePhilips (#49289355) Attached to: Uber Shut Down In Multiple Countries Following Raids

Just know that Germany is extremely protectionist on many fronts.

Recent discussions on GEZ or GEMA do not make me feel that there are lots of fans of them. The problem is that nobody can suggest a workable alternative.

But on-topic, Uber has to simply comply with the local law. The case in Frankfurt was heard in local court and its decision is only valid in state of Hessen. But the premise of the case was so simple that it didn't take long for judge to reach the verdict: Uber operates a taxi service, but doesn't comply with the relevant laws.

Uber's case has nothing to do with the stupidity the GEZ and the GEMA grew to be.

You can't even buy common off-the-shelf drugs that would cost $20 for a couple hundred in the US, but rather have to pay a pharmacy like a buck a piece for there.

I have absolutely no idea what you are talking about.

Just go to a doctor, complain, ask for a drug, and in all likelyhood they'll write you a prescription you want. (Just say the pill had helped you in the past. In most cases that is enough.)

And any (as in *any*) drug prescribed by a doctor costs 5 Euro, and the rest is payed by the health insurance.

Unless, of course, you try to abuse the system. But then it would the health insurance on your neck, trying to reimburse the costs. And they typically do not care, as long as you simply pay the bill for the drug. So I'm not really sure what's your problem.

Comment: Missing option (Score 1) 307

Graphic card's fans.

If it were possible to pick two, those two would have been the choices.

P.S. But the nastiest problems I ever had were once cause by PSU (caused memory problems). Spot #2 goes to a motherboard with cracked memory bus lane: system was working when MB was in horizontal position and failing in vertical. Took ~5 people to figure that out. But that took only few hours compared to the PSU trouble which took couple of weeks, to replace systematically every component to narrow down the problem.

Comment: Re:what's the point (Score 1) 94

by ThePhilips (#49271311) Attached to: Top-Secret US Replica of Iran Nuclear Sites Key To Weapons Deal

But what I wouldn't do is go somewhere to blow up random civilians.

And that is why I think (historically) the democracy hasn't yet matured. Or probably even doesn't make any sense.

The big question about democracy is: who is responsible? those who were voted in the office? or those who voted them in?

The current "balance" is that nobody is responsible for anything. On the scale of the world, that is volatile and simply unsustainable.

And I certainly wouldn't pretend that God wanted me to do it.

"God" or "freedom" - there is really no difference between these imaginary entities. They are secondary anyway.

First people kill. Only then they look for a justification of their actions. Whatever makes people feel better about themselves or bear the guilt.

And let's be clear *skip*

That's a pretty senseless rant. Replace "Iran" with "Israel" and imaginary actions with real actions - and you are actually onto something.

And if there is going to be a war, I want the US to win it, because in the end, we'll at least try to do the right thing, and failing that, we'll leave.

Just like you did in Iraq. Very peaceful country. What they have? 10K civilian casualties per year? Very peaceful. Very freedom-y. And the best part: they owe you load of money for "freeing" them.

Comment: Re:So much for LTS releases (Score 1) 338

by ThePhilips (#49211775) Attached to: Google Chrome Requires TSYNC Support Under Linux

Check the Ubuntu kernel updates again.

There were two kernel updates for 14.04 in a row recently so I checked things out. The only difference in the second update was that some network-related patch was removed since it was causing problems. There is a chance that your problem was fixed.

Comment: Re:I'm not sure what the article is about (Score 1) 261

by ThePhilips (#49125473) Attached to: The Case Against E-readers -- Why Digital Natives Prefer Reading On Paper

I only skimmed the summary.

And it is good so, because it has nothing to do with "e-readers". Every single of the linked articles deals with the normal tablets, PCs and smartphones - e-readers are not even mentioned.

As somebody who switched to the Kindle several years ago, I had hard time believing the headline. As it turned out, the headline is full of bullshit and is not related to the content of the article.

The beer-cooled computer does not harm the ozone layer. -- John M. Ford, a.k.a. Dr. Mike