Do you not think O'Reilly Associates fits some of that role? It seemed like Perl had more commercial backing compared to the other scripting languages if anything at that point. Python and JavaScript were picked up by Google, but later. Amazon was originally built out of Perl. Perl never converted its industry footprint into that kind of advocacy, I think some of that is also culture-driven.
Maybe until the 2001 O'Reilly layoffs. Tim hired Larry for about 5 years, but that was mostly working on the third edition of the Camel. A handful of other Perl luminaries worked there at the same time (Jon Orwant, Nat Torkington).
When I joined in 2002, there were only a couple of developers in general, and no one sponsored to work on or evangelize any specific technology full time. Sometimes I wonder if Sun had more paid people working on Tcl.
I don't mean to malign or sideline the work anyone at ORA or ActiveState did in those days. Certainly the latter did more work to make Perl a first-class language on Windows than anyone. Yet that's very different from a funded Python Software Foundation or Sun supporting Java or the entire web browser industry funding JavaScript or....
Thanks for detailed reply. Yes, the marketing budget for Java was unmatched, but to my eye they were in retreat towards the Enterprise datacentre by 2001. I don't think the Python foundation had launched until 2001. Amazon was migrating off Perl and Oracle. JavaScript only got interesting after Google maps/Wave I think, arguably the second browser wars start when Apple launches Safari, late 2002.
So, I guess the counterfactual line of enquiry ought to be why Perl didn't, or couldn't, or didn't want, to pivot towards stronger commercial backing, sooner.
> Pace and ambition of shipping has not only faded, that very culture is non existent. You don't see people building the next Facebook or Amazon these days, do you?
Do you not? The pace of anthropic/Claude tool development is pretty bonkers, AI hype reminds me of the 90s a lot.
(Author) Sorry you had a poor experience, yes my blog "engine" is a hacked together POS that barely works, with hand written CSS, that was mostly built before the mobile first era, I have just tweaked it to work somewhat on portrait phone screens, but it's really not a very good website. I do try to generate fairly plain semantic HTML so the pages should work pretty well with "reader mode" or user stylesheets if you have access to that. That's probably the optimal experience.
The platform always suffered from two big architectural missteps.
1 - the native browser being an old firefox/gecko fork embedded into their own UI framework, giving a poor performance and dated compatibility quirks
2 - the android emulating runtime meant that you get again, dated , poorly performing android apps, that you're driven towards because the browser engine was so poor.
these two mean you basically end up with a sub-standard android handset/UI, and a tiny market for native app development (because everyone made do with android), its a real chicken/egg.
In fairness I've not used it since the sony XPeria days, but it was my daily phone for 3-4 years since the Jolla 1. It was cool being able to emacs and irc natively on the phone, but that was limited in use cases tbh.
Same experience here, though from Sailfish OS run on their first Jolla phone.
Also permission model on Sailfish was much worse than on Android. I didn't use Android apps on Sailfish, though.
I really liked Silica UI, but available apps had much less functionality than their counterparts on Android and iOS. I think that open sourcing Sailfish and Silica would end up better for them.
Nevertheless, I kinda liked the phone, but ultimately went back to Android.
The Firefox engine legacy goes back to the Maemo times - its not ideal, but what else would you use ? The web engine situation is quite bleak even on desktop Linux distros and its even worse on mobile Linux.
My naive assumption is that WebKit would give a route towards blink and more mainstream compatibility. Gecko was a perfectly defensible choice in the Maemo era, the landscape just moved. That's my point, Jolla sailfish are coupled to old choices and don't have the resource to do much more than keep those maintained.
they did indeed have a crowdfunded tablet that went wrong in supply chain, and basically bankrupted the company. Many funders lost out. That's unfortunate, and perhaps might have been avoidable with better organisation. Absolutely it sucks. They did have a limited refund program as others have noted.
However, they do not have a continous history of not shipping. I personally owned their two previous phone handsets, both shipped. Also I've bought and run their firmwares on third party handsets, they also shipped the software.
Debian had binary packages with dependencies via dpkg from maybe 1994. Automatic recursive downloads, with apt (apt-get) were much later, around 1998. Rpm was launched in 1997.
It's hard to remember really, but automatic downloads would have been considered quite a misfeature by lots of user sites, in an era of intermittent, metered internet connections.
Didn't dselect in Debian deal with transitive dependencies (albeit through a tui rather than a cli) a couple of years before deity/apt came along?
As I recall, rpm could list dependencies but not automatically fetch them. Full apt-style recursive downloads weren't a thing until yum from Yellowdog (a PowerMac-specific clone of RedHat) and urpmi from Mandrake, both of which arrived in late 1999 or early 2000-ish.
RedHat eventually started using yum as well, but not until around 2002.
Certainly, in the late 90s, apt was king. Debian was struggling badly with their internal processes at the time, though, so they didn't benefit as much as they otherwise might have.
I think you're right about rpm and yum, actually, my memory failed me. (I was always a Debian user, so didn't have as much direct RedHat experience). I remember yum being really slow when it first arrived too.
I don't remember dselect _downloading_ dependencies, but it may have been capable of resolving the full graph - AFAIK .deb always included dependencies
