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

Okay, discriminators are randomly assigned unless one pays for nitro, that said they have account creation date on record, so they can do it in order no problem.

The issues are the order they have chosen is not that simple. They are giving verified bots first choice (some of these are questionable), then owners of partnered servers, then discord for business, then it is going by account age.

They have added a clarification to their blog post: "Current Nitro subscribers paying for the ability to customize their discriminator that registered for Nitro on or before March 1, 2023 will also be given early access." Yeah, when early access is in the list I do not know.


Let me be clear, basically the "rolling cipher" is DASH/HLS streaming for automatic quality changing. This has been an argument RIAA has been making since 2016, but outside of the judgement in Germany (which is wrong). All they have had on it are default judgements where no-one has even tried to counter it in court.


Ah, there is a logical fallacy there. That logical fallacy that is just because they reused the same bitkeeper word that they took it from there AND are using it in the same sense. Ultimately this is a strawman, you are putting Bitkeeper's practice and arguments onto git.

Slave is never used once in git documentation, never has been and never will be: https://git-scm.com/search/results?search=slave


That’s fair, but the OP’s conclusion had no supporting premises at all.

Ultimately this is a digression; this change is being made not because of the intentions of the authors of git, but to be considerate of users of GitHub.


> to be considerate of users of GitHub

Which users?


1) My server runs nginx on debian squeezy, even using the newer packages for nginx from upstream, they are built against OpenSSL 1.0.1t matching the system version which does not support APNL. So while I have HTTP/2 enabled, neither Mozilla Firefox or Google Chrome can negotiate to even know the protocol is available for use.

2) HTTP2 forces TLS encryption and compression and several other things making it a PITA to debug as one has to first extract the session keys, then decrypt and decompress the data before one gets something readable. What's more wireshark does not yet have the same level of support for piecing together HTTP/2 as it does HTTP 1.1. And even after all that the data is still a binary format.


1) US government should cancel all contracts with Equifax,

2) US government should demand a list of all effected SSNs

3) US government should use pre-breach tax data to issue replacement SSNs to all affected and send Equifax the bill for doing this.

3) US governments should ask the courts to consider any use of a breached SSN on any credit issued after breach date to not be enough evidence alone for any credit recovery processing (basically nullifing any credit after the breach for an affected SSN without the Banks being more careful with regards to identity checks).


Except for the first #3 (counting is hard) I agree with all of these.

I just don't think it's practical to reissue millions upon millions of SSNs. We need a more permanent and secure system than SSN entirely.


Well, it only takes one report to the relevant authority.


Same goes for claiming to be made in most countries when it is not. I'm pretty sure the author/company founder is in France and EU law has quite a few things to say on the matter of misrepresenting goods and services provided. His post is pretty much a confession of such misrepresentation.


"Converting the (VERY analogue) Morse key into a digital device was the next step."

Urm what? A morse key is either on or off, pushed or not pushed, morse code is an on-off keyed digital mode. It is not analogue under any circumstances.


A year or two ago, I started doing software for embedded hardware. It’s terrifying how many things we software developer abstract away, actually behave far more strangely in the real world.

There could be nothing simpler than a button press, right? And yet in the real world it often enough bounces on and then off several times, quickly. An the tiny on/offs themselves change voltage for tiny bits of time as the current coming through bounces off other components in its new path before settling down. There’s nothing that will shake your faith in binary logic as a simple hardware button.


Technically code via SMS is 2FA, it is proving one has access to that cell/mobile phone account either directly or indirectly. I would say it is a terrible authentication system but it is a different factor to something you are (biometrics) or something you know (password/passphrase). However cell/mobile phone accounts are really easily to social engineering access to via the phone companies to send replacement SIM cards for that IMSI, not to mention the encryption to/from the phone has known major flaws (especially pre 3G GSM standards). Far better to use TOTP, HOTP or U2F which are actually designed for authentication purposes rather than have the phone company attempt to do it for you.


If I was Google I would just remember I served add for website for account x but the number on the click was for account y. Real easy to detect.


I don't know enough to say with certainty, but I don't think it's that simple. The way I understand it, the script that loads Adsense does/did so at the end-user level when their PC loads the HTML and executes the script in their browser.

For what you are saying, I think it would be necessary for the original request to come from the site owner to pass through to the end-user, which I don't believe is the case. If that were the case, ad-blockers would have a much harder time determining the source of the content.


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

Search: