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 love your pages, they are really great, especially the one about reverse engineering the display driver to discover that 1-2-3 actually supports better display resolutions.
I've been running the DOS version in DosBox-X for Mac at the moment to ground l123 in the reality of what using 1-2-3 was like. I'm using Release 3.4a, which was the last version that didn't go full GUI (R4 for DOS was kind of a Windows-light version). I'm trying to balance fidelity to the original with something that might be useful to actually do some productive work in, especially when one might not need or want the full GUI/overhead of Excel or (shudder) Google Sheets.
What specifically has gone poorly? Is a dozen bug reports high or low compared to previous versions of the software where humans are writing the code?
I don't use ledger-cli myself but I do use the similar software hledger. I don't pay very close attention to hledger's development process, but I haven't noticed any bugs that affect me in years of using it.
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.
I think apps like this are the real risk. Who is going to get in trouble because vim* has a bug from AI generated code? Errors in your accounting software can get you into audit/compliance trouble.
I saw that tweet and thought it looked crazy. To me, it sounds like a death threat. Especially given that it's posted on X.com, after a really heated argument, with no clarification afterwards.
If you didn't actually post that tweet, that's great! I'm happy to be corrected
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.
This is XMMS, a X11 Clone of winamp. We all had it on our desktop these days. And hell yeah, our Linux desktop could look anything we wanted. What a time!
Looks like you're on Windows? You can run X apps with XMing, I used to do it years ago. You can run the actual X app and use it, not just get a screenshot.
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.
Ok that's weird indeed. Here at European hacker events this action would be applauded. Getting permission from spy agencies before fixing something would be a surefire way to get lamest vendor, lol.
Most there don't trust government. And besides security holes can be used by all sides so it's imperative to fix them asap.
Yikes! One would have expected a little more code review or a design review from a hardware manufacturer, especially of security system. A system that people have been worried about since the Pentium FDIV bug.
I feel like using the example key isn’t really the big failure here.
They didn’t need a keyed hash at all, they needed a collision resistant hash.
SHA256 would have eliminated this vuln and it has a hardcoded “key” built into it.
Using a secret key for CMAC would not have been more secure, it would have just meant sophisticated hardware extraction of the key was required before this attack could be mounted.
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.
The point here, I believe, is that 1Password will only prompt you to enter the 2FA code if the domains match, same with the password. Your point that if you've already decided to enter your password then entering the 2FA code isn't much of a hurdle is sound, but from the perspective of a user of 1Password, it is indeed very surprising (and rare!) when I try to log in to a page and find that 1Password won't show my log in because the domains don't match. It happens, usually due to some cross-origin login flow, but it's rare. So I think the claim isn't false, it's just based on a premise that might not factor in for different people.
If domain doesn't match, password manager of choice will not suggest to populate credentials. In that case it doesn't matter if 2FA is saved by the password manager, or is managed on another device, because you won't have the chance to use the 2FA.
If domain doesn't match, and you manually copy the password, and login, you can as well manually copy the 2FA code.
I think their point was that it's less phishable from the perspective of needing the attacker to try logging into the site with it in realtime instead of being able to just store the password for some later time. The needed concurrency makes it more difficult (if only slightly).
I'm curious though why you don't think TOTP or similar are good against credential stuffing though, would you be able to expand upon that?
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 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:
I don't think it's terribly wrong. It will generate the desired entries (internally) and proper reports, if you add the appropriate option (--forecast=... for hledger, something else for Ledger). Or you could use it once to generate permanent journal entries, in your main journal or a forecast journal:
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