How does that work? You still need some program to actually play the music (mpv, Sotify, whatnot)? Or what am I misunderstanding? Unfortunately there are no details in the article, and an interwebz search doesn't really show anything.
https://www.phoronix.com/news/Linux-6.16-QCOM-USB-Audio-OLOA...
Audio usb offloading. Only supported on Qualcomm soc's.
Article is misleading. Audio offloading is probably only useful to avoid waking the main CPU too often, so better battery management... CPU can remain sleeping a few microseconds longer, not all the time.
Not something many will benefit.
Probably more the fact that the memory and battery management logic assumes all user apps which are not in focus can be killed aggressively, which makes the system unsuitable for any background task by design.
They are using BGP and routing nodes (backbones), recreating a mini IP (layer 3) network I think.
I've used raw wireguard in a p2p fashion to interconnect LANs. I run wireguard on each segment directly inside the network routers.
Just make sure all LANs are using a different subnet. A /24 is standard. Then configure all the peers and you get a fully peer to peer network. No relays. You only need one side of every peer "pair" to be reachable from the internet.
I do have a small management script to help peer discovery (dynamic IPs) and key exchange, but it's not strictly required. With a dozen nodes or so, it's maintainable manually. Wireguard supports roaming natively, as long as one peer can reach the other.
Very little overhead. ICMP, TCP and UDP support.
Out of interest, how do you run your migrations in production, deploy the service then run an ad-hoc job with the same container again? That was one thing I was never super happy with.
So new version can work with the previous version's DB schema.
Then, yes, simply run the migration in a transaction once the new code is deployed. Postgres has fully transactional DDL changes which helps.
Of course, it heavily depends on the actual change being made. Some changes will require downtime or must be avoided if it is too heavy on the db.
Another approach if the migration can be applied quickly is to just run the migrations as part of the deployment script. This will cause a downtime but can be short.
Easiest is just to do runmigrations in your docker image start commands, so DB is always migrated when the container starts.
tl;dr: It depends on the complexity of the migrations and your uptime requirements.
I use celery with the same code base/docker image. Just a different entry point to start a celery worker instead of a wsgi (web) worker.
Too many http requests? Add web worker instances.
Background jobs piling up? Add celery workers.
Clearly separate read endpoints from write/transactional endpoints and you can hit a slave postgres db or the master db depending on the http call.
This creates a very robust system that can scale easily from a single code base.
Thanks to the author for adding a very interesting readme.
I know this is for archiving and historical value, but I'm wondering what kind of license this work would/could fall under?
I see some files have copyright headers from probably long gone companies (upgrade.pas for example).
Also, the readme mentions the original documentation is not included but the src dir does contain a 98kb .HLP file, which I thought was more associated with early windows era software and not common for MS-DOS but someone might want to take a look
* The pricing tiers and included features by tier penalizes you in frustrating ways. The base plan is a reasonable $6/user/m, but if you want to use ACLs to control anything in a workable way, it jumps 3x to $18/u/m. Better solutions are available for that kind of money, and I shudder to imagine what the next tier ('call us') costs.
* Subnet routing broke on Ubuntu (maybe other distros) recently, and there were no alerts, communication from TS, or TS tools to pinpoint/figure out what was going on. I stumbled on a solution (install subnet router on a Windows box), and from there I searched and found others with that issue. Lost half a day in emergency mode over that!
* Better tooling to determine why it's falling back to DERP instead of direct for remote clients. DERP relays should be an absolute last resort to provide connectivity for Business-plan-level customers (very slow), and the way TS works just assumes any connectivity is fine.
Overall, the simplicity and abstraction of complex VPN networking is wonderful, but if you have issues or advanced needs, you are immediately thrust into the low-level UDP/NAT/STUN world you were trying to avoid. At that point, you're better off using a traditional VPN (WG, OpenVPN, or heaven forbid, IPSec), because it ends up being more straightforward (not easier) without the abstractions and easy-button stuff.
Tailscale touts all the perf benefits of the wireguard protocol but in practice between the userland wireguard that seems to be used all the time on all platform (even linux) and the over reliance on DERP, it has none of the performance benefits of the real thing.
8 bits is enough to represent the entire ascii char table, there must be some other limitation going on. QR code control chars maybe?
The linked "byte mode" table only has 45 individual chars. This could be represented with 6 bits with room to spare..
I'm not advocating in doing it for the exposure as a primary reason. And absolutely not to be paid in exposure. 100% agree with the comic there.
I should not have used that word. It is clearly charged with negativity.
Of course I wish everyone would be compensated for their work. I feel that for some types of project, publishing as open source is a great way for people to find and use it. This can give new opportunities.
Exactly which kind of project and under which conditions is up to debate.
I have worked on a few projects that I regret not being able to open source. Mainly not my choice, stakeholders wanted traditional go to market strategies and failed/ran out of money trying to make sales. I can't help but thinking what other opportunities could have arisen have we chose another strategy.