There is no support for dynamic libraries in Cosmopolitan right now, so the libraries would either need to be compiled in (statically) or included in the archive as Python-only libraries. With the later ones, it should be a matter of adding them to the zip archive within the cosmo python executable, which should make them available to your scripts. See the discussion elsewhere in this thread (https://news.ycombinator.com/item?id=38102629) for some additional details.
It does indeed look interesting and looks to be similar to Lua in several aspects (although, there are some noticeable differences too). FWIW, there has been work done in eLua to keep some of the data (transparently) in ROM: https://eluaproject.net/doc/v0.9/en_arch_ltr.html (see rotables).
I don't think it's really that wrong-headed. What are the choices: (1) march ahead trying to salvage the current design with no clear path forward (other than waiting for the SSR solution), (2) quit right now, or (3) quit in 6-8 weeks if the proposed solution doesn't work (or is not delivered fast enough). The last option is not that bad if the author is hoping to figure it out, especially that the timeline is short and with a quick prototype (which the author did) it's going to be clear much sooner if the new approach is workable or not.
I've been using FAR for the last 20+ years on a daily basis and it hasn't crashed a single time for me. I like its minimalist UI, but a quite complex functions are only a click or two away and various plugins extend its functionality in useful ways (for example, Netbox for ftp access). I think it's a fantastically useful and robust tool.
And if you're running Far under ConEmu, copy ConEmu\Plugins\ConEmu folder into Far's Plugins folder. It will do better integration with ConEmu (there will be bunch of new ConEmu related features under F11 menu in Far).
I mostly use arclite, Brackets matching, Netbox (for FTP access), Process list, FarColorer and Temporary panel. I suspect most of them come bundled with Far.
> What the author is missing is the comparison with physical books, which never had this feature. You want to recommend the library get a book? You fill out the form they have. That process still works regardless of the format.
It doesn't. I used to be able to submit a request for printed and digital books, but my library stopped accepting those requests for digital books and (just as I commented elsewhere in this thread) now refers me to the Notify Me feature and Overdrive catalog (and if it's not in the catalog, I can't request it do be added).
> and if it's not in the catalog, I can't request it do be added
If its not in the catalog requesting it from the library isn't really doing anything for you but give you false hope of it appearing. Wouldn't you rather know your request isn't going to be fruitful ahead of time instead of thinking your request is doing something when its just going straight into the bin?
And, can you really blame the library from not wanting to have to maintain two lists of digital requests, especially since those digital requests will probably be delivered through Libby and requesting through Libby will actually notify you when its available, and let you know if its an actually requestable title?
Imagine going to a restaurant where they didn't have a menu you just asked the server for food and maybe eventually they'll show up sometime with food for you without ever telling you if they could even serve that dish. Somehow you'd prefer this model!
You are being facetious. Libraries used to be able to do this and this is exactly how it was working until relatively recently (I received a notification earlier this year as someone who submitted requests for digital books in the past).
> If its not in the catalog requesting it from the library isn't really doing anything for you but give you false hope of it appearing.
That's precisely the point. If it's not in the catalog, there has to be a way to request it to be added (assuming the publisher allows that), but right now there is no even a mechanism to do this, as there is no competition and the full control is on the Libby side to include or not include an item (without libraries having any say in it).
You're assuming the libraries ever had a say in what Overdrive's catalog was. I can't imagine they ever did.
Some libraries probably presented a UI suggesting they could do it as their own combined catalog probably wasn't synced to whatever Overdrive's library was. But you're then assuming your request for a book that wasn't in the Overdrive library actually got to the point of notifying Overdrive, which is yet to be shown either way.
I doubt it did anything more than have a librarian check if the book was in the Overdrive catalog, and if not they probably just closed the ticket. And right now this idea has just as much evidence as yours.
> it's a long rant against a feature change which is really just "I don't like this change in behavior". The search box likely changed to show results from only your library, instead of worldwide results, because it was confusing a lot of library patrons
> But this is just a UX change that the author doesn't like.
That's not the case. This removed the ability for me, a library patron, to request a digital title that I had before. I can still request a printed book to be added to the catalog, but for digital title our library FAQ states (which I presume is copied from OverDrive): If you’re looking for a specific digital title that we do not have, you can use a Notify Me tag in Libby. Notify Me will alert you if the library buys the title. However, not all publishers sell their content to libraries in digital format. If you cannot find a title in Libby’s catalog, then we cannot buy the item.
This looks like the control for digital purchases was removed from the libraries and moved to OverDrive/Libby, which is definitely not a simple UX change.
This doesn't serve my interests at all and, according to the article, doesn't serve the library interests either, as they don't have the information they had before about who requests what books and can't control the purchase process. It's also (according to the author) a sign of the (coming) platform changes for the worse, which I tend to agree with.
The article (and the local-first software) has nothing to do with cloud vs. on-prem. It's about the priorities in developing and running/using your applications: "The word “local” in the name refers to your personal computer. “First” means your computer is prioritized over “someone else’s.”". Local-first apps can still use cloud resources for synchronization or for simplifying their initial configuration, but it's not a focal and critical point of the design and only serves as one of the nodes and can be made optional. You can still get all the benefits of being cloud-enabled, but you're also getting all the benefits of working without any cloud involvement at the cost of adding synchronization and conflict-resolution mechanisms.
Agree; it also helps to write documentation supporting the example. On several occasions I ended up reworking APIs I'd been working on after writing documentation for them, as some of the elements were too complex, looked inconsistent, or just didn't feel right.
