Knuth is also still reviewing TAOCP-related email and issuing reward checks. A teammate received a reward check for 1 hex dollar last month after finding an error in Seminumerical Algorithms. Along with the check, there was a printout of the original email with hand-written annotations.
Some of the checks added up to quite a bit more than that (if there's ever another error check for TeX it will be for $327.68), and one notable at a TeX User's Group conference stated that he had cashed a check for $40.96 and was grateful to DEK for it, since it put food on his table when he was a poor starving grad student.
SheetJS | https://sheetjs.com/ | Software Developer | Full time, Remote (US) | $165K - $240K
We're a bootstrapped company building open source solutions for spreadsheets and structured data. With over 1.8M unique monthly visitors, companies across the business world turn to us for challenging data processing problems. Over the last 10 years, we have pushed the boundaries of JavaScript and the web.
In this role, you will master new and established technologies while working on high-impact projects used by millions of people across the world. Balancing research and engineering, you will design and implement creative solutions that draw from your academic and professional experience.
This happened to a team I was on with Google Safe Browsing. The company was a competitor to Google in certain industries. An internal domain was flagged after a security researcher set up an intentionally vulnerable service and visited it in Chrome. The particular domain was shared with some other internal services which caused an internal outage. We registered in the Google Search Console, then leveraged some industry contacts and later our legal team (which had a friendly backchannel with Google's legal team) to escalate within Google. I believe our domains were given special treatment after that.
SheetJS | https://sheetjs.com/ | Software Developer | Full time, Remote (US) | $165K - $240K
We're a bootstrapped company building open source solutions for spreadsheets and structured data. With over 1.5M unique monthly visitors, companies across the business world turn to us for challenging data processing problems. Over the last 10 years, we have pushed the boundaries of JavaScript and the web.
In this role, you will master new and established technologies while working on high-impact projects used by millions of people across the world. Balancing research and engineering, you will design and implement creative solutions that draw from your academic and professional experience.
JavaScript has a massive and unrivaled ecosystem outside of core data analysis. The main hurdle to adoption is ecosystem and community. A generation of applied mathematicians and data scientists were trained on Python. Python overcame older ecosystems like Matlab and Fortran for its ease of use for other general computing tasks (Matlab is a decent language for large array manipulation but soft tasks like string processing are kludgy compared to Python).
In the same way that Python developers are interested in extending their ecosystem to other spaces, JavaScript developers are interested in growing into the data science space. But that doesn't happen unless there's a clear benefit for switching.
What advantages do a native JS solution have over Python? Performance: There are arguably many more developers and companies focused on pure JS performance than python. Community: A JS solution opens up a much larger pool of talent to build innovative solutions. Cost: Running heavy computations client-side, in the web browser, reduces costs for service providers.
Performance where, exactly? Most Python data munging I've seen just punts it all to C based libraries anyways. Are people doing things in pure python these days?
Under the hood, numpy and friends punt to native code. FFI / native module performance becomes a bottleneck, and Bun is correctly focusing in this area. Shumai [1] is a cool library for Bun that also punts to native code
The hardest unsolved problem is document compatibility. It's not enough to have a cool tool -- you need to be able to interchange data with existing users of Excel and other workflows. This was an important piece during Excel's journey to overtake Lotus 1-2-3.
We (https://sheetjs.com/) have been looking into document compatibility for 10 years (celebrating our 10 year birthday this week!), and our eponymous open source project https://github.com/sheetjs/sheetjs is used by companies large and small. It's not a particularly glamorous subject and doesn't tend to electrify people in the same way as build tools or frameworks.
.
There are ways to improve upon the space, but the problem is that the world has changed. Excel was designed to be the "center of the universe", a creative substrate that bypassed org security policies and enabled extremely flexible line of business tools. Excel was designed to be used by one user at a time, with fundamental inconsistencies blocked at the UI level (for example, try entering a bad custom number format). This made sense 20 years ago, but it doesn't make as much sense now.
The current crop of SaaS companies effectively monetize access to the data. They aren't incentivized to make it easy to export metadata back to Excel -- they want to keep you using the software. This runs at odds with the data portability and freedom that is needed for a successful replacement.
Whatever will replace Excel won't be a facsimile of the current tooling (what Google and Apple are trying to do), nor will it be a siloed experience (what the myriad of SaaS apps are trying to do).
Unfortunately the source spreadsheet was not shared, but the root cause was a misreported codepage (which you can actually fix with a hex editor!)
"Â ", where the second character is a unicode non-breaking space characters (U+00A0), is the CP1252 encoding of the byte sequence [0xC2, 0xA0] which is the UTF-8 encoding of "\u00A0". So all that really needs to happen is to get Excel to think that the file is UTF-8 encoded.
The fix? For XLS, there is a special Codepage record that indicates how strings are to be interpreted. The magic value to force UTF-8 interpretation is 65001, and it is possible to use a hex editor to find exactly where that record is located and change it.
This password specifically refers to "Password to Modify" and Excel 2019 / 365 clearly warn in the reenter password popup:
> Caution: Password to modify is not a security feature. ... Malicious users can edit the file and remove the password.
This type of "protection" is also present in the VBA blobs (where you can change a few bytes and work around the VBA protection)
Saving a file with a password to open actually employs encryption. The exact setting can be tuned with registry settings, but is typically AES-128-CBC.
Saving a file as "read-only" encrypts the file with the standard password "VelvetSweatshop"
Hi, random developer that somehow ended up in the top 500 but didn't have 2FA turned on (https://www.npmjs.com/package/xlsx)! npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then. Assumably the same fate befalls other random devs.
> npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then
This sucks, but invalidating the pre-2FA tokens is unavoidable if their goal is to tighten security of top packages. I don't know how this went down behind the scenes, but hopefully they announced giving you some long enough window like 60–90 days before the old tokens were invalidated.
However, what does invalidating your old tokens have to do with signing into the web app that uses your username and password?
>Due to ongoing legal matters between SheetJS LLC and npm, Inc. (which will not be discussed here), it did not make sense to continue using the public npm registry for distribution.
Did they tell your users that they locked out the developers? Uhm.... I kinda of expected some mediation or a step-by-step, but that just a dumpster fire solution.
