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

it's mine.

Exactly. It's beyond me that people have to fight to use what they own as they please, or even are asked to justify themselves...

I'll stick with Owl for a while longer. This native feature doesn't support calendars or address books, making it essentially worthless to me.

Also it's based on a protocol that's dying (slowly).

Good to see they're attending to exchange support, but this is a lackluster step.


In my opinion this is a poor, vendor-originated commentary attempting to spread FUD and drive people to a product. Not worth reading, and I wish I didn't.


Accepting responsibility and leaving is a cop-out?

That's totally opposite to my impression. She took responsibility, left and the company has now shown externally and internally that these kinds of errors have large consequences.

Also: This was not the first sign of mismanagement and bad culture at Norsk Tipping.


I get that it's sort of an accepting of responsibility if you accept we made a grave error -> the person who made (was responsible for) the grave error must be fired; I am ultimately responsible for everything -> I must be fired.

But it's not an accepting of responsibility in the sense of we made a grave error -> it must be made right. Someone getting fired doesn't help the people who were improperly notified. It likely doesn't help prevent improper notifications in the future.

Taking responsibility could mean setting up a quality control process for future changes as well as validating all current the notification strings are appropriate and accurate. And sending an apology to the affected people.

That said, it is perhaps a time for reflection when considering this:

> The company acknowledged it has experienced “a number of technical problems” over the past year.

If you're responsible and things continue to go wrong, perhaps someone else would do a better job, and the best choice is to let someone else have a try.


Yes, that makes sense, if there were many instances and really the leader could have observed that and better lead. My comment was about this approach in general, and specifically when it's just one incident resulting in someones head rolling, in what seems to be a disconnected feedback loop.


Ah, let me admit - My opinion wasn't about this incident. More of a general response to this approach in general.


Thankyou! I was starting to question myself looking at those small bar-graphs. That's not a spark-line!

Cool, I guess, but no spark-line.


I'm just gonna say it: this does not matter. Just use whatever you want. If you're afraid that someone is going to think less of you for it: the people who matter won't.


For those who downvoted this - how does a millimeter of difference in the length of a line matter?


Well-meaning can vary if you don't put spaces around your dashes, and a well—meaning writer wants to ease the job of the reader.

ıt might simpıy not matter though, a miııimeter here and there, ı suppose.


An excellent example of why dash length matters. Because of the wrong usage of ‘—’ and ‘-’, it took me 10 more seconds of rereading and re-parsing your comment to understand what that first sentence meant.

I see what you did in the second paragraph too. It’s another example of “a millimeter of difference in the length of a line” mattering in that it looks weird, though it’s not much harder to read.


The undotted small "i" character comes from the modern Turkish alphabet. It's perhaps only slightly disorienting for an English reader to slightly shorten some letters that are just lines in a sans-serif font. In Turkish though, a millimeter of line can make an entirely different letter.

Being able to render a variety of line lengths with different meanings is a cool and useful thing.


The difference in dash length really doesn't matter and your example is not the same at all, but it probably made you feel really smart.


Did you mix those up on purpose?


giving it a domain-name and serving with https encryption on it would improve all kinds of security.

then again, it feels wonderfully apt that it is on some random ip


Security of what? You're not inputting any data of your own into the site.


Hypothetically speaking, you can still be MitM'ed.


And then what, serve me fake Disco Elysium dialogs? What's the threat model?


Either pick one of the recent JavaScript sandbox escape CVEs on a vulnerable browser, or redirect to your phishing page as to your liking. Again, hypothetical and very unlikely, but the risks are there.


They could do all of this without mitming by just making a submission on HN. The extra step doesn't add anything.


Then why don't they, do you think?


Because it's a made up threat that only exists in your imagination?


programming.dev has some good ones


highly recommend edamagit in vscode for those over here.

except there's currently a bug that stops commit from working (c - c) when developing in wsl or a devcontainer, hopefully it'll be fixed soon. BUT if you're developing directly on your machine it is an excellent interface to git.


hugged to death?

anyway - i got a great 429 back with a suggested try-after -time. it made me smile in appreciation!

well done!


That's the wrong status code

The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting").

Unless the server believes you as an individual user were sending too many it should not have been a 429 If the server was unable to handle the volume of requests more generally it should have been a 503 which also supports Retry-After


The 429 response is sent when rate-limiting (based on IP address).

Either something is wrong with my rate-limiting code or there are many people behind a single IP address.

Anyway the limits are increased now.


Possible your application isn't seeing real ips, maybe is seeing the IP of a load balancer or similar.


IME, it is relatively common to get this response code incorrectly, i.e., not triggered by rate. IME, it can be triggered by sending one and only one HTTP request to a site one has never visited before. For example, a request sent to a certain IP address with a certain set of HTTP headers and header values using a certain HTTP method and HTTP version.

Despite what "Too many requests" suggests, people writing/configuring software are (accidentally) sending this error in response to requests based on quality not quantity.

In each case where I have received it, I was able to make the error go away by changing something about the request.


Maybe one request is one Too Many at this point. ;)

Call it a very dynamic rate limit that autoscales all the way down to zero.


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

Search: