I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf
I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).
It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.
A regression here and there would be normal before, major features breaking in this stable 25 year old software is simply unheard of.
This is not exciting cutting-edge software, it's a boring financial app. My instinct is people want stability and confidence that the output won't change and that their records will still parse.
If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.
In 2022, Google TAG were awarded a "lamest vendor" award at defcon for fixing a Chrome vulnerability they discovered was being exploited in the wild... without asking for permission from the NSA first. That was the turning point for me.
Imagine you reuse the same password everywhere, and are sick of credential stuffing attacks. You ask your friend for advice, and your friend tells you to just enable TOTP when available, explaining that when there is a data breach you will be safe.
That is obviously bad advice, the vast majority of services do not use TOTP and you will have to race attackers to change your credentials quickly at dozens (hundreds?) of services. I think a reasonable person would say that you have not "prevented" credential stuffing.
A far better solution is unique passwords, it works today with all service providers.
I'm not familiar with the expert they consulted, but the claim that "The main advantage of 2FA is that it is much more difficult to gain access to your accounts via phishing attacks" is just plain false.
TOTP or SMS-2FA are obviously phishable, if you just entered your password into a phishing site, why wouldn't you also enter a TOTP code? I usually point to Modlishka as a practical example (https://vimeo.com/308709275) to help visualize this.
In fact, the main (claimed) advantage of 2FA is that it prevents "Credential Stuffing" of reused passwords. I personally don't think TOTP (or similar) are a good solution to this problem at all, but this is a thorny issue.
I think that's a miss for Claude, this doesn't look right at all. The accrual account is an okay solution, but the syntax is wrong! That syntax is only used for budgeting and forecasting.
I think the solution is effective dates, there is an example pretty close to this scenario in the manual:
This seems like a weak excuse, the same problem exists on UNIX, but slocate solves it well enough. The slocate solution is to build the index and record permission and ownership, then it can restrict output to entries you have permission to see at query time.
I bought a few items at a drugstore yesterday, and noticed the cashier had very elaborate nails.
She used the second knuckles on her inverted hands (i.e. palm facing up) to operate the touchscreen PoS system, and was very efficient. Tool usage can sometimes be adapted.
Super cool, I didn't know about this - too bad it's not archived. I did know about a different game for 1-2-3, I even managed to track down original media and get it working in Linux!
A while ago KeePassXC published a glowing audit report, but the report just ignored the scary stuff -- i.e. the things being disabled here like browser integration. I took a quick look, and thought the design could use some work -- but when I tried to discuss it they were very dismissive.
I did file a bug for one of the vulnerabilities we discussed, but I don't think they changed anything and didn't seem interested.
> Testing cannot be used to prove that a flaw doesn't exist, only that it does.
FWIW, I wrote a similar blog post about a different encryption bug that really seemed like it should have been found by fuzzing, and had 100% coverage.
I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf
I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).
It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.
I wrote a display driver to make that work a little better: https://github.com/taviso/lotusdrv