Hacker Newsnew | past | comments | ask | show | jobs | submit | hoppla's commentslogin

«A Booking.com market manager in south-east Asia admitted at a recent industry event that payment delays were caused by the installation of a new payment system. Staff salaries were also affected, she said, explaining it as a risk they had to take.»

It seems like there is a misunderstanding of who is on the taking and receiving end of risks


Sad to see the top comments in the thread not even bothering to discuss the technical reasons and legal implications behind this .. and instead everyone wants to just discuss unrelated anecdotes about their personal travels.

The story here is about how booking.com is screwing over hotels and hostels, not guests. Someone should create a different thread for that, because apparently people have a very strong need to tell their tangentially related stories.


You've seen how discussions work in real life right? There's no requirement to stick to some topic at hand, it's a free-flowing dialogue. That's what you're seeing happen in this discussion board too.


Wage and expense theft by companies is not just anecdata.


Real companies have competent adults build and test this type of thing so they don’t stiff their vendors or miss payroll. It’s not an area where you should let techbros move fast and break things.


It’s booking.com, they are notorious for not being competent adults. Just check out this article about their working conditions [1] (you might want to google translate it you happen to not speak Dutch).

1 - https://www.computable.nl/artikel/nieuws/development/6777910... (


> the developers complain about Perl programming language, which forms the basis of the online platform and to which, according to them, is held far too rigidly. Criticism of Perl may even result in dismissal, according to an anonymous source.

If this machine translation is correct and the statement true, then this is borderline hilarious. I know that some companies keep their languages dearly, but that's taking it to the next level.


> Criticism of Perl may even result in dismissal, according to an anonymous source

That statement is absurd. You can't dismiss an employee in the Netherlands for such a stupid reason. I used to work in their HQ as a developer, and complaining about Perl was always water cooler talk.


After duckduckgo, this is the second time in a few days where I hear about some relatively big company using Perl for their backend.


Perl used to be a really popular language for cgi scripts. So much easier than writing them in C! I can't describe how amazing PHP was at the time of its inception. While I have trouble picturing somebody starting a big website in perl today, it's certainly plausible that momentum prevents a switch pretty much indefinitely.


Any hosting provider running cPanel is running on Perl


some of the older stuff at OVH is also in Perl.

All the newer stuff is in Go or Python (thank God), but there's an acrophyal story about someone asking Octave Klaba, the founder of OVH about any regrets he had, and he allegedly responded "maybe using Perl was a bad idea".


Heard a story about a developer auditing the code for missiles. He quickly pointed out that there was memory leaks everywhere … turns out that it was intentional, as the missile had its own garbage collection at the end of flight.

Any OOM issues was handled by doubling the expected memory usage during the missiles flight.


"Out of missile memory, switching to guns"


Hard to believe TBH.




I am not sure how it was possible, but I was able to play mp3s on my 386sx 16mhz (with turbo button) using the mpg123 player. OS was Slackware Linux.


Sure that was a regular bitrate stereo mp3? I remember struggling a lot with my 486DX/100, waiting for better assembly optimization to happen on Linux (to keep up with a DOS mp3 player that handled it better).


I no longer have the details, but the music was just some mp3 files I copied from friends. Buffering may have played a role as I had at some point, I had maxed out the specs memory-wise.


A bartender told me that he had connected the fuel pump to a switch hidden. He lived in a rough neighborhood and his car was an easy target for thieves. More than once he had found his car a hundred or so meters down the road.


Adam Carolla likes to talk about how he did this with his truck way back in the day. You could drive as far as whatever gas was in the carburetor and fuel line.

He also painted his radio brown like the interior of the truck. It was so ugly nobody ever stole the one thing that had any value in the truck.


<quote>When you spot one, put it in a Ziploc bag—while protecting your hand with a napkin or gloves—and add vinegar or salt.</quote>

Why the need for protection? Does it bite?


This is discussed in detail in the actual article.


It excretes the same neurotoxin as puffer fish


Cool idea, but I would have implemented this as a PAM-script rather than as a user profile script.


Looked at a 6 byte hash today. Modifying the hash or the data attached to it made the API respond with an error saying untrusted input. The data is an encrypted blob and the hash protects it from being tampered with.

My guess is that it’s a truncated md5(secret + data) or hmac. Either way, with a sufficient long a secret, I won’t be able to guess it (offline), and because of the truncation, length extensions also out of the question.

With only 48 bits of entropy, I can’t shake the feeling that there are practical attacks I have not considered.


Does this set precedence? Under $1 dollar fine for each identity impersonation is a bargain!


Opening a zip webpage url is probably harmless compared to opening a file archive…


I think the problem is that zip webpage URL http://familyphotos.zip is a download to a file archive that people will open.


And <a href="http: //perfectlynormalwebsite.com/familyphotos.zip">familyphotos.zip</a> isn't?

Am I missing something? What does the TLD add that wasn't possible before? Auto-vivified links in the 0.001% of users who only read text/plain? C'mon.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: