|
|
Subscribe / Log in / New account

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 10:48 UTC (Wed) by Lennie (subscriber, #49641)
In reply to: Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs) by AndreiG
Parent article: Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Here are my first thoughts about why PHP is popular:

To know why PHP is popular is to know the alternatives at the time.

When PHP became available/started to get more popular I think this was the time of FTP, cgi-bin and Perl and C.

As you can imagine, PHP is a lot easier to work with than Perl and C with cgi-bin.

Just upload your script to the webserver with FTP and no messing around with executable bits.

No build process (like with C)

(no (Perl) module dependency conflicts with Perl modules already on the server ? Was that ever a problem ?)

PHP also uses a webserver module instead of executing a new process which makes start up time faster and you can use an opcode cache.

Start up time of PHP is also much less than for example many Java projects.

It's also easier to read PHP than Perl (or C or Java) for people just starting out.

This brought in a whole new bunch of people building dynamic websites.

As you can imagine hosting provided for PHP websites is simple for the user and cheap too.

PHP-FPM also made it much simplere for the admin. And PHP-FPM doesn't need to be a webserver module, so some people like to migrate from Apache to nginx for example.

But that came later.

Commercial offerings also existed at the time or later, things like: ColdFusion and Microsoft ASP(.NET).

But they all require extra licensing (read: money). Which isn't of much use for a companies trying to make money in a business sector with low margins (hosting websites).

Did I forget anything ?


to post comments

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 11:37 UTC (Wed) by AndreiG (guest, #90359) [Link] (36 responses)

Python was available a few years before PHP and modpython for Apache since before 2000, don't remember exactly.

Why is PHP 'easier' to learn than Perl ? What are the costs of using Perl and hiring Perl programmers, which, mind you, at that time were more numerous and with a lot of experience under their belt ?

People 'just starting out' naybe should do something else. You wouldn'd drive in a 'simple' shit car because the so called 'engineer' is just 'starting out' and anything beyond highscool algebra is too complicated.
I doubt you would follow the advice of a doctor going 'man it's hard to know all this shit, here , i read on stackexchange the green pill is for diharreea' ...

That PHP 'starts' faster than a Java server app is laughable ... For once, you have no ideea of how to implement an efficient reactive server and you stupidly spawn process after process for each request (chain) and, as an added bonus, out the door fly any notions of security. How can you possibly have any security in this language and in this operations environment ?

'simple and cheap' until you consider the consequences... Like automobiles, they satisfy your narrow-minded individual wants and you don't have to worry about where the inputs come from (oil) or where the outputs go (emissions).
Who gives a fuck anybody can hack all these piss poor sites and databases ? Or that my phone wastes battery parsing 'human readable markup' that has no reason whatsoever to be 'human readable' in the first ? Seriously, (right-click -> view page source) on your most used sites ... Who the fuck reads that ? Look at Javascript specs and all its idiocies ... Who designs a language like that ?

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 12:14 UTC (Wed) by Lennie (subscriber, #49641) [Link] (4 responses)

"Python was available a few years before PHP and modpython for Apache since before 2000, don't remember exactly."

Well, Wikipedia claims PHP3 (which I think was the time of mod_php) existed in 1998 and mod_python exists since 2000.

"Why is PHP 'easier' to learn than Perl ? What are the costs of using Perl and hiring Perl programmers, which, mind you, at that time were more numerous and with a lot of experience under their belt ?"

My guess is there was large influx of new people. The field was still young, the Perl programmers were already employed.

I think perception is also very important. Maybe that wasn't a reason, I don't know.

"People 'just starting out' naybe should do something else."

I'm just trying to state what I think are the facts that happened, not what is a good idea to do.

"That PHP 'starts' faster than a Java server app is laughable ... For once, you have no ideea of how to implement an efficient reactive server and you stupidly spawn process after process for each request (chain) and, as an added bonus, out the door fly any notions of security. How can you possibly have any security in this language and in this operations environment ?"

Hey, don't blame me, I'm not defending anyone. I'm just trying to find reasons why I think PHP became popular.

Maybe Java used more memory. Linux is pretty efficient at starting multiple processes that use the same base libraries that are already in memory.

Anyway, for Java you need a hosting provider that will give you a machine or maybe some kind of VPS and someone needs to administer that.

With PHP all you need is a website/domain with FTP access.

"Look at Javascript specs and all its idiocies ... Who designs a language like that ?"

Again, what is good for people or society or technology is not automatically what gets popular.

The whole population isn't a bunch of scientists applying the scientific method to everything in society.

Sometimes things like the Web happen, lots of people want a website. Lots of people join the field from other fields and just try stuff until it works.

It really is that simple.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 15, 2015 0:13 UTC (Sun) by Seegras (guest, #20463) [Link] (3 responses)

I was there when PHP3 hit. As sysadmin at an ISP. And no, there was no mod_python or mod_perl then, that was easily usable, and deployable for sysadmins.

At around the same time when I learned PHP, I learned Perl. Because Perl was for the commandline, and PHP for the Web, as simple as that; and doing one with the other was a major hassle.

Java did not enter the picture for a long time, because it was a CPU and memory hog; as an ISP you couldn't possibly offer Java on a shared hosting, and shared hosting was what most people used. And running Java on webservers is still a hassle, because you still need this monstrum of JDK somewhere within the webserver, and it still won't work with non-exec stacks and such. In fact, I'm pretty sure the Java runtime is related to Jabba, the Hutt. They look the same and have the same footprint. (Yes, language-wise Java is much nicer than PHP, but face it: nice syntax doesn't excuse any ugly runtime. Just look at C# and its abysmal trash of a runtime; Jabba looks quite nice compared to those Sith).

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 15, 2015 1:17 UTC (Sun) by anselm (subscriber, #2796) [Link]

The main advantage at the time (as far as many people were concerned) was that you could stick PHP right into your HTML pages. This made it easy to start with a simple static HTML site and then add PHP as required, often with the (to-be-expected) spaghetti-type result.

The other languages would generally require you to write CGI code that output the eventual HTML content, which was much more of a hassle even if it was usually safer. Perl, for example, would let you track the provenance of data items with a view to preventing people from sticking user-contributed stuff into shell commands or SQL queries without sanitising it first, which was a very useful feature.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 16, 2015 10:35 UTC (Mon) by fb (guest, #53265) [Link]

> In fact, I'm pretty sure the Java runtime is related to Jabba, the Hutt. They look the same and have the same footprint.

Thank you for this. I mean it.

(I work full time as a Java developer)

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 18, 2015 10:03 UTC (Wed) by djmutex (subscriber, #12657) [Link]

> In fact, I'm pretty sure the Java runtime is related to Jabba, the Hutt. They look the same and have the same footprint.

This made my day. Thank you :-)

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 12:34 UTC (Wed) by Zack (guest, #37335) [Link] (1 responses)

You asked a question:

>Can someone explain why is this 'language' so popular ?

Poster Lennie responded to that question with an answer. There's no need to be rude to him and hold him accountable for recounting and explaining events as he remembers them.

"Please try to be polite, respectful, and informative"

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 20:26 UTC (Wed) by AndreiG (guest, #90359) [Link]

I was just ranting about the thing, not *at* the responder.
I don't have anything with Lennie nor was I holding him accountable ... I was just posting counter arguments.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 13:26 UTC (Wed) by Corazoor (guest, #105304) [Link] (7 responses)

"Why is php 'easier' to learn than Perl?"
The main reason for that, as I believe, is the "simplicity" of the language: It hides anything you would need a formal programming education for from the programmer, mostly through heavy use of do-it-all library functions, over-committed language structures and hidden "auto-magic".
For example, there is only one structure Type: Arrays. They function as double linked liste, associative arrays and normal arrays at the same time, and come with a gazillion of library functions to sort, filter, rearrange and even shuffle Them. And for all this to work, you need to know next to nothing in terms of data structures.Try teaching any beginner how to properly use collections in Java, and you know why people learn PHP faster.

What helped php in the beginnig, though, was its incredible single minded Focus: delivering dynamic web pages via Apache, using mysql as database If needed. The whole language is geared towards that, like no other. Mysql is part of the default library, and has a simple ready-in-three-commands syntax, along with Tricks like "1"==1, so you don't even have to worry about converting between the three types php actually offers.
Get Parameters are converted to variables automagically, and echoing simply outputs to the browser...

There is lots of stuff that makes these tasks brain dead simple, so much even, that you can get working web pages with just copy and pasting stuff from the php Doku...

It really is the perfect language for anyone not knowing nearly enough to get the job done in any other language...

This also helps explain why there are so man php cms/ many cms in use are php: People who set up a cms are mostly web "designers", working for media agencies and the like. Their focus is on design and ui, custom functionality is mostly provided through existing plugins. The actual need to code is very small, but If present, even the website-building grunt force can manage php...

And why not hire "proper" programmers? Because, most won't bother with php because of its poor performance and plentiful inconsistencies. Since that is a self selecting process, you remain with an above average population of developers without formal education. That lowers the average wage (compared to other fields), which in turn will set the "wrong" incentives: "These java java/Perl guys want too much, let's use php, we can get two of those guys for the same price".

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 20:47 UTC (Wed) by Lennie (subscriber, #49641) [Link] (3 responses)

Yes, you are right.

Farnz below also mentions this and explains it very well.

I do wonder why people keep mentioning things like:

"formal programming education"

The formal programming education I had didn't teach me anything about secure programming or input validation. Guess I was to early, different times.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 12, 2015 15:25 UTC (Thu) by Corazoor (guest, #105304) [Link] (2 responses)

About the "formal education" part:
It really depends on what type of degree you get, and in which contry. I used the term mostly to make a distinction between people who know what is best practice, and why, as opposed to people who don't.
Or another way to put it: between people who learned the engineering part of programming, and those who didn't. It is the least insulting term i could come up with.

You can totally get the same degree of knowledge without any formal stuff, just by teaching yourself. But I would argue that being forced to learn about all the "Not so fun" stuff, especially project management, design patterns and how to manage bugs, changes ones approach to and thinking about programming.

Example:
Converting from string to int, automatically, just because the other type in question is an int, without proper error checking, just silently failing or trim trailing characters: that is bad, for obvious reason.

Except that it isn't obvious for anyone just starten out: You either have to learn that through countless hours of tracking Hard to find bugs, or someone has to teach you why.

And that is the dividing point I see:
Either you already know the general pitfalls of programming enough, or you don't. The former tend to dislike php, because it got even more weird stuff than c++, and the latter tend to like it, because of "look at how easy i got this working, just need to iron out the last few bugs"

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 13, 2015 0:30 UTC (Fri) by Lennie (subscriber, #49641) [Link] (1 responses)

I think a better way to look at it, especially when talking about types, is that most scripting languages are dynamically typed.

And PHP is a scripting language.

Scripting languages are useful for smaller code bases.

Luckily people are talking more and more about these so called microservices, aka smaller code bases.

Nobody likes big code bases anyway (or at least not without good architecture and clear separation of parts).

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 17, 2015 12:08 UTC (Tue) by Felix (guest, #36445) [Link]

I don't think this has too much to do with dynamic typing but much more so with strong vs. weak typing. These are orthogonal concepts. Weak dynamic typing is (IMHO) a sure way to debugging hell for any non-trivial program while I got quite far with strong dynamic typing (and a lot of automated test cases). However I grant you that static typing helps especially in big projects.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 21:04 UTC (Wed) by h2 (guest, #27965) [Link] (2 responses)

Corazoor, this is an above average, for lwn, view of php. I have to almost burst out laughing when the original comment rails against php and its insecurities. I must have been reading the wrong tech media my entire life, but C buffer overflows come to mind, which are a non stop issue. My current belief is that the lwn type rants against php are made by people who simply can't handle the fact that there is a language that allows one person, or a team, to deliver results in super fast time frames and at relatively low costs.

While I sympathize with people who can't grasp that their tool is not the only solution possible for any given situation (one thing I notice is that php critics almost never actually list what tool would perform better for END users and CLIENTS). I understand perfectly well that the high cost of development, and updates, for many other languages, make the person attached to that language a decent income, and may even create the illusion of having a 'career', but that's as far as it goes.

Personally, I have no need to debate this, since my top clients are rapidly becoming industry leaders, delivering products and services that nobody else in the world can offer. And at a tiny fraction of the budget you'd expect to have to pay. Why? Because I use php. PHP is friendly, it has a deep respect for my needs as a web developer, and basically does not care about what various geeks think who hate it, because their focus is on me and my needs. This means extremely stable feature set, many years advanced warning on deprecated features (you know, the opposite of python, that is), which means, I can note the fact that I will have to do some small modifications of the code base at some time in the next x years, but there's no hurry, because the php authors are going to respect my needs as a developer over their own geeky need to break things release to release. That alone puts PHP on a pedestal that few other languages can touch.

Since we, as a team, like facebook, do not have to pay any attention to the critics, and can deliver feature after feature at low cost, fast times, there is simply nothing anyone who must bitch about php can say that has any relevance, it's like reading the opinions of a child who whines because his toys are the wrong color. I use an incredibly solid, reliable, php cms, that again, like php itself, has a deep respect for both my needs as a developer, the the admin staff who do the updating. So again, childish rants about php etc simply have nothing to do with our workflow, but I know that will never stop these types of critics, who I assume simply have no idea of what budgets and developer friendly tools actually look like, at least that's my guess.

However, I can't spend more time commenting, have to roll out some new industry leading features, I've been slacking a bit.

When PHP 7 rolls around, our code will work. Because they respect me and my needs.

For what it's worth, I started with asp 6, or what it 5, hated it, I found the stench of corporations to permeate it at every level, including the deep contempt for the needs of the developer, which was proven at I think maybe asp 6, then asp.net, each of which basically broke existing code bases. But I just hated the logic and syntax, I thought it was ugly and painful to use. When I started to explore the options, I first checked out perl, which I found to be a huge mess, way too prone to write only errors. My view on perl has since changed, I now view it more as a language made by and for someone with a profoundly different brain than me, or most other users who wanted to generate web presences. Subsequent readings with Larry Walls interviews, particularly his profoundly flawed views of linguistics, showed me where that difference came from, on a deeper meta level, but it's important to grasp that just because a language is alien to my brain (which views perl as criminally insane), does NOT mean it is alien to all brains. Seeing this makes me sort of almost wince grownup, I hate to admit. Python I find absurd, I WANT brackets, I do not want the language forcing me to make my code hard to read. I can type fast, adding a ; or { ] does not hurt me, anyone whose typing is so slow that a few characters makes a difference in code production should find another line of work. But again, some people like that way of doing things, making everything objects, whatever. So python fails to meet my needs as a developer. It meets other people's, which is good, that's why we have different languages.

So after giving perl its chance, and finding it nuts (a view apparently shared by many amazon programmers internally), I found php, and I was like, ok, whoah!! this tool is made for me. This is almost perfect. Not perfect, no language is, but I was astounded by how great it was and is for my needs. Every time I work with other languages, and come back to php, I am always filled with relief, a sense of, oh, thank god, I don't have to deal with the stuff I can't stand, and now can get real work done, fast.

I see the same nonsense here about mysql/mariadb, and all the whining words I read about these things never explains why we NEVER have any issues with these things. Never. They work. This does not mean they are the right tool for every job, but as facebook has shown, you can go pretty damned far with these tools if you stop obsessing about geek things and focus on the actual job, which is winning in your niche. no user in the world cares what tools are used, but I can assure you, our users care deeply without knowing it that I use php, because they can now do what they could NEVER do before online. Never. So pardon me while I laugh at those critics, then get back to work.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 12, 2015 14:16 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

Nice writeup!

I can only add that from my rather mild exposure to PHP I see that the language does evolve into direction with more safety features on by default but that does not break existing code. And even when a brekage happens, very quickly an option to PHP.ini is added to fix it. That makes maintaining old code or porting it to new environment like switch from Apache to nginx+fastcgi very painless.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 16, 2015 14:01 UTC (Mon) by nix (subscriber, #2304) [Link]

My current belief is that the lwn type rants against php are made by people who simply can't handle the fact that there is a language that allows one person, or a team, to deliver results in super fast time frames and at relatively low costs.
Hardly. It's more that to anyone who's done anything in any more, uh, rigorous language (that would be all of them), PHP just looks and feels inelegant. It could so easily have been so much nicer (a less incoherently-named standard library would have been a good start).

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 18:07 UTC (Wed) by jwarnica (subscriber, #27492) [Link] (20 responses)

Well, for one: $deep['ly']['nested'][3]['structures']['work'] vs ${@$deep}['ly']->{wtf}::$%*&<>{}%&*@

In the early days, PHP was but a thin wrapper over... everything. IMAP was just imap.h. LDAP was just ldap.h. MySQL was just mysql.h. And glue. No "better" or "easier" wrapper. The thing was the thing. Not a special Perl version of the thing. Not a special Python version of the thing, it was the thing. And when the thing was compiled in and working, it worked; no end-user intervention required.

Anyway, today it is quite possible to write secure and otherwise good PHP code. It does lack an app server (and related long running processes), but what it does it does well.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:00 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (13 responses)

> Well, for one: $deep['ly']['nested'][3]['structures']['work'] vs ${@$deep}['ly']->{wtf}::$%*&<>{}%&*@

Or more realistically: $deep->{'ly'}->{'nested'}->[3]->{'structures'}->{'work'}. A bit longer, but no less readable in Perl than in PHP. And if you have that many indexing operators strung together in one expression, you really need to refactor the code anyway.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:18 UTC (Wed) by nye (subscriber, #51576) [Link] (12 responses)

>Or more realistically: $deep->{'ly'}->{'nested'}->[3]->{'structures'}->{'work'}. A bit longer, but no less readable in Perl than in PHP.

What? That's massively less readable - that syntax looks like nothing else on Earth.

I don't think I'd have even *guessed*, looking at that, that it's [the moral equivalent of] a multi-dimensional array. And what's up with "[3]"? Why is that a special snowflake?

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:25 UTC (Wed) by jwarnica (subscriber, #27492) [Link] (3 responses)

Because Perl doesn't have "associative arrays" that just work, they have hashes amd arrays, and mixing the two rather special.

I don't believe nybble41, either. Its been my experience that nesting the two inside each other requires references and crap to extract. It is almost sendmail.cf level of noise.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:39 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (1 responses)

> Because Perl doesn't have "associative arrays" that just work, they have hashes amd arrays, and mixing the two rather special.

It's not particularly absurd, if anything the contrary, to separate arrays and associative maps. They're rather different datastructures when you think about efficiency and supported operations.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:54 UTC (Wed) by jwarnica (subscriber, #27492) [Link]

I consider a language/compiler/hardware responsibility to make my life easier, not the other way around.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 22:21 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> Its been my experience that nesting the two inside each other requires references and crap to extract.

You are using references. That's what the "->" operator is for, to follow the reference. Apparently you can even leave out all but the first arrow, since they're implied. (Thanks, hummassa!)

That just leaves the first "->", needed since $deep is a reference, and the distinction between hashes and arrays. To be fair, it's not a *necessary* distinction: {3} would work perfectly well, as a hash reference rather than an array reference. I merely took the liberty of assuming that [3] was meant to refer to an element in an array, and used the more efficient data structure for that purpose.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:26 UTC (Wed) by nye (subscriber, #51576) [Link]

>I don't think I'd have even *guessed*, looking at that, that it's [the moral equivalent of] a multi-dimensional array

Thinking about this a bit more, I guess an array in Perl is a special case of a class whose indices act like member variables, and perhaps the '->' syntax is the standard way to access member variables in Perl? I'm not confident about this guess though since that seems like the sort of thing you'd see in hardcore OO languages, which Perl most definitely is not.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 20:05 UTC (Wed) by hummassa (subscriber, #307) [Link] (6 responses)

That would be

$deep->{ly}{nested}[3]{structures}{work}

in idiomatic Perl.

and the [3] is different because $deep->{ly}{nested} is a reference to an array (and not to a hash)

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 20:28 UTC (Wed) by nye (subscriber, #51576) [Link] (4 responses)

>and the [3] is different because $deep->{ly}{nested} is a reference to an array (and not to a hash)

Differentiating between arrays and hashes is reasonable, but having a different syntax for indexing them is still weird. In Python, for example, you could have deep['ly']['nested'][3]['structures']['work'] if you wanted to, even though you'd be using lists and dictionaries.

I'm not saying that this makes Perl a terrible language, and I certainly don't want to claim that PHP is a *good* one, but this does seem like a strange and unusual design decision for Perl, and a good example of why people generally consider it hard to learn and to read.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 22:17 UTC (Wed) by kleptog (subscriber, #1183) [Link] (1 responses)

> Differentiating between arrays and hashes is reasonable, but having a different syntax for indexing them is still weird. In Python, for example, you could have deep['ly']['nested'][3]['structures']['work'] if you wanted to, even though you'd be using lists and dictionaries.

FWIW, it's because in Perl operators have somewhat more influence on the expressions that you might expect from other languages. In particular: $a[3] and $a{3} mean different things. The former referring to the array @a, the latter referring to the hash %a.

Now all of this is from before Perl acquired references, because in the case of a reference there cannot be any ambiguity about what you're dereferencing, so the separate syntax isn't really helping. Before references, $a{'a'}{3} and $a{'a'}[3] could conceivably both be valid and refer to different things (though I'd shoot any programmer trying to commit such code).

It's right in line with having separate comparisons operator for strings and numbers, the operator determines how the operands are interpreted. In other languages, operators are methods on one of the operands (usually the left).

Now, you may well not like it this way, but it is consistent.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 12, 2015 13:19 UTC (Thu) by hummassa (subscriber, #307) [Link]

> though I'd shoot any programmer trying to commit such code

Not if they have a good reason to do so. One classical example is "ordered hashes" (think tabular data lines):

$a = OrderedHash->new(one => 0, two => 1, three => 2, 3 => 4, x => 5, y => 6);

$a->[3] == 3; # the fourth item on the array

$a->{3} == 4; # the item indexed by the string ("column name") "3"

Remember, the programmer does not have control over any random input tabular data column names...

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 12, 2015 18:27 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

> this does seem like a strange and unusual design decision for Perl

“Different things should look different”. Perl 5 doesn't have many design decisions to begin with, but it gets this one right.

Many other languages do not; for example PHP's +, Javascript's +, C++'s... everything. You can't rely on these things to do what they look like without auditing the operands.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 12, 2015 18:45 UTC (Thu) by jwarnica (subscriber, #27492) [Link]

I suppose my initial point was, compared to PHP which has a singke k/v storage system, perl has two, the reasons of using each are obscure.

And, perhaps not for the entire scope where perl is used, the scope of where PHP v3 was used optimizing between hashed and arrays is more effort than it is worth.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 12, 2015 1:14 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

$deep->{ly}{nested}[3]{structures}{work}

Only if $deep is a scalar containing a hashref. In the more common case of %deep being a hash, you wouldn't use the dereferencing arrow and would have $deep{ly}{nested}[3]{structures}{work}.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 20:48 UTC (Wed) by AndreiG (guest, #90359) [Link] (5 responses)

"Well, for one: $deep['ly']['nested'][3]['structures']['work'] vs ${@$deep}['ly']->{wtf}::$%*&<>{}%&*@"

The same response to something like that is to flag that commit as 'shit', re-open the issue/feature and tell the SoB to GTFO and refactor that:
if you need a million levels of indirection, your design is shit.

The same goes for 'C is \'notoriously buggy\' due to naked pointers and heap memory not de-allocated' which, most likely, is quoted more than 0x4A 0x6F 0x68 0x6E 0x20 0x33 0x3A 0x31 0x36 0x00 ... I don't want to be an asshole and brag, but I don't do that because I actually know what I am doing, I assert post and pre conditions in code, I write tests, I run my programs through valgrind etc ... Unfortunately, due to corporate greed, we hire people who 'heard' of valgrind and never actually ran it, we hire people to write network code who never opened wireshark and so on ... And if you think technology solves a fundamental human/social problem (narrow-minded short term profits irrespective of consequences) you haven't debug and/or ported (to another language, mainly C/C++ ) Java servers ... The amount of memory and thread leaks a long running Java server can have is truly astounding, irrespective of all the 'design' that went into the language to prevent all the 'shit wrong with C/C++'. Until we can fully automate programming and have a sassy businessman bark 'OK Siri, make me exponential profits' and out it spews formally-verified production code, rest assure that various linear combinations of cheap programmers and xls management will produce abject shit in any conceivable programming language.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 16, 2015 14:24 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

if you need a million levels of indirection, your design is shit.
Almost every difficult problem in computing, and almost all significant data structures, needs lots of indirection, often potentially unbounded indirection, particularly when you consider that links in trees, graphs, even lists are usually implemented via... indirection!

You just said that every compiler ever written, every database, almost every OS kernel (even microcomputer kernels from the 80s!)... all have 'shit' designs. I think perhaps you might want to rethink that.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 16, 2015 16:29 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (2 responses)

> Almost every difficult problem in computing, and almost all significant data structures, needs lots of indirection, ...

Yes, but that's in the data, not the code. The data might have a thousand levels of indirection, but in general you're only going to look at one or two elements and perhaps their immediate neighbors in any given expression—neighbors-of-neighbors in the worst case. If you find yourself directly referring to elements four or five levels deep inside your data structure, you're probably doing it wrong.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 16, 2015 16:32 UTC (Mon) by jwarnica (subscriber, #27492) [Link] (1 responses)

I don't know the standard XML libraries for Perl anymore (if I ever did).

If you know the structure, and you want something 5 layers deep in a document, the obvious way is also the wrong way?

I don't know the standard SNMP libraries (if ever). The structure is fixed; the obvious way to get a deep attribute is the wrong way?

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 16, 2015 19:14 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> If you know the structure, and you want something 5 layers deep in a document, the obvious way is also the wrong way?

If your document format specifies that there is a unique object five layers deep in the document, and you're OK with reading the entire file into memory as nested hash tables just so that you can get at that one element, then perhaps the obvious way is alright. I would normally recommend using XPath for something like this in XML; among other things, you can configure an XPath expression before reading in the file, and only retain the element(s) that match the search. I'm not sure whether Perl has something similar for SNMP.

Obviously this is merely a guideline, and not a hard rule. There are exceptions, and the sort of quick-and-dirty scripting which would lead to hard-coding the location of a specific element deep inside a document is not expected to adhere to best practices anyway.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 18, 2015 14:09 UTC (Wed) by robbe (guest, #16131) [Link]

Chill, dude! It's just a (bad) programming language, not the cause for world hunger, or fathering you a new red-headed step-brother.

In case your aren't actually raging madly at your screen while writing this comments, you may want to learn more varied expressions for things you don't like.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 17:07 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

One more thing missing from your list; if I start with a static web page, and then need to make just one bit dynamic, it's easy to get going with PHP in a typical setup; just "mv page.html page.php" and add "<%php " and "%>" pseudotags to replace bits of HTML with code.

For example, to put the current day of the week on a page is just "<%php print( date( "%l" ) ) %>". Using Perl, Java or C, I have to write a full program that outputs my static content (that I already have working in a browser, and am loathe to fiddle with because I don't really understand why my HTML works) with the date inserted.

This leads to a very low cost of entry for PHP "programmers"; first learn to write web pages, then replace placeholders with dynamic PHP code, then you're programming. In turn, this means that low skill people get comfortable with PHP before they really learn anything about programming as an engineering discipline. By the time they've built something that's "big enough" to be worth rewriting in a better language, you've got something that's sprawling and specified only by its own behaviour, and is thus a nightmare to justify replacing, especially since low-competency PHP programmers are cheap and plentiful (after all, they're people who got interested enough in web site design to write HTML, then needed something simple to just do one simple bit of server-side content).

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 19:58 UTC (Wed) by Lennie (subscriber, #49641) [Link]

Yes, very good point.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 11, 2015 20:18 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

That's about how I remember it going way back when. Also note that php was gaining traction in the late nineties to early 2000's - all kinds of stupid things were being created in tech, then, and the market was definitely getting flooded with untrained employees making nice salaries with very little skills. Those who could learn just enough limped through the bad times, and likely associate php with the days that were "good" and how things "should be". I remember riding a train to my first job in 2003, and listening to someone who had had little training, but had just lost their job making way more than I was, and they waxed nostalgic about php.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 13, 2015 6:57 UTC (Fri) by bmur (guest, #52954) [Link]

You forgot one of the biggest purposes and advantages of php. Forms!

Form handling with perl in 1998 was terrible. There were competing methods between CGI.pm (and the other procedural library that I forget). And while using CGI.pm seemed to work "better" it forced you to mix object oriented crap in with your typical of the day procedural programming style. As someone coming from C, I hated that. And regular expressions were an unneeded complexity for your typical website handler too. You get the one a-hole who writes his perl that way and you want to kill him. /2@#$\@*.$\\#<#@!/g

Switch gears to PHP. The default setting was to register globals. All of my input field names were instantly available to me in variables. I no longer had to fetch strange environment variables or worry about parsing a query string. Just a little input validation and I was on my way.

And in 98 when you are in a university setting with 500 websites on a shared unix box (most likely not even privilege separated), java was a non-starter.

Linux Ransomware Debut Fails on Predictable Encryption Key (Bitdefender Labs)

Posted Nov 18, 2015 17:35 UTC (Wed) by JanC_ (guest, #34940) [Link]

What you forgot is the conceptual predecessor of PHP; the first popular system for embedding logic into HTML pages: Server Side Includes.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds