Hardly a hot take but a lot of people seem to think that if code isn't actively being worked it, you can't use it, as if there can never be a point where fewer and fewer bugs are reported and fewer and fewer features are requested.
when's the last time Knuth wrote a check for TAOCP? Is it "dead"?
Heh, that's kind of a bad example, because Knuth is still actively writing TAOCP, and presumably does still send out his (now symbolic) reward checks. Volume 5 expected by 2025! https://www-cs-faculty.stanford.edu/~knuth/taocp.html
> I still take full responsibility for the master sources of TeX, METAFONT, and Computer Modern. Therefore I periodically take a few days off from my current projects and look at all of the accumulated bug reports. This happened most recently in 1992, 1993, 1995, 1998, 2002, 2007, and 2013; following this pattern, I intend to check on purported bugs again in the years 2020, 2028, 2037, etc. The intervals between such maintenance periods are increasing, because the systems have been converging to an error-free state.
(The latest round, in 2013, did surface one bug: the debug string representation of an "empty" control sequence was missing a space.)
> I imagine most of these checks (definitely all $7 of mine)
The 0x$2.00 check I got from 10 Feb 2020 was for one typographical item in Volume 4A and one pedagogical improvement in Volume 1, Fascicle 1. So it is certainly possible to still get checks for material that is already published.
Since it is now 2020, anyone with bug reports from the typography stuff should send them in soon, wouldn't want to miss the deadline.
- On page 715 of Volume 4A, he had something like \`a when he meant to have just à.
- In Volume 1, Fascicle 1, there is a convention that the "main" entry point of an MMIX program begins at LOC #100. The convention is established early on and repeated throughout the text. However, at no point is it explained why LOC #100 was chosen (instead of LOC #0, LOC #80, or whatever). It could be gleaned through careful study -- LOC #0-#80 are reserved for trip/trap handling and one more location before #100 is reserved for a special second entry point -- but you basically had to read the entire fascicle to find /all/ of these. A naive user would be likely to try writing a program beginning at LOC #0 and wonder why it didn't seem to behave correctly. My suggestion was to just add a note explaining why LOC #100 was used. He agreed and you can find the added note in the latest errata for Volume 1, Fascicle 1.
Oh thank you. I looked up page 715 of my copy of Volume 4A and can see the \`a. :-) I also see both corrections you mentioned in the online errata, that's cool. :-)
He no longer writes checks to people for bug-hunting and hasn't done so for years due to concerns about the proliferation of his banking information. He mails out certificates.
Those numbers across the bottom are your bank's routing number and your account number. I'm honestly surprised I don't hear more about e-check theft done using those numbers.
> Those numbers across the bottom are your bank's routing number and your account number.
Those aren't secrets, are they? Isn't your bank account protected by separate secrets and or physical authentication tokens? You can't just take money out at a bank by giving a bank account number, surely?
> You can't just take money out at a bank by giving a bank account number, surely?
That's exactly what a check is. It's a legal document that says "I give you X dollars from account Y." You can use a napkin instead of a the pre-filled sheets of paper your bank sends you, and it's still the same legal document.
Typically your signature is checked against one on file, but only for large transactions, and of course handwriting signatures can be forged. And, if you are writing checks against other people's bank account, you'll probably go to prison. That is the check on the system.
(It's no different than signing a contract. I'll do this work and you'll pay me when it's done. What happens if they don't pay you? You sue them. The root of trust is the judicial system.)
Right, but the bank is still entitled to check with me before handing over the cash. They have no way of knowing that I signed the contract. Account numbers and squinting at a signature isn't any kind of proof!
> the bank is still entitled to check with me before handing over the cash.
They're allowed to, but have no (legal or socially expected) requirement to do so. I've never heard of a bank doing so for small (<$10k or so) amounts, and then only if fraud alerts are already present.
Those numbers are not secrets. They're literally just the bank's routing number and your account number. Using those numbers anyone can withdraw/deposit into that account. Madness isn't it?
I'm from the US and I've never heard of a bank verifying permission before releasing funds, they simply release the funds. As far as I know, US banks no longer check the signature (if they ever did) and no longer validate the date on the check (at least at my bank you can no longer post-date a check).
We recently lost a book of checks and the bank totally wigged out. They demanded that we close the account immediately and it took a decent amount of back and forth to talk them into waiting a week (we wanted existing checks to clear). To my mind, this implied that they did no validation on checks.
I haven't actually used a check in a looong time so I don't know exactly what you mean.
I do know that I keep the numbers off a check from my checkbook I received when originally opening my bank account like 10 years ago in Lastpass. When sites that don't accept credit need payment information (my student loans mainly) I just copy/paste the numbers into their payment form and the money gets taken out of my account. No verification whatsoever, Nelnet is able to just withdraw the money from my account using those numbers.
I assume anybody with a debit processing backend or service can do the same if they have the routing/account #. It's kind of a wonder peoples money doesn't just disappear all the time really.
No, you would have to do some authentication at a physical bank itself.
You can use the numbers to request a wire transfer from the account. In fact, when you're setting up an ACH transaction for bills and such, they tell you to get the numbers from a check.
Check forging. Was a big problem years ago when checks were widely used; These days they're almost dead so; (See 'Catch me if you can' film if you didn't already!);
In the UK if I write a check my bank checks with me before honouring it. They don’t just let you wave a piece of paper with numbers on it and empty the account lol.
I don't think anyone really uses mp3 for audio compression anymore, though. There's FLAC, mp4 (AAC), and free Vorbis (which claims to be competitive with both); and DVDs and whatnot are still using AC3, EAC3, and various other Dolby Digital audio formats. Given that landscape, I don't know why you'd pick mp3.
Well most pirated music albums and songs are still in mp3s. Even bandcamp I chose mp3s for itune, maybe it's bias confirmation, but I don't believe mp3 went out of style.
Do you have a source for this? Is this audio compression for music production people or in general? I just can't see mp3 being out.
I keep a library of music, ripped from cds I own. My master copy is FLAC, but I use mp3 for on-the-go copies because it is not patent encumbered and it is supported everywhere.
If you have a suggestion for an encoding+container that is will work out of the box both natively and in every major browser, across every major OS (Windows MacOS, Android, iOS and GNU/Linux, specifically distros like Fedora or Trisquel that don't ship nonfree codecs in their default repos), I will gladly switch to it.
Does Ogg Vorbis play on iOS? In my experience it has pretty good support across most other platforms. You do have to install Web Media Extensions on Windows, but that's little different from having to install libvorbis on Linux.
MP3 is good enough for most casual uses, and not being patent encumbered makes it easier to use. I honestly don't know why I should bother using anything else for personal audio consumption.
TL;DR: at over a decade old it's a primordial Node lib which has become increasingly difficult to evolve as the platform introduces new features, so rather than break every user with a massively disruptive new version that embraces modern features it's going to attempt to quietly sunset to free up the oxygen in the room so that new libs can grow.
I'd agree if it wasn't for it having to remain compatible with future node releases. If it was (and I don't know if it is) part of the node.js testsuite then it seems like the ideal way to end active development on a library.
The annoying thing is, since it is marked as deprecated, everyone installing a package that relies on it will get a deprecation notice. I already had some users opening issues on some of my projects for this.
> request will stop considering breaking changes.
> The committers that are still active will try to merge fixes in a timely fashion
Sounds to me like the library is "done".