I think tailscale supports exactly that? You give them your email address and they check the web finger endpoint of the domain for your configured SSO provider. https://tailscale.com/kb/1240/sso-custom-oidc
I would assume that limitation is because it's on the roadmap, but they want a different UI for it, or more control, or to see how beta goes with just your own devices, give some time to think about how it should work, etc.
Because they've had to specifically put that limitation in place, no way they don't realise it could be useful.
> There's a single implementation as far as I know
That's exactly what I mean.
Systemd itself, including timers, is deeply coupled with the Linux API, and cannot be (easily) ported on any other system. Cron, on the other hand, exists on almost every UNIX-like system.
systemd is is many things, but obvious and accessible is not one of them. It has a lot of power and flexibility, but the trade off is a lot of complexity. Just look at the unit configuration file:
I have no idea from that documentation how I'd run something every hour. I guess I have to create a new unit file, and use the OnCalendar stanza? But what do I set it to? I'm directed to this page:
I started my career as a Unix SA over 25 years ago and have worked with a lot of different Unix-flavored operating systems: SunOS/Solaris, HP/UX, FreeBSD, Linux (Slackware, RedHat, Debian), macOS/OS X, AIX. I'm familiar with all their different variations of init.
All of them are esoteric in one way or another. Some of them have their behavior right out in the open where it's easy to see (inittab and rc scripts). Others hide away massive complexity (launchd and systemd) and require extensive documentation to understand.
I appreciate all the power that systemd provides. It gets a lot of things right. But in terms of complexity, it's almost an operating system unto itself.
I'm not quite sure why you felt pressed to write this long-winded response to something I didn't write. I never said that systemd is easy. I said that if someone is running *BSD, today, in 2024, they'll cope with cron's syntax.
I'll still reply to one part:
> Oh, I see I can use "hourly" but it turns out that's syntactic sugar for:
> *-*-* *:00:00
>Is that really any easier than the cron equivalent?
> 0 * * * *
...Yes? Ask someone who's not familiar either with cron or systemd to guess what each one mean, with the context that it's supposed to be something related to dates and times. If you're vaguely familiar with how dates are usually written down, and that a star is a wildcard, you can immediately guess that the first one means "any year, any month, any day, any hour, at the first minute, first second". The cron one? It's anyone's guess.
Hah, that's fair. I inferred from your comment the corollary that systemd is not arcane, and thought "oh, it's just arcane differently," hence my long-winded reply.
You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.
I’d argue that the degree of portability implied by the term is very much context dependent. “Portable between Linux systems” is a perfectly valid use of the term, imo.
Do you take portable to mean a program that can run on every processor arch and OS available?
> Do you take portable to mean a program that can run on every processor arch and OS available?
The definition of the word "portable" is not the point of this comment thread (although if you want to hear my definition, see the reply to a sibling comment).
Let's take the context into account:
> hashworks:
While I support systemd timers over cron, AFAIK cron has stuff like @hourly.
> caiusdurling:
Some cron implementations do, it's not portable.
> bheadmaster:
Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.
User caiusdurling said @hourly is not portable between cron implementations as a way to discredit hashworks' argument about cron having @hourly.
However, that's a disingenious argument, because systemd timers aren't any more portable than cron implementations that use @hourly - in fact, there isn't a single system out there implementing the systemd timer interface except systemd.
Portable means easy to make it work while changing the underlying system or its implementation details - where the underlying system refers to architecture, OS, API or any other dependencies needed to run the program.
In context of systemd, systemd isn't portable because it highly depends on Linux API and thus cannot be ported on any other UNIX-like (or unlike) OS.
In context of systemd timers, systemd timers aren't portable because there isn't as single alternative implementation that can interpret systemd timer unit files.
You certainly don't need a full on Keycloak installation here, if you don't want to go that far. There's various OIDC providers, some more complex than others!
If you already have LDAP or some other backing auth, setting up Dex for OIDC is pretty easy. Took me less than an hour or so.
If you want something fancier Authelia isn't too bad, I got that running in an evening and hooking it up to Tailscale took another hour or two. Most of that spent figuring out how I want to do webfinger.
2. I set up Webfinger first, so assuming you're setting it up from scratch you can either run a Webfinger server yourself, or just configure the paths in whatever web server you have for your base domain. I didn't feel like running Yet Another Server and since the Tailnet's only for me I just plugged the following section into Caddy:
Where webfinger.json is file containing the response tailscale is looking for from their doc. You can verify it works right at https://webfinger.net/lookup/ .
I guess I'm doing overkill then. I actually use Keycloak for Tailscale. It also serves as authentication for my Nextcloud and Mastodon instances, so maybe slightly less overkill.
Actions like this will just hurt Wayland in the long run. It needs more users, and for that more applications that support it by default. No one will bring X11 to the level of Wayland, but someone might fix the existing Wayland problems.
X11 today works better for more users than Wayland. No user will want to switch to something that provides a worse experience.
Until these issues are ironed out, it's delusional to think that making Wayland the default will make users happy. Keep it as an experimental feature, and once it provides an objectively better experience for everyone, make it the default.
These technical discussions by folks in the trenches often miss the forest for the trees. Users don't care that X11 is difficult to support, develop and maintain. They just want a working system. By the looks of it from this GH issue, Wayland is also a pain for developers. What a sad state of affairs for Linux.
I guess I'm just hoping for some user that will be bugged enough by problems in Wayland that they decide to fix them. The chance of that increases with user count.
I understand that the bulk "forest" of Linux users don't care about their window manager / desktop environment, but it's a higher number than in other operating systems. This approach wouldn't work in Windows or MacOS, in Linux it might.
Why learn about wayland and figure out how to fix things (and then probably have gnome developers never ever accept your fix) when you can just switch to Xorg in 3 seconds?
Because nobody maintains Xorg anymore. Wayland was started because the Xorg developers thought Xorg had come to the end of the road and was unfixable. You can think of Wayland as X12, except without copyright/trademark concerns.
Sure, X11 "better", as long as you don't have high or mixed DPI screens, appreciate variable refresh rates, arbitrary scale factors, don't mind inconsistent tearing, aren't bothered by using a openly unmaintained, abandoned critical piece of desktop infra, etc.
Otoh, if you're willing to buy a GPU from a vendor that doesn't snub Linux, or maybe god forbid change screenshot programs (doubt you even need to nowadays), you get plenty of benefits with Wayland.
Edit: athe kind of person that downvotes comments like this are some of the least respectable, laughable, on the planet. Shove your fingers in your ears harder and make that tantrum louder. I'm sure it will convince X11 devs to abandon Wayland and return to the project they declared on life support, yup. That's how these things work.
The “oh, just don’t buy a GPU from NVidia” point is one I see made a lot when discussing Wayland’s failures, but it completely misses the fact that CUDA is currently the only viable option for GPU compute in many situations. If any significant part of your desktop usage involves such compute, that’s not a solution - or rather it’s a solution that renders your system less capable than it was before.
Though in a sense that’s consistent with Wayland’s general “you’re holding it wrong” approach of shifting blame for any problems onto the person reporting them and concluding that anything that doesn’t work well isn’t a valid use-case anyway.
> Sure, X11 "better", as long as you don't have high or mixed DPI screens, appreciate variable refresh rates ...
Tell that to the PCSX2 users who experience issues on Wayland, but not on Xorg.
This is what I mean by missing the forest for the trees. There's no doubt that Wayland is technically superior to Xorg in many ways. But technical superiority means squat if applications are misbehaving and crashing. While developers are arguing about who should be in charge of window placement (FFS, how is _this_ still a discussion after *15 years*!?), the only thing users get is a poor experience.
> Shove your fingers in your ears harder and make that tantrum louder.
I didn't downvote you, but maybe you should follow your own advice and realize that Wayland does not work great for everyone. Your type of dismissals are the equivalent of "works on my machine".
Not sure it will do anything to hurt Wayland. The app will just run in XWayland which is mostly impossible to tell between a native Wayland app for users.
I might not be up to date on this, but does fractional scaling work at all on Linux under any setup? Last I checked GTK just flat out didn't support it or something.
KDE supports fractional scaling. GTK doesn't and as a result neither does GNOME. There's hacks in gnome to work around this by faking it with downscaled integer scaling (render at 2x, squash into 1.5x) but it never provided a good experience for me.
In the example there are no concrete path, both have variables. Is there an example in the documentation that allows paths with variables precedence over concrete paths?
This was also about 8 years ago. It was originally a RAID1 setup, but I did an in-place converter to RAID6, which is cool. And like I said, I didn't lose any data.
With mdadm, I don't get auto-repair on top of the checksumming.
