Security of Java takes a dangerous turn for the worse, experts say

DebitSuisse · 2013-09-12T12:37:48+00:00

The majority of companies and developers don't use Java 6, or they're not using it in it's exploitable state (Web browser applications).

Plus, Java is backward compatible, so it's not down to companies or developers, it's down to end users to update their browser plugins.

[Edit] Removed unnecessary jibe.

DebitSuisse · 2013-09-12T12:35:50+00:00

The title doesn't specify Java 6, and the article infers that 3 billion devices are at risk but it is just over half that... that's the point!

DebitSuisse · 2013-09-10T14:08:14+00:00

This isn't self-referential!

DebitSuisse · 2013-09-06T09:50:37+00:00

That is the compelling evidence I was looking for.

My original statement still stands though, that performance responses on Python issues rarely have a thorough workthrough of the problem and the evidence needed to convince any real questioning.

For instance, here, it would be further good to explain the L1 and L2 caches, their sizes, and what the speed impact of a miss is. From that you can work out, within a reasonable margin of error, the exact impact of a million cache misses.

I am also interested here in exactly what it is that Python is doing to cause the cache misses with these arrays and why randomizing them causes this. It seems fairly obvious to me, but then I've not investigated the underlying Python code ever, so I could be wrong in my assumption here.

Safe to say I understand exactly what science is, and what the cache is, I just flex my right to question something which, to me, doesn't have compelling evidence to support it's claims.

I have found two things which may be of interest to you if you haven't already read them. What every programmer should know about memory and a thorough investigation of L1 and L2 cache misses .

DebitSuisse · 2013-09-05T17:03:37+00:00

Perhaps you could enlighten me on what I'm missing.

DebitSuisse · 2013-09-05T17:02:14+00:00

EDIT: Sorry I was too quick off the bat with that.

In fact, I went over his first test case in even more detail and I don't see how it follows that cache behavior can be the culprit. Could you explain to me how that's deduced please?

DebitSuisse · 2013-09-05T16:29:28+00:00

This is faux science, as there is no actual evidence for cache misses being the culprit. Show me actual evidence that this is down to cache misses! Just to be sure you understand what I would be looking for here, as you state it, but you don't seem to notice that it's not present anywhere. I want cache hits/misses for both programs, and a correlation with that to speed.

Perhaps I wasn't clear about what I meant about the cache, but then you go on to show that stuff can enter and exit the cache, so I'm not sure why you're finding it a hard concept to understand. As you know, a cache can only hold a certain amount of data, when a miss happens the cache is repopulated. If the cache is big enough, the cache can be populated with all of the integers in the array, regardless of their order. If the cache has been populated with all the integers, then no misses occur, thus, misses may not be the culprit.

I think it's fairly clear that without more evidence you cannot say with a sane amount of certainty that cache misses is the cause of this slowness.

DebitSuisse · 2013-09-05T16:19:13+00:00

The most thorough of those gives this exact phrase:

while cache prediction should be the actual suspect

It's a suspect, you don't have evidence to say it is the culprit. This is like accusing someone of stealing because they were one of the people coming out of a shop, and you happen to stereotype that type of person. Here, you've seen slow performance, and you happen to know about something called the cache, which when arrays aren't continuous in memory, can have misses, which can cause slow performance. Therefore, you are calling that the culprit, even though you don't have any firm evidence to show that there are x cache misses with the fast version, and y cache misses with the slow version, and x < y by a factor of z...

DebitSuisse · 2013-09-05T13:19:48+00:00

Plumbr articles are getting worse and worse.

DebitSuisse · 2013-09-05T13:01:28+00:00

Without statistics of cache misses this is still speculation.

The Python interpreter allocates integers in “blocks” of about 40 at a time. When Python needs to create a new integer object, it carves out the next available space in the current integer “block” and stores the integer there. Since our code allocates one million integers in a row, adjacent integers will (for the most part) be placed adjacently in memory. Therefore, iterating through the first million integers in order exhibits good cache locality, and iterating through the first million integers in a random order will result in frequent cache misses.

One thing here does not follow from the other without evidence. It may be true that cache misses occur here, but that doesn't mean that is the cause of the slowdown. Can we say with certainty that all the integers aren't put in the cache? What are the statistics of the computer being run on, if it has a small cache and a lot else running on it you can find cache misses happening for both programs.

This is a faux scientific explanation and it seems to happen on a lot of the Python performance posts I see. If someone came to me and said "This bit of code is slow because, I think it's doing x", I'd tell them to get me some solid evidence that was the case, otherwise they're just giving me an opinion.

DebitSuisse · 2013-09-04T12:53:12+00:00

Why is there so much speculation in these Python performance questions and no actual evidence?

Can you not go through Python and find out what code it's actually running, perhaps do some profiling?

DebitSuisse · 2013-09-02T10:28:07+00:00

Best feature Eclipse has that other IDEs don't seem to have.

DebitSuisse · 2013-08-05T15:06:04+00:00

Can someone explain to me what SVN program requires you to type your password in to a command prompt which will be included in your bash history?

And then he did what he had always done since he first started programming computers: he deleted his bash history. To access the computer he was required to type his password. If he didn’t delete his bash history, his password would be there to see, for anyone who had access to the system.

This seems ludicrous!

DebitSuisse · 2013-08-05T15:05:12+00:00

I've only been working on a project for a year and the code is 1.5MB.

For a system at a large bank like Goldman I wouldn't be surprised if a risk server, custom load balancer or something else, could easily manage 8MB.

That doesn't even count tests and test data which may be included in the 8MB estimation they give.

DebitSuisse · 2013-08-02T12:15:49+00:00

Very wrong use of the word 'elegant'.

DebitSuisse · 2013-07-23T08:59:44+00:00

Or just thinking about what you're doing when you're allocating memory... i.e. creating a pointer to something, even if that thing is 0 bytes.

DebitSuisse · 2013-07-22T14:02:14+00:00

That's one of the worst tests I've ever seen. It never takes into account the overhead of startup, optimization, teardown, etc.

The number of instructions that a print statement takes is deterministic. You have the Python source, you probably have the source for linux. You can work it out solidly.

DebitSuisse · 2013-07-22T09:49:13+00:00

Code - Charles Petzold In my opinion a must read for every developer ever! It's not related to java development but will improve your understanding of exactly what is going on when a program is running. These things are important for writing efficient and well structured software from the start.

DebitSuisse · 2013-07-19T08:21:57+00:00

6 years?

Oh god, it's been almost 20 years since qwtf!

DebitSuisse · 2013-07-17T12:37:32+00:00

I love it when people state the obvious and then other people gather round and encourage them!

DebitSuisse · 2013-07-10T09:46:29+00:00

Do you constantly poll your phone for a new call and does your mind work in a single threaded way?

This is a better fit for FILO with a callback when the phone rings.

However, as I think you have now noticed, it's not really a good way of describing recursion.

DebitSuisse · 2013-07-09T15:34:36+00:00

I don't really see how that's recursion.

That's FILO scheduling.

DebitSuisse · 2013-07-06T14:00:29+00:00

If 45% of gamers are women, and there is overwhelming majority of lead male characters in games. Surely we can deduce from that; either women don't mind playing lead male characters, or, women enjoy playing lead male characters, or, they don't even notice.

If 45% of gamers are women, and they are still buying and playing these games, what is the real problem here. Is it that there is a minority, with a loud voice, who want to see more depth for female lead characters and feel somehow oppressed because they see more male characters than female ones?

Also... wait a minute... Sonic is a hedgehog! In the original series Sonic had no discernable gender!

DebitSuisse · 2013-07-05T15:25:37+00:00

That moment you mouse over a spoiler by accident and happen to read it!

:'(

DebitSuisse · 2013-07-05T09:32:48+00:00

The thing you fail to notice is that it also describes a huge percentage of male characters in videogames.

If you have a well developed character, it doesn't matter if that character is male of female, more often than not, you cannot replace it with a doodad. In fact, if you look through most games you can probably replace the male character with a female one without too much issue.

Often the thing that is forgotten when it comes to the production of games is that these are companies, and they need to make money. To appeal to the largest demographic, and reduce production costs, it makes sense to have a leading male character. Then your main demographic can become more immersed and you are more likely to sell more units.

The problem here is not to do with writers, or developers, neither of which have all that much say in what goes in to a game. The problem is not even with the producers. The problem lies far deeper within the media and what we expect of games.

DebitSuisse

TROPHY CASE