I paid for GPM for quite a while. I then started working at Google and beta tested YouTube Music from very early on and gave lots of feedback about how it sucked. When they shut down GPM I cancelled my YouTube Premium membership and installed an ad blocker. Not just YTM but so many things about YouTube were getting worse and worse and I couldn't find it in myself to keep paying for a service that kept removing features.
Yes, but in my experience it is pretty trash. Unlike Google Play Music which matched the music to known tracks and shuffled it in with recommended playlists and other features on YouTube Music the uploaded songs are basically completely isolated. At that point why use a streaming service?
What are you running MS-DOS? laughs in multi-tasking.
I just drag my vi terminals to another workspace and launch a new editor.
A few hundred a month is just a few per day. That is pretty low volume by most standards.
I would say in general if the SMTP server could be replaced by a single human writing and mailing snail-mail letters by hand it qualifies as low volume.
https://github.com/simplex-chat/simplex-chat/issues/444 suggests otherwise. Do you have any information about multi-device support.
This isn't how YouTube has streamed videos for many, many years.
Most video and live streams work by serving a sequence of small self-contained video files (often in the 1-5s range). Sometimes audio is also separate files (avoids duplication as you often use the same audio for all video qualities as well as enables audio-only streaming). This is done for a few reasons but primarily to allow quite seamless switching between quality levels on-the-fly.
Inserting ads in a stream like this is trivial. You just add a few ad chunks between the regular video chunks. The only real complication is that the ad needs to start at a chunk boundary. (And if you want it to be hard to detect you probably want the length of the ad to be a multiple of the regular chunk size). There is no re-encoding or other processing required at all. Just update the "playlist" (the list of chunks in the video) and the player will play the ad without knowing that it is "different" from the rest of the chunks.
That is a pretty weak argument. The issues are minor and in a library that people are moving off of to a better build and stronger validated library. Yes, it should have been like that in the first place, but the problem is minor and being addressed.
I would look more to the various features of Matrix that aren't encrypted like room names, topics, reactions, ... and not to mention the oodles of unencrypted metadata. I really wouldn't call Matrix a high-privacy system.
I like Matrix and use it regularly, but it definitely doesn't have a privacy-first mindset like Signal does. I'm hoping that this improves over time, but without a strong privacy first leadership it seems unlikely to happen.
Simplex doesn't support mutli-device. That's a deal breaker for me. I do 90% of my messaging at my desktop but also want to be able to chat on the go. Using my laptop on the couch is also fairly convenient.
Are you doing auth in the reverse proxy for Jellyfin? Do you use Chromecast or any non-web interface? If so I'm very interested how you got it to work.
The concern is that it would be nice if the UNIX users and LDAP is automatically in sync and managed from a version controlled source. I guess the answer is just build up a static LDAP database from my existing configs. It would be nice to have one authoritative system on the server but I guess as long as they are both built from one source of truth it shouldn't be an issue.
Yes, LDAP is a general tool. But many applications that I am interested in using it for user information. That is what I want to use it for. I'm not really interested in storing other data.
I think you are sort of missing the goal of the question. I have a bunch of self-hosted services like Jellyfin, qBittorrent, PhotoPrism, Metabase ... I want to avoid having to configure users in each one individually. I am considering LDAP because it is supported by many of these services. I'm not concerned about synchronizing UNIX users, I already have that solved. (If I need to move those to LDAP as well that can be considered, but isn't a goal).
I do use a reverse proxy but for various reasons you can't just block off some apps. For example if you want to play Jellyfin on a Chromecast or similar, or PhotoPrism if you want to use sharing links. Unfortunately these systems are designed around the built-in auth and you can't just slap a proxy in front.
I do use nginx with basic with in front of services where I can. I trust nginx much more than 10 different services with varying quality levels. But unfortunately not all services play well.
How are you configuring this? I checked for Jellyfin and their are third-party plugins which don't look too mature, but none of them seem to work with apps. qBittorrent doesn't support much (actually I may be able to put reverse-proxy auth in front... I'll look into that) and Metabase locks SSO behind a premium subscription.
IDK why but it does seem that LDAP is much more widely supported. Or am I missing some method to make it work
But the problem is that most self-hosted apps don't integrate well with these. For example qBittorrent, Jellyfin, Metabase and many other common self-hosted apps.
NixOS makes it very easy to declaratively configure servers. For example the users config to manage UNIX users: https://nixos.org/manual/nixos/stable/options#opt-users.users
Yet another service to maintain. If the server is crashing you can't log in, so you need backup UNIX users anyways.
I mean it is always better to have more open source. But the point of the multi-hop system is that you don't need to trust the server. Even if the server was open source:
- You wouldn't know that we are running an unmodified version.
- If you need to trust the server then someone could compel us to tap it or monitor it.
The open source client is enough to verify this and the security of the whole scheme.
LDAP to UNIX user proxy
Is there any service that will speak LDAP but just respond with the local UNIX users?
Right now I have good management for local UNIX users but every service wants to do its own auth. This means that it is a pain of remembering different passwords, configuring passwords on setting up a new service and whatnot.
I noticed that a lot of services support LDAP auth, but I don't want to make my UNIX user accounts depend on LDAP for simplicity. So I was wondering if there was some sort of shim that will talk the LDAP protocol but just do authentication against the regular user database (PAM).
The closest I have seen is the services.openldap.declarativeContents NixOS option which I can probably use by transforming my regular UNIX settings into an LDAP config at build time, but I was wondering if there was anything simpler.
(Related note: I really wish that services would let you specify the user via HTTP header, then I could just manage auth at the reverse-proxy without worrying about bugs in the service)
Why can't you return empties in downtown Toronto?
This is frustrating. I live in a small apartment and my nearest beer store is over 20min walk. I can get to at least 6 LCBOs in that time and dozens of grocery stores that sell alcohol. I'm not even the worst off..
Note that in the map posted the middle location is Yonge and Dundas which doesn't accept bottles. So if you live in the downtown core you can be walking 30min easy (each way).
You can see a map here, but which ones accept bottles or not aren't indicated until you click "show details". https://www.thebeerstore.ca/locations
How is this acceptable? I am forced to pay a deposit on every bottle but have nowhere to return them. Either I save up and haul a giant bag 20min or drive. Either way a waste of space in my apartment and I don't even drink that much.
It seems that we need a solution.
- Make LCBOs take bottles back. (or anywhere that sells alcohol, including Beer Store delivery)
- Remove the deposit and recommend recycling (sucks for bottles which are better washed and reused rather than crushed and reformed).
- At least make the Yonge and Dundas store accept empties. This would at least give options in downtown core that are less than 15min away. Still not great but closes a gaping hole.
Please recommend me some blogs about Linux or FOSS or similar that you follow through RSS.
Hi. I have a category Little Tech Blogs in my rss reader where I put those cool niche blogs mostly about Linux, FOSS, programming, etc… Many of them I found by articles linked in this community, so I was wondering if you guys know about more blogs like that. By little I mean it’s run by one person o...
Please recommend me some blogs about Linux or FOSS or similar that you follow through RSS.
Hi. I have a category Little Tech Blogs in my rss reader where I put those cool niche blogs mostly about Linux, FOSS, programming, etc… Many of them I found by articles linked in this community, so I was wondering if you guys know about more blogs like that. By little I mean it’s run by one person o...
What is your favorite terminal emulator.
I'm reconsidering my terminal emulator and was curious what everyone was using.
This is Fosstodon's official stance on the whole Facebook joining the Fediverse debacle.
Bisecting the Linux Kernel with NixOS
cross-posted from: https://beehaw.org/post/551377
> Recently my kernel started to panic every time I awoke my monitors from sleep. This seemed to be a regression; it worked one day, then I received a kernel upgrade from upstream, and the next time I was operating my machine it would crash when I came back to it.
>
> After being annoyed for a bit, I realized this was a great time to learn how to bisect the git kernel, find the problem, and either report it upstream, or, patch it out of my kernel! I thought this would be useful to someone else in the future, so here we are.
>
> Step #1: Clone the Kernel; I grabbed Linus' tree from https://github.com/torvalds/linux with git clone [email protected]:torvalds/linux.git
>
> Step #2: Start a bisect.
>
> If you're not familiar with a bisect, it's a process by which you tell git, "this commit was fine", and "this commit was broken", and it will help you test the commits in-between to find the one that introduced the problem.
>
> You start this by running git bisect start, and then you provide a tag or commit ID for the good and the bad kernel with git bisect good ... and git bisect bad ....
>
> I knew my issue didn't occur on the 5.15 kernel series, but did start with my NixOS upgrade to 6.1. But I didn't know precisely where, so I aimed a little broader... I figured an extra test or two would be better than missing the problem. 😬
>
> > git bisect start > git bisect good v5.15 > git bisect bad master >
>
> Step #3: Replace your kernel with that version
>
> In an ideal world, I would have been able to test this in a VM. But it was a graphics problem with my video card and connected monitors, so I went straight for testing this on my desktop to ensure it was easy to reproduce and accurate.
>
> Testing a mid-release kernel with NixOS is pretty easy! All you have to do is override your kernel package, and NixOS will handle building it for you... here's an example from my bisect:
>
> > boot.kernelPackages = pkgs.linuxPackagesFor (pkgs.linux_6_2.override { # (#4) make sure this matches the major version of the kernel as well > argsOverride = rec { > src = pkgs.fetchFromGitHub { > owner = "torvalds"; > repo = "linux"; > # (#1) -> put the bisect revision here > rev = "7484a5bc153e81a1740c06ce037fd55b7638335c"; > # (#2) -> clear the sha; run a build, get the sha, populate the sha > sha256 = "sha256-nr7CbJO6kQiJHJIh7vypDjmUJ5LA9v9VDz6ayzBh7nI="; > }; > dontStrip = true; > # (#3) `head Makefile` from the kernel and put the right version numbers here > version = "6.2.0"; > modDirVersion = "6.2.0-rc2"; > # (#4) `nixos-rebuild boot`, reboot, test. > }; > }); >
>
> Getting this defined requires a couple intermediate steps...
> Step #3.1 -- put the version that git bisect asked me to test in (#1)
> Step #3.2 -- clear out sha256
> Step #3.3 -- run a nixos-rebuild boot
> Step #3.4 -- grab the sha256 and put it into the sha256 field (#2)
> Step #3.5 -- make sure the major version matches at (#3) and (#4)
>
> Then run nixos-rebuild boot.
>
> Step #4: Test!
>
> Reboot into the new kernel, and test whatever is broken. For me I was able to set up a simple test protocol: xset dpms force off to blank my screens, wait 30 seconds, and then wake them. If my kernel panicked then it was a fail.
>
> Step #5: Repeat the bisect
>
> Go into the linux source tree and run git bisect good or git bisect bad depending on whether the test succeeded. Return to step #3.
>
> Step #6: Revert it!
>
> For my case, I eventually found a single commit that introduced the problem, and I was able to revert it from my local kernel. This involves leaving a kernel patch in my NixOS config like this:
>
> > boot.kernelPatches = [ > { patch = ./revert-bb2ff6c27b.patch; name = "revert-bb2ff6c27b"; } > ]; >
>
> This probably isn't the greatest long-term solution, but it gets my desktop stable and I'm happy with that for now.
>
> Profit!
>
>
SaaS RSS hosting
Simple and cheap cloud hosting for your RSS feeds and content. You can create or import RSS feed, edit it, add messages, get a download link for sharing and check statistics.
An introduction to RSS/Atom feeds and why they are so incredibly useful.
I started an RSS to Email Service
I know the Email isn't everyone's favourite RSS reader but it works really well for me. I wasn't happy with any of the existing services so I started my own.
https://feedmail.org is a low-cost RSS-to-Email service with nice clean templates. I'm happy to answer any questions.
Get updates from your favourite sites by email. The latest news, directly to your email.
This is a service I created to consume RSS feeds via email. This has been my preferred way to consume RSS for a while but I never found a service that I was really happy with and no self-hosted tool easy enough to manage.
So I created FeedMail mostly for myself but decided to share with others. I would appreciate feedback and any questions you have.