This is how Apple addressed audio hardware and do something similar for speakers. Instead of trying to make speakers that have the desired frequency response or microphones that produce the desired signal, they let the analog hardware do whatever it does.
Then in software they use digital signal processing. For speakers they modify what gets sent to the hardware so that the actual output then does match the frequency response, and for the microphones they do this work to extract the desired signal.
If Linux addressed the speakers as is, you would get unpleasant sound, and if it read the microphones as is, it would get a lot of noise. That is why Asahi had to add digital signal processing to the audio input and output, to get the "correct" audio.
It does mean the processing is specific to the analogue audio hardware in each of the different Mac models.
The processing could be done in additional hardware, but why bother when you have a very good CPU that can do the work.
> For speakers they modify what gets sent to the hardware so that the actual output then does match the frequency response
As I understand, this is not a magic pill: it probably won't help to pull out frequencies which are suppressed by 30-40 dB and I assume that if the frequency response graph is too wavy (lot of narrow peaks and dips), it won't help either.
Also, you need to have calibration files to use this method, right?
Yes you need calibration files for supported models. You can see the details and explanation at the asahi audio repository. They also criticize the MacOS curves, and point out how some Windows vendors are doing the same DSP approach.
By the way I now realized that simply adding an equalizer before the amp might be not enough; speakers typically produce different sound in different directions, so for a perfect sound you need to somehow track location of the head and adjust filter curves.
SQLite has a session extension that can record changes on a local database into a changeset and you can replay those changes on another SQLite instance. Note that it replays what the changes were, not the queries that resulted in the changes. When applying changes you provide a conflict handler. (You can also invert changesets making a handy undo/redo feature.)
You can save conflicts to another changeset. There is also a rebaser to help deal with multiple way syncing.
there's also a CRDT version of this, which allows two databases to be sync'ed to each other in real time (aka, updates to one will eventually make it to the other, and both database would eventually contain the same data).
It's https://vlcn.io/docs/cr-sqlite/intro , and i find it amazing that this is doable in sqlite. It is perfect for small scale collaboration imho, but it also works to sync across local client and remote server (for a single db per user scenario).
Interesting link, it'd be great if their solution meets expectations.
Right now, the proof-of-concept they've provided seems simplistic. Their progress seems to have shifted from cr-sqlite into "Zero" instead. I'm guessing it has something to do with CRDTs being quite app-specific and hard to generalize.
I would want to see this library used in production first before hyping it
in a sense it is quite specific. In a difference sense, this is as generic a CRDT as you can get - it's CRDT on table(s). There's no merging of rows iirc (unless you write a custom merge, which is supported but probably need some tweaking and could lead to poor results?).
My sweet spot is working as a developer in a small team that has to do all the work to ship the product, using Python for practical and productive development, and as glue, C for performance and lower levels, and domain specific tools and languages when necessary.
Where I worked we got an early system as we made graphical desktops for workstations. IBM required that we have a separate locked room for the system!
Despite having over 20 different brands/Unix systems, AIX was the only one we had to pay a 3rd party consultant to come in and do installations and upgrades. That was back in the days of tapes. It used some convoluted volume management system where the tape contents got spooled into the disk and then the installation absorbed that.
smitty always felt so slow. There was a release where it was sped up. They didn't actually make it do the work any quicker - they just doubled the animation speed of the running man that was shown.
You can store your text and PDFs in SQLite (or their filenames) and use the FTS5 infrastructure to do tokenization, query execution, and ranking. You can write your own tokenizer in Python, as well as ranking functions. A pure Python tokenizer for HTML is included, as well as a pure Python implementation of BM25.
You can chain tokenizers so it is just a few lines of code to call pypdf's extract_text method, and then have the bundled UnicodeWords tokenizer properly extract tokens/words, and Simplify to do case folding and accent stripping if desired.
Thank you, your project meets my requirements. I want to build a long memory RAG system for my personal data. I like the commercial offerings like Google Gemini integrated with Workplace data, but I think I would be happier with my own system.
Thank you for publishing your work. Do you know of any similar projects with examples of custom tokenizers, e.g. for synonyms, snowball, but written in C?
The text is in UTF8 bytes so any C code would have to deal with that and mapping to Unicode codepoints, plus lots of other text processing so some kind of library would also be needed. I don't know of any.
My technique is to give an estimate with error bars. Something like 6 weeks plus or minus 2. That then leads into discussion as to what is unknown/undefined leading to the uncertainty. Sometimes the error bars are larger than the estimate because I know there will be endless feature creep and UI revisions for something like "analytics". And sometimes the number could be negative like 6 weeks plus or minus 8. That is when the functionality already exists (eg the data is already there - you can already load it into Excel and a pivot table) and could be sufficient.
At my very first job out of college,¹ the VP who led the division that I was part of invited me into his office (I think there was someone else from the team, but this is 34 years ago so who knows) and talked about a little game he had encountered about estimates. He gave us a list of 20 things to estimate with 95% confidence (the only one I remember was the weight of a 747), all given as a range. If we did it right, we would get 19 of the 20 correct. The point was to set the range large enough that you could be confident about the answer.
I kept that as a practice when I did freelancing work, always giving my estimates as a range rather than a single number. It would be nice if agile(ish) practices incorporated this in the estimation process.
⸻
1. Technically, my second job since I had a short temp job doing some cataloging work at a local used bookstore between leaving school and starting at that company.
I worked on X.Desktop at IXI. All the Unix workstation vendors (and I mean all of them) had us port X.Desktop to their Unix systems. We had over 20 varieties of Unix systems in our office including Sony workstations, IBM, HP, Motorola, Sun, DEC etc. X.Desktop ensured a workstation had a graphical desktop in multiple languages (English, French, German, Japanese), as there was no alternative except Looking Glass briefly. SCO bought IXI to ensure continued and expanded support for their platform. Over 95% of our business was on the RISC platforms, especially Sun workstations. The standard Motif source also had many bugs we fixed so that was an important part of the business. Other than OEM deals, a lot of our customer base was all the Wall Street companies, Government agencies, Oil Companies and others that used Unix workstations and applications.
CDE (Common Desktop Environment) was announced which cratered our sales for a while, but it took quite a bit before CDE shipped. In the meantime Microsoft Windows took off as an alternative to Unix workstations, and especially the release of Windows NT meant that the graphical software than ran on Unix moved to Windows, and the Unix workstation market came to an end.
IXI pivoted to software making Windows and Unix work together well, and then did Tarantella - a web based environment for interacting with graphical applications. SCO sold off its Unix business to Caldera (who sued IBM ...) and renamed itself Tarantella. Tarantella was later bought by Sun, and Sun was bought by Oracle. Oracle owns the X.Desktop source code. None of the source was used in later products.
Actually providing electricity consists of two parts. There is the fixed infrastructure of all the transmission lines, transformers, maintenance, and similar, plus the preparedness of generators to provide electricity on demand even when it isn't financially worthwhile. (The latter robustness was behind Texas' problems a few years ago.) Then there is the electricity you actually consume. They were all combined into one per kwh price that was adjusted every year or so by the regulator so the utilities got to cover the costs and get a 5% return on their "investments".
This is now an attempt to bill separately for those fixed costs versus the actual kwh costs. As an example someone with solar and battery completely covering their needs would have been paying $0 (there is more & fine print), despite all that fixed infrastructure being in place to provide all their needs without notice. Similarly homes with solar panels are pumping electricity back into the grid at times now when it is least needed. Commercial solar providers get curtailed and cannot do that. (See "duck curves" for more information.)
People using the least amount of electricity weren't paying much. People using the most electricity were getting solar, and weren't paying much towards that fixed infrastructure. Those in the middle were paying the most. This will in theory move more of the burden onto either side of the middle. Make your own mind up if that is fair.
But it gets worse. Most electricity in the state is provided via PG&E. You'll note they have been in the news over the last decade for various incidents such as exploding gas mains and neglecting maintenance leading to wildfires. That has been very expensive to address and rectify (many billions of dollars). Guess who is ultimately paying for all that? Hint: not the shareholders.
If you are offering consumer products, then you generally want to offer 3 tiers. It is conventionally known as good-better-best [1]. But you also have to be careful attaching your brand to all three because people don't want to pay best prices for good level product. If you visit the carrier websites they are targeting the better and best level. You'll note they don't list the acquired mvnos in their plans on their sites.
Those mvnos all competed on price and lowest product level. While it may not seem like it, it is expensive and time consuming to build a brand. Many fail. And many upper brands fail really badly when they try to build a low end brand.
The carriers are acquiring an established low brand:
* that has figured out how to do it and survived
* along with a bunch of customers
* that use your unused network capacity
* have retail locations and staffing (except Mint)
* have figured out how to distribute their product (eg other and own retail locations)
* have figured out how to acquire and retain customers
* have figured out how to provide customer service
They get to acquire all that without affecting their main brand. The people involved aren't idiots, and it turns out it does have great value. Billions in some cases!
Then in software they use digital signal processing. For speakers they modify what gets sent to the hardware so that the actual output then does match the frequency response, and for the microphones they do this work to extract the desired signal.
If Linux addressed the speakers as is, you would get unpleasant sound, and if it read the microphones as is, it would get a lot of noise. That is why Asahi had to add digital signal processing to the audio input and output, to get the "correct" audio.
It does mean the processing is specific to the analogue audio hardware in each of the different Mac models.
The processing could be done in additional hardware, but why bother when you have a very good CPU that can do the work.