Heard about this ordeal on NPR a while back. It's crazy how dependent a community can become on a piece of software and at the same time no one takes measures on preservation or open sourcing that software.
Especially with all the passion and work Tom put into the program and his work with multiple Rabbi's to tweak in their slight changes and localized traditions. This feels more like much needed historical preservation that the community could have guided.
I've seen it multiple times; the sole company/developer often considers the software "their baby" and doesn't want to "let it go" for a number of potentially quite valid reasons, such as fear of loss of livelihood, disagreement with others on the direction, etc.
Tarn Adams has a similar situation with DF. But hopefully they realize that at least having some sort of 'make available on death' could be valuable.
We have already lost untold countless relatively custom software packages for niche markets that you've never heard of - and people just continue or go back to doing things by hand.
Last I heard Tarn Adams is considering open-sourcing at least parts of it in the long term now that they are more financially independent. The Steam launch was probably the best case scenario for both developer and community.
Yeah, and part of me wishes they did this years ago, but at the same time I can understand they wanted to keep it small on purpose; once you go public like on Steam, the dynamics change and you can't just bury your nose in code all day but you have to deal with finances, refunds, reviews, legalese, etc as well.
Does escrow really work though? If the author of this software had placed a copy in escrow 25 years ago it is not clear to me that it would much use if the customer pulled it out in 2023 and tried to get it working. Access to the source, sure, but recreating the build chain on modern systems is not guaranteed to work at all. If someone told me they had escrowed 1998 vintage code and it was all mine to tinker with I would expect to find a CD with the release binaries, and a fat lump of a Visual SourceSafe database that expected NT4, some ancient C compiler (or worse, some VB5 runtime and a plethora of random DLLs) and who knows what level of deep magic to resurrect. And thats assuming I could even find hardware to run the OS of the build machine. Lord help you if there any kind of copy protection dongle nonsense going on, as was popular back then.
I don't work in that department so I can't tell you the exact process, but this is how it was explained to me: The goal of escrow is to have people not only understand the toolchain and ensure that they can get it working at the time when the software is put into escrow and then document it, but to also periodically pull it out of the archives and verify it can still be built. As part of escrow, steps are taken to ensure that any additional necessary software and hardware is kept to support this. That's what you're paying for with something like NCC's escrow service. If you want I can actually just ask my colleagues tomorrow.
> It's crazy how dependent a community can become on a piece of software and at the same time no one takes measures on preservation or open sourcing that software.
It's almost always because it's a labor of love and isn't worth the money.
Richard Douglass created Ballroom Dancing competition judging software because, as a competitor, he was wasting vast amounts of time with crappy judging and software (especially because a lot of software wouldn't deal well with garbage network connections).
https://www.douglassassociates.com/
It has roughly 300 uses per year. It charges roughly $1000 per use. That's about $300K per year for taking the support calls, managing the credit card bridge, and updating any features due to the OS makers breaking shit.
They have a plan to release the code when he passes. However, that probably isn't enough. It's likely nobody has the programming AND ballroom dance competition experience necessary to keep it going.
$300K/yr isn't a labor of love, it's skimming money from dues payers by being friends with corrupt leadership.
Lots of ballroom dancers are computer science students who could build this as a class project, and any programmer who knows a ballroom dancer can look at the paper slips and write software to automate it.
"Garbage network connections" are trivial to deal with with modern web app practices.
> Lots of ballroom dancers are computer science students who could build this as a class project, and any programmer who knows a ballroom dancer can look at the paper slips and write software to automate it.
Feel free to write it. People have been complaining that they want something better for quite a while (in both the US and EU). This project has been around since 1997(!) and someone could have replaced it over 25 years. And yet, no one has.
This isn't a technical problem and it absolutely stupefies me that people can't seem to wrap their heads around this.
You will field customer support calls. A lot of them. Ballroom competitions tend to have lots of non-tech people in them. You will field irate calls because something went wrong in the middle of a competition (even if none of it is your fault).
All for $1000 a competition. Not per competitor--per competition. Roughly speaking--the price of tickets from two competitors.
I look forward to seeing your replacement.
(Note: In fact there ARE other "more modern" solutions in the space. And they all say "Contact Us" when you start looking for pricing. Translation: we're going to charge way more than $1000).
I have no idea how much running a dance competition costs, but given that competitors expect to spend $450[1][2] on entry fees for a single competition I think that the organizers spending $1000 on software seems like a bargain?
> it's skimming money from dues payers by being friends with corrupt leadership
This is a really, really odd take.
Firstly, as pointed out above the cost of $1000 for a competition seems pretty reasonable.
Secondly, where do you get "being friends with corrupt leadership" from?
Most sports/recreation activities suffer from a huge lack of software. They are crying out for anything that helps them. If the leadership knows the author of the software, that isn't corruption that is a small community - and probably a good thing since it means the author probably listens to them.
I was on a comittee organising about 8 years back for the southern universities latin and ballroom competition, so not a professional one, but also not profit making.
The full day cost around £6200, that included music, demonstration couple, compare, 6 judges, food, first aiders, venue hire, officials, trophies, medals, programmes, decorations. We then charged around £12.50 entry for ~500 students.
The national competition for universities happens in blackpool every year and I imagine the costs are around 3-4x that considering the venue and number of officials. And unless we got discounts for being universities, or the judges are paid less, i imagine it costs at least £28,000 to put on a big professional competition.
In a comparable venue to the winter gardens in blackpool
What an amazing jump to go from software that is clearly desirable enough that people are paying for it to "skimming money" and "corrupt leadership". To take issues THAT STILL EXIST in 80%+ of software and call them "trivial".
Yes, the tools to build this product and make it function obviously exist. If you can do it cheaper, then do it and undercut him!
I don't think you want to handle billing, support (for VERY non-tech savvy groups) and build and customize the software fulltime for <300k revenue (not profit!). Especially not at the "$1k a client project" price. Anyone can crank out a webform, very few people can integrate software into a client and have the client continue to want to pay them!
Accusing someone, without merit, of skimming and corruption is bordering in the libel territory. Doing it in this case is also rude and shows a lack of experience.
> Heard about this ordeal on NPR a while back. It's crazy how dependent a community can become on a piece of software and at the same time no one takes measures on preservation or open sourcing that software.
I don't even think this necessarily has to do with open sourcing necessarily. This is a wider software conundrum as well. From the article:
> The first warning Shepard got was when she went to update her Mac, and the system warned her that TropeTrainer wouldn’t run on the newest OS
Operating System updates frequently break software. Operating System transitions break software a lot. This is a thorny issue, imo, because on the one hand when people buy software I doubt they're thinking about how it'll be useless if the Operating System's company (or community) think they can do better with new APIs and behavior. On the other hand, updates are part of moving something as vast as an OS forward, and at least some amount of the time they're necessary.
Windows provides some ways of running older software in a VM. I'd be curious if they've tried such a thing with this software. MacOS I'm not so sure of, since even the ISOs are somewhat controlled.
Open source means that anyone sufficiently able and sufficiently motivated can keep up with these changes. In that humans have to be touching code to keep up with api / abi changes, not letting humans touch code is the actual problem in this case. The human that did died, and the humans left kept it closed source.
That looks a lot like a claim that software only deserves to exist if it is made by, or attracts the fanatical devotion of, people who have a deep love of maintaining software against a moving target.
Ugh.
The expectation that once you've made something you can't expect it to keep working without endless catchup, attitudes like this one, are why I have completely given up making software for fun or to solve noncommercial problems for myself and others.
> The expectation that once you've made something you can't expect it to keep working
I don't think there is a single type of item in the world for which you could expect it to keep existing indefinitely without maintenance. Machines rust, wood degrades, paintings need restoring every few centuries. And even when properly stored in controlled atmosphere etc, books from a few centuries ago are almost unreadable because the language has changed so much since then (see https://web.cn.edu/kwheeler/diagram_4english.html for example).
Everything in this world needs constant maintenance or it breaks down. Why would you expect software to be any different?
I expect it to be different because it is different.
Machines rusting and painting needing restoration is because they oxidize.
Wood does not magically degrade, it decomposes.
These are physical phenomena confined to the physical world.
Your example of the book being unreadable because people's language changed, that is a closer example but even that falls short because language is a human to human communication pathway. We have to spend literal years training people to understand it, it is inherently chaotic and messy.
Software is math, it is engineered. We don't wake up to find that suddenly the coefficient of friction is different and now our tires fail to grip the road. Or more to the point, that our speed and feed calculators are now trash and will crash the endmill into material ruining the machine and part.
Computers and their ability to run or not run software after and update is completely in the control of the people programing the updates. The reason so much software fails is because either A. It was not well designed to begin with or B. the people creating the update did not design it well.
Except software isn’t math. Math is entirely self contained and self defining. Software has dependencies in hardware and other software that are not contained in the software. A better analogy is the symbolism of an algebra and way of expressing math. While calculus hasn’t changed for techniques known at the time, fluxions aren’t supported as a method and symbology while a derivation of liebnitz’ notation is. The math is invariant but the symbology and evaluation methods change with time.
Likewise hardware architectures change, and it’s absurd to assert machine code from the Eniac must run on every architecture, as well as every variation of every machine ever made on every future hardware in perpetuity. There are to this point many preservation efforts that create emulators that run on modern hardware or reference virtual machines that can be carried forward. But to expect this to be done in situ everywhere all the time for everything is on the surface absurd and unreasonable to an extreme.
Edit: the Eniac didn’t have machine code, but switches and wiring - even more to my point. While it’s still just math and logic, it’s not reasonable to carry forward all software configurations of the machine.
This is a wholly false analogy. If I store most things properly they decay only very slowly and most maintenance tasks are easy. The software equivalent of that is only making sure I don't lose something to bit rot. No software lasts long enough for that, I look away for a year or so and someone broke something it stands on. It's not analogous to keeping an old book in a safe, it's analogous to keeping an old book in the street while random strangers queue up to piss on it.
I have books up to 500 years old that are perfectly readable. I have programs I wrote single digit years ago that I'd need to give up a couple of days just to find out if I can get their build chain back and dig them out of dependency hell. Not worth it to buy, at best, a few years before I get to repeat the experience. Restoring and rebuilding old physical things is also far more rewarding because when I do it properly I never have to do it again.
You seem to be cherrypicking the heirloom quality physical items and comparing them to programs that were constructed with not nearly as much care.
I've owned physical objects that were worthless a few months (cheap throwaway), and have also worked on code that was over 5 decades old and still compiled just fine. If you construct the software with care it is entirely feasible to have something that you can run several decades from now, but that does mean that you shouldn't use dependencies which might disappear in that time. Curl or sqlite are probably fine, a dependency with a single maintainer is probably not fine. Network dependencies on DNS or NTP are probably fine, depending on the API of some 1-year old startup is almost certainly not fine.
I feel you. But the challenge is supporting ancient apis and abis over time greatly complicates the underling runtime. There’s a natural tension between flexibility for the evolving system that adapts to modern needs and techniques and hardware and one that runs ancient runtimes in perpetuity. Things have gone back and forth over time and the winner tends to be the simplest one, which is apis stay stable over some lifetime until some well advertised horizon then things stop working if they don’t make the effort to evolve. Just like I don’t expect to be able to plug in a old mainframe RLO drive into my MacBook M2Max and have it work, you can’t plausibly expect ancient runtimes to work forever. That said, a lot of effort goes into writing emulators, and I’d expect this specific software will see a second life at some point
> Open source means that anyone sufficiently able and sufficiently motivated can keep up with these changes
Provided there is anybody with very rare combination of being developer proficient in whatever language was used to write this software and who knows how Torah is read/sang
Yes you can get very old software running in Windows using various compatibility tools. Like isn't it possible to get Windows 3.1 software running on the latest releases of Windows? There's definitely just a setting in Windows 10 to run compatibility modes back to Vista. Earlier versions of windows that can be run in HyperV can go further back.
Not so much MacOS after a few years, though they did release Rosetta and Rosetta 2 to handle the transitions to and away from Intel processors.
On Linux, as long as the program is compatible with Wine[1] to begin with, Wine will support programs that that require basically any Windows version. Maybe this specific community needs to spin up some Ubuntu or OpenSuse boxes?
No, and it's much more thorny than you make it out to me. Windows Vista (I think... 7 for sure) and later cannot run 16bit exes at all.
While the software itself was 32bit, many of the intallers of that era were Intallshield/InstallerWise that were still actually 16bit, so while if you could get the thing installed...you can't.
The only way you can get win311 software working on win10 is to install the 32 bit version (aside from emulation). Not sure win 11 has a 32 bit version. Also win311 apps can be wildly picky what sort of dlls are installed. So your mileage can vary.
Running old versions of macOS with VMWare Fusion is pretty easy as long as you still have an Intel Mac. I've been doing it for years to build legacy software, and for testing software compatibility with old versions of macOS.
This a bit of generational divide -- I think as more developers, even those starting out later in life, just live with open source software as the norm the more of them will just consider opening their code now or when in inevitable happens.
I think we take for granted the obviousness of open sourcing something and having a community potentially continue development when you're gone.
People were pissed with Bill Gates for close sourcing DOS so your open source is new and hip bit can get off our artificial lawn! <ShakesWalkerAndVi />
Actually software was almost always free and public domain up until the early 1970’s as accountants realized they could extort more dollars by making software licensing models. In 1983 Richard Stallman made the gnu copy left and fsf as a reaction to the role of aggressive sales jocks and bean counters in computing. The rest, is, of course, well know. But the 1950-1970 period was also, albeit less formalized, a heyday of more unfettered public domain development. I’d also note that concurrently in the 1980’s was the shareware movement, which didn’t generally distribute source but free binaries (or with nominal distribution costs to cover media etc).
The moral of the story is accountants know the price of everything and the value of nothing, and if you really want to kill something of beauty, let an accountant be in charge. (Source: I’m married to an accountant - while a person I love, she can’t understand living for any other reason than counting money)
The reason why originally software was free is that there were no software companies, only hardware companies shipping software with their hardware. It’s good to think whether you’d have a job in that world.
Well that’s not entirely true. A lot of software was academic. And, yes, I would. It wasn’t a world that paid well, but for those interested (and there were few) there was a lot of demand. But the pay was like that of an accountant. When I grew up it wasn’t a greatly enriching career but a stable one and I never doubted from five I would do this. I was lucky to land at Netscape at the start of the current modern software gold rush ride.
Why not make it trigger on not logging in for N months, and after ignoring multiple attempts to notify you? This is what Google's inactive account manager does.
I was going to speculate more about how GitHub could handle this, but it turns out they already have a system where you name a successor and they get control of your public repos 7d after GitHub receives a death certificate or 21d after an obituary.
But they don't include private repos: https://docs.github.com/en/account-and-profile/setting-up-an...
We're talking about an optional feature for developers who want it, that you have to go and turn on.
(And it should have very clear warnings before you turn it on so you don't accidentally make things public that shouldn't be. Plus, there should probably be some sort of way to tag which repose would still need to stay private even after your death.)
Eh, if I don’t respond for a few months I’m probably dead enough. It’s something you’d enable yourself, so you’d know that all your repos were made public if you ever wake up from a 6 month coma.
Telegram allows you to auto-delete your account after a configurable number of months of inactivity. That neatly side steps the "how to prove someone is dead" problem.
But it puts the onus on the user to decide what they want to happen in those circumstances rather than leaving on Telegram to decide whether such and such person is living or dead.
It seems even worse than that: the fevered dream of of a single person, leaving behind incomprehensible 5mil+ program shaped around custom coding practices that others wouldn't understand and would struggle to modernize. (For reference, the linux kernel is ~8mil.) Even open sourced, it's likely it would be hard to maintain or extend without that intimate knowledge.
THIS. "Open Source" removes one of many barriers to the code being well-maintained over time. "I'm sure that somebody qualified will step up and..." is exactly the sort of wishful thinking that got them into the current mess.
I know, it’s amazing how Debian still uses isc dhcpc, what a massive blunder of open source software.
A little tongue in cheek, and I know off mainline maintenance exists, but it’s still the same ordeal - oft presented with a different tone of backdrop.
I used TropeTrainer to study for my bar mitzvah! Brings back memories. A shame it's gone now. I wonder if the source code was ever in any sort of repo online, or if it was only ever on the guy's computer, in truth.
So, speaking from an ethical standpoint - and I mean purely philosophically, not in terms of legalities - what would be wrong with reverse engineering this program and finding a way to get it running again, for those who paid for it? If it's just a matter of spoofing a couple web requests and maybe bypassing some activation checks, I suspect it could be done.
I was thinking the same thing. It's effectively within the realm of abandonware at this point. (edit: I guess someone released a new version about a year ago but it's not as good?)
People have been reversing stuff like DOS games recently [1], I don't really see any reason why this program couldn't be done the same. I think the legality is kind of just handled by not packing in the binaries along with the code. Personally I don't know a deep lot about reverse engineering, but it sounds like an interesting challenge to try to learn it.
Yes, archive.org has an .iso file. Someone posted an activation code for the program there. Windows 7 programs should run fine under Wine on Linux. So if anybody really wants to run this, it shouldn't be hard.
But listening to chanting from DECtalk? Here's "Happy Birthday" via DECtalk.[1]
There was apparently a 90s thing for religious DECtalk files. Here's an archive of them.[2] Here's "The Old Rugged Cross" in DECtalk input format.[3]
This mysterious program that represented so much work is probably mostly a DECtalk player and a big collection of playable religious DECtalk files. If someone were to extract the files, that would recover the content. There are players for DECtalk files; there's one at the links below. Converting them to a better text-to-speech system would help.
For anyone who doesn't know, DECtalk didn't always sound like that Happy Birthday song. Think more like Stephen Hawking.
I got to play with DECtalk around 1999, when it was already old, and IIRC required us dusting off an old SGI workstation that could run it in software.
We had a school homework assignment to hand-tune DECtalk encodings of famous lines of speeches by US statesmen, for dramatic delivery. "Essential liberty", "shall not perish from the earth!" etc. Prosody, stress, etc.
> This mysterious program that represented so much work is probably mostly a DECtalk player and a big collection of playable religious DECtalk files. If someone were to extract the files, that would recover the content.
The programmer who was doing the DECTalk work talked about this some:
> I ask Schnee if Buchler’s source code could be reconstructed from a copy of the software.
> Not exactly, she says. It might be possible to induce the machine code to dump out a database of every phoneme it had ever uttered — all the tiny pieces it had used to sing Armenian and Lithuanian and Egyptian trope — and then, if you were very patient and very skilled, you might be able to write code to piece them back together.
> It could be done, she says. But it wouldn’t be quick or easy. And it wouldn’t be the same program Buchler wrote.
There's also a sound file of their implementation at the bottom of the article.
That quote from Schnee seems odd to me. I mean, what do you get if you try to decompile the binary? That output should be more useful than "a database of every phoneme it had ever uttered".
And, as someone else pointed out in this thread, there exists an ISO and an activation code at archive.org, and it should be possible to get this running in Wine or in a VM. Someone clever could probably patch the binary to make it run on modern Windows. The distraught rabbis should community-source a developer.
All of that said, even if the source code were to be found, it seems likely that further development of the core functionality might be dead. This was a man's life's work in an esoteric domain; it might not exactly be accessible code.
I’m late to this thread but I actually cracked Trope Trainer open so I can help with the speculation. The interface to from Trope Trainer to the DECtalk DLL is just strings of ascii phoneme names and pitch and duration information. The code that generates those strings has simple parts and complicated parts. There’s an encoding of the Hebrew scripture, an XML file that describes the musical notes for different “tropes” (in several traditions), an INI file mapping Hebrew letters to DECtalk phonemes (in several dialects). Then there’s a fair bit of code that actually ties those together. The old version on archive.org is written in Delphi, newer versions written in Xojo (REALbasic). That compiled code has very gnarly hand-written logic for Hebrew pronunciation rules, and all the logic for choosing which trope to sing for which biblical verse. It’s daunting in there, but if more people than just me were interested in reverse-engineering it, I’m sure we could get it done.
I have several physical copies of the last edition of Trope Trainer, with serial numbers. They don’t work because they try to phone home for activation. I think they have all of the actual code they need to run, if would could bypass the initial steps. Realbasic binaries are harder to debug than Delphi, and I haven’t had time to really dig into it.
I have a book that makes an argument from Halakha that copyright is a binding norm under Jewish law, but I feel like it's kind of motivated reasoning because copyright as we know it is a 1700s British invention and there's no likelihood that any Jewish communities observed anything directly equivalent to it before that.
There's an additional principle of Jewish law that says that Jews should normally obey secular laws of the places where they live:
Disclosure: I am neither a lawyer nor a religious scholar. These are just my own, personal thoughts related to the above comment.
The same concept applies in Islam and has been used to justify copyright for Islamic works, even audio recordings of Qur'an recitation, one of the most common Islamic media outside of books themselves. So, the idea makes sense from an Islamic perspective, but there is plenty of room for interpretation and also for different accommodations and adjustments depending on the situation.
For example, it would be likely that a scholar would rule that strict copyright may be violated if the alternative, e.g., the complete loss of usefulness of an otherwise beneficial software, may be violated because the benefits outweigh the harm.
I think it should be okay, even a mitzvah, to preserve the program since preserving knowledge of the Torah is hefsed merubeh when it's in real danger of being lost. but I'd definitely want to heck with the rabbi he was working with first. but even if the copyright status is murky there's enough sofek and it's for a good purpose.
I have a bunch of software/websites that I run. If I were to get hit by a bus, they would all go offline and there would be many confused users. There is no-one that could pick up where I left off.
I have on my todo list to make a dead man's switch. If I don't flip the update after a couple of months, a maintenance message is put up, and if I still don't update it, then an end of life process is kicked off before all my domains expire. Maybe I'll get to it some day.
The software is harder since I guess you aren't offering gratis downloads, but I think Software Heritage will eventually offer a source code escrow service.
Would you like to open source your apps when this happens?
Is the absence of updates the only signal you wish to rely on, or should confirmations from other people be involved somehow in the decision?
The software is mostly just hobby/paid apps that do have a bunch of users. It would be difficult to turn that into open source although I've thought about doing pieces of them before.
It occurs to me that a program like this can be effectively complete. And stand alone. I'm sure there's a few bugs and of course always more features are possible. But this software would probably be usable as-is in 100 years for Torah study just as it is today. It's quite a shame we still haven't come up with a way of packaging software in a way that makes it relatively future proof, even if the legal issues could be resolved.
We kind of have. Buy a new mac today and you can run a 40 year old sh program fine. Its just that most people aren't being trained on these standard unchanging technologies in computing unless they take an active interest in it. They are being trained on $newapp and how to navigate $newwebsite and become beholden to those patterns of software design sensibilities, because in this attention economy this obviously generates a lot more money than having the masses use some simple bash code to solve a lot of their problems.
It only seems ridiculous framed from the modern perspective on computing. Ask this in 1995 and yes, this would be the best interface. The only reason why its no good anymore is because these abstraction layers we shovel into people. Maybe in 2005 the best way to view the talmud was a gui based native app, because thats the level of abstraction layer people where shoveled versus the command line. Maybe in 2015 the best way moved from a native app to a website, since thats now how most people operate by then, not installing tools themselves but just going to different websites and therefore losing that knowledge. Maybe today the best way is a mobile app, because people don't even visit desktop websites anymore and don't take well to those design philosophies.
You have to wonder where this is marching off too, this march away from complexity into easier and simpler abstractions, further from the magic and raising the ivory tower of the wizard who makes these tools higher above the masses who increasingly have no idea what is happening nor any mental model to think about this stuff as it actually works. Certainly some groups benefit from siloing the knowledge of fire of our modern world, but I can't help but imagine we are all losing in this race away from complexity.
If it worked on people's Windows 7 computers, then people can probably still use it in 100 years (potential issues with network services required by the software aside). I can run a Windows 7 VM today, and given that I can also run an emulator for any marginally popular 40 year old game console I expect people in 100 years will have an x64 emulator that can run Windows 7. Not the most convinient thing, but lots of people enjoy games that way, so why not study the Torah that way
This immediately reminds me of Llull from https://unsongbook.com/, a (fictional) program that finds the names of God by iteratively speaking Hebrew phonemes.
This is absolutely maddening to read. Open source the software for christ's sake! *I* will recompile it to run on macOS Catalina or Windows 11. It's not that hard. Just get it on GitHub!
Or heck, give me a precompiled binary and I'll give you a docker script that runs it in virtualization on any computer.
EDIT: Ok I finished the article. I guess the source code is gone. But surely there is a binary floating around somewhere? I could get it running under Wine, or worst-case decompile and fix the program.
so, there’s an old version on archive.org that was pretty easy to crack a serial number and run in a VM. It uses the older, low-quality Hebrew synthesis that was cobbled together from German and French phonemes.
I have physical CDROMs and serial numbers for one of the last versions ever published, but I haven’t been able to get them to run — they try to contact an activation server which no longer exists. I think this is just DRM, and in theory it can be bypassed, but no one has managed to do it yet. (I’ve gotten a couple people to look at it, but no one has had time to seriously dig in)
The data files for Trope Trainer are mostly human-readable, lots of XML. But then there’s an incredible amount of hand-coded stuff implemented in the software - very detailed pronunciation rules for Hebrew, just written as, apparently, lots of switch statements. In principle it could be mapped out, but I’d feel more confident about it if we had a running copy of the newer version.
I actually started reimplementing the old version as javascript- I managed to get the dectalk DLLs running in Wine, and then it’s just a matter of sending it the right phoneme codes… I had it accurately reciting the first few words of Genesis! but then someone mailed me the new, locked CDROMs, which derailed me
what makes me sad is that Thomas Buchler seems to have been more afraid of people stealing his work than of it being lost. There’s something deeply ironic about coming up with a new system for teaching an ancient tradition, but refusing to teach anyone how that system works!
It sounds like the software pulled the trop you wanted from a server. So unless you already downloaded everything, there is nowhere that has it. And even if you have the install file, it’s not that useful because you can’t download the trop files.
Ah, that's much worse, and sadder. More and more "desktop" software is just streamed intentionally or unintentionally from various SaaS servers, which will go dark at some point.
Gamers have dealt with this for years now, but it's going to affect more and more things. The era of emulators being able to preserve software is coming to an end.
It's okay, for the next generation of emulators, forward-thinking users will train ai models on the service to replace the remote functionality with a local imitation.
Are you sure? Because based on my reading of the article it sounds like it's all embedded in the executable.
>I ask Schnee if Buchler’s source code could be reconstructed from a copy of the software.
>It might be possible to induce the machine code to dump out a database of every phoneme it had ever uttered — all the tiny pieces it had used to sing Armenian and Lithuanian and Egyptian trope — and then, if you were very patient and very skilled, you might be able to write code to piece them back together.
You’re conflating personal morality with group morality.
As an individual, you should strive to always follow your moral code.
As a member of a group, you should accept that everyone is fallible — including and especially yourself and your ability to even define what constitutes fallibility.
There is much to lose and little to gain by ostracizing others for their immaterial human failings.
This applies to non-religious people with their ethics/morals/facts/etc as well.
As with faith, sin also comes in many forms, from a semiotics perspective. But, one is probably best of not getting into too much detail as it can interfere with living one's best life (of which high self-esteem is a crucial component).
If it's out there as an old Windows 7 .exe what are the chances that someone could get it running in WebAssembly eventually, similar to how https://infinitemac.org/1998/Mac%20OS%208.1 works?
Not sure whether it was the article itself or the software, I got hooked to it. As the follower of another Abrahamic faith(Islam), I have nothing but utmost respect for Thomas Buchler.
1) the way he's enunciating every word and then pausing stops this from flowing nicely as a tune. Maybe its good for teaching but it doesn't sound as nice as flowing nicely would, and the tune ends up helping you memorize it better than the trop (since reading at the actual torah scroll doesn't have the trop).
2) while he has good overall sound and reading of the trop, the interface isn't highlighting the trop involved - you can memorize the reading but it isn't doing a good job teaching the tune of each trop to someone who needs the help enough to use it. It needs some re-work to make sure people associate the correct trop with the tune it creates.
still totally usable but a student needs to know to make an effort to connect the words smoothly and not pause as this person does.
edit: listening to some of this I also notice some inconsistencies in how he treats some of the trop. It might be a different style issue but I don't think so.
> Friedman explains that he had previously developed another web application, but says he can’t tell me what the app was called because of ongoing legal issues.
I heard that the creator of the K language Arthur Whitney would delete all old versions of the compiler source code and binaries before working on the next version. That's a unusual step to start afresh. It illustrates that giving enough will and resource most software can be recreated.
I've done that before and found it super refreshing. If the program is about the size you can fit in your head you can probably end up re-writing it better the second time around. Bonus points if it's in a new programming language
This is another approach at automatically generating the right interpretation. Why is the software important when the entire bible could be recorded once and then be streamed from Youtube?
There is one computer still running. Everything could be recorded.
Psalm 90 - Prayer of Moses [1]
>Note-for-note transcription of the Hebrew texts by Dennis McCorkle utilizing the DAVIDIC CIPHER.
I don't understand why they can't run old hw or a vm with legacy OS and keep running the last version of TropeTrainer they have. "Oh no! Windows 7 is no longer supported! I have to update!" is BS. It's not like it self-destructs or something. There are entire populations of Mac users running legacy hw and software, 68k boxen and even Apple ][ users still out there. You know, an OS keeps on working whether or not it is still supported and has any more updates or patches. I've still got NetBSD 2.3 and A/UX 3.0.1 booting on a SE/30. I used to leave it up 24/7, but it just eats electricity. I'm still running Snow Leopard and Mountain Lion, and my main box runs Mojave and I'll never upgrade it. What's the problem here? This software will self-destruct?
This project sounds important to a large community of people. Yet it sounds like many of the people mentioned in the article were in some ways outsiders, even within that community.
I don't know whether the reasons are the same, but we used to often see situations like that in open source software, and in computing in general before that.
It only makes sense for such kind of software to be funded by the community and be open source in the first place. It's quite in line with the goals it's intended for. Same way the trop itself doesn't have copyright.
Also, even if something doesn't run on modern Windows, good chance it would run in Wine on Linux.
Wow, it’s an impressive story, but hard to imagine learning from that software if the sample is accurate. I learned to lein and the most important thing was having a clear and clean recording of the trop.
How does Windows have a reputation for "backwards compatibility" when every single piece of legacy software that people want to use shits itself on the latest Windows version, yet somehow runs on WINE.
This is the way, for software like this that's stuck in time. I just recently helped my fiancee get a piece of old bioinformatics software running that wouldn't run on Windows 10. WINE on Ubuntu on WSL2 works fine.
It's a good story. But the things that make it a good story are also just plain wrong. At the end of the day it's software. It could be ran in a VM or even using windows compatibility layer. It could be decompiled and recompiled as a WASM web app. I also highly doubt the code for the voice engine is 4 million lines. The story calls the creator a genius, but really it's just a guy that had a passionate project. It's a good story, but anyone who doesn't think computers are magic can see right though it.
> It could be ran in a VM or even using windows compatibility layer.
The overwhelming majority of folks using this software seem to be extremely non-technical. Any of the options you listed would work for HN readers but not the general public. If it doesn't "just install" it's useless.
> The story calls the creator a genius, but really it's just a guy that had a passionate project.
Arguably, creating software that nobody else has managed to create that is beloved by its users is genius. He was clearly an exceptional engineer to have made the software and exceedingly business minded to get it into the hands of users and delight them. It's not hard to make mediocre software, but it's a terrific challenge to make it so good that your users are lost without it. You don't need to be in the running for the Turing award to be a genius.
A matching or best-effort decompilation would be quite slow and difficult to complete successfully, especially if the program was obfuscated. I'd think the source code is effectively lost, except if someone puts the time into recreating it off the binaries.
The code for the version of DECtalk that was used in TropeTrainer was released some time ago by one of the original developers as part of a project to preserve and revive DECtalk. The code can be found on the internet archive. https://archive.org/download/DTK_SRC/hebrew_mac_2016_09_04_l...
Even if they did, they couldn't publicly admit to it. To do so would be admitting copyright violations. The 'new' version does not seem to be sanctioned by any inheritors, and it deliberately capitalises on a name without a defender.
Whew boy -- the reminder of the Gell-Mann amnesia effect is powerful on this one.
I can't imagine it would not be more than a few minutes of downloading the image from archive.org and running it on any VM - I would be a bit surprised if this had any kind of sophisticated VM countermeasures in it.
Meanwhile, I can believe there is some 4 million line code of something (maybe it was written in assembly!) - in any case a horrible unmaintainable mess that nobody at this software company wants to deal with anymore. Rather just rewrite it in some web based shit like half of this site does for a living.
Also on actually reading TFA - it's rife with errors - at no point in history was the DECTalk the only game in town for speech synthesis - let alone 1999! - and the idea that it was the only one with controllable pitch is hogwash as anyone with a early 90s Mac can attest.
MacinTalk 3 (what you probably think of when you say early 90s Mac), i.e. voices like Fred, is technology closely related to DECTalk, and in fact the audio sample in the article sounds eerily close to a Fred-turned-orthodox.
But the article's description of how Siri synthesizes speech is grossly inaccurate.
Well, sure it's related (and MacinTalk is still builtin to modern macOS and iOS - you can use them for the system TTS voice). But DECTalk and MacinTalk weren't the only speech synthesizers available in 1999 by a long shot.
I had to chuckle about the genius of being able to program C and Lua as if typing English - I mean that's pretty much any reasonably proficient dev.
There is a lot of focus on the ... human aspects .. of the people in the story but in turn it makes some of them look really bad.
The quote about 4 million lines of code and how could they it would be impossible for them to share it because it is too large for email...
I think the program's creator was a great guy, doesn't seem like he was really thinking about his death seriously. His friends loved him and miss him but do not look to continue his legacy by helping the community.
The worst thing is that all the little dialects that were preserved by this are now at larger risk of being lost.
Hate religions all you want, but software like this is neat from a cultural/historical perspective and seemed to be an interesting solution to a community's problem. It also makes me wonder how we can use technology to save others that are rapidly dying like Native American languages and oral traditions.
Terry's work is remembered not really because it was exceptionally great but because it was just pretty odd in an interesting way. Plenty of people make hobby operating systems, custom programming languages, and more.
I found your comment hurtful and I'd urge you to delete your comment. Obviously trademarking someone else's program name is very unethical, but I don't think it's indicative of my ethnicity.
This is on quite a moving article about Jewish culture and doesn't warrant comments about Jews and business practices.
Implying the joke and not saying it explicitly doesn't make it any better.
Especially with all the passion and work Tom put into the program and his work with multiple Rabbi's to tweak in their slight changes and localized traditions. This feels more like much needed historical preservation that the community could have guided.
What a massive blunder of closed software.