This makes me think of QGIS. I've recently been learning it for a couple different projects. It's an incredibly powerful and configurable tool, but its learning curve is incredibly steep. A big reason for this is that the UI is almost entirely toolbar+button based -- but the meaning of all of the button icons are completely opaque to a new user. And, making things worse, there's no way to change the UI to show text next to buttons. So every time a user wants to do something, even if following instructions that say "click the add feature button", they have to hunt around for it.
QGIS is free software, so it can be somewhat excused vs a billion dollar company. But they could really benefit from some UX expertise...
Other than phones and laptops (i.e. "real computers"), most devices only support 2.4, no? I can't recall the last time I set up a non-computer device that didn't say "make sure you're using a 2.4GHz network"...
(I imagine it's a much lower cost to only handle 2.4GHz?)
I was curious so checked my network. I've got 21 things on 2.4 and 16 things on 5.
The 16 are 4 computers (2 Macs, a Surface Pro 4, and an RPi 4), 3 mobile devices (iPhone, iPad, Apple Watch), 3 media devices (Fire TV, Nintendo Switch, and Kindle Oasis), one smart plug, a Brother printer, 3 smart speakers (Google Home Mini, two Echos), and an EV charger.
If only calling "representatives" still worked nowadays in the age of blatant corporate lobbying... it's really hard not to completely despair, because is there _anything_ we peons can do?
(I used to call my senators and house reps about things, but it never got more than a polite "thanks, but I don't care" and now they don't even bother to reply at all)
Have you posted any writeups or other information about how you built this? I'm eyeing a Mazda as a next car (I've never owned a car newer than a 2014, and outside of that one, any newer than 2006, but family safety needs may lead to getting a newer car soon), and telemetry seems like one of the few downsides to an otherwise good carmaker. Would be very interested to learn more!
> (I've never owned a car newer than a 2014, and outside of that one, any newer than 2006, but family safety needs may lead to getting a newer car soon)
I don't know much about automotive safety, but has much actually changed since 2014 in terms of safety standards? I had thought that by the 2010s, basically everyone big had already figured out how to build a relatively safe car from a structural standpoint. Or are you only talking about electronic assistive features, like proximity sensors or lane assist?
It's amusing that changing the altitude scale doesn't reset the "trails" -- when I dragged it around quickly (on mobile) it left vertical streaks behind all the in-flight planes
I've used [Keycloak](https://www.keycloak.org/) in the past for "open-source Auth0" -- though I'm not sure it has ever described itself that way.
Keycloak ended up being quite extensible and powerful, but the UI and data model both sometimes made things more difficult than they had to be... this could be an interesting project to look at.
One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh
> One bonus (for us) for Keycloak was that it was JVM-based, meaning it was easier to integrate our existing JVM libraries. Though its use of Hibernate was frustrating at times, heh
I'm pretty frightened of running Java services, not because of the JVM, but because every Java app I've had to operate is infinitely configurable via some poorly documented XML file, and trying to reverse engineer the XML file is often difficult because you have to route through a bunch of Spring Boot magic (preventing an easy grep for configuration options). And on top of that the defaults are rarely system defaults, so even figuring out _where_ the application expects to find its configuration file is nontrivial and logging by default is separated into some unknown number of log streams which each go to a completely different path on disk by default and each one has its own configuration option for telling it to log to stderr.
By contrast, Go services are pretty explicit about where they expect their configuration, they usually log to stderr by default, you can pretty much drop them into any Docker image and run them without issue (no need to custom tune the JVM or bundle up dependencies and ensure the right runtime version). I'm told that the Java world is changing, but in the mean time I will put up with _a lot_ in the way of missing features in order to avoid running a Java application.
The nice thing about the Java base here was that instead of trying to solve problems with a mess of configuration, we could just write our own code plugging directly into / replacing parts of Keycloak. Definitely don't disagree with you about the pain of XML, but that wasn't an issue for us here at all
Yeah, I fully believe that there are advantages for your team, and even that Keycloak is much better than the Java apps I have had to operate. I'm just traumatized. :)
Tbh, I much prefer ORY's API first approach. I looked into Keycloak when I was trying to have a multi-purpose auth server that allowed me to peek into the auth flows.
The sheer complexity of Keycloak's configuration and deployment vs. something like ORY's Hydra was night and day.
And the fact that I could intercept the auth flow through a callback and use their RESTful API to drive it was amazing. No more "package this JAR" and hope that it works. Hydra would run on its own and I don't have to touch it, except when I have to upgrade it.
Yea part of the motivation to create Ory Kratos was that Keycloak was too clunky and cumbersome for us to use, also hard to scale and a bunch of other issues - so we wrote our own basically.
Oh, I wanted to escape the Kratos hell by migrating to Keycloak and you say Kratos was created to actually be a better alternative? Well I have to say I had a very hard time implementing browser flows, configuration is a mess, not everything working through yaml configs works as env var. Documentation is a mess. All in all, it took months what should have been weeks at most. Sorry for the negativity, but it is one of the software pieces I really wish I have avoided.
sorry to hear that, hope you have a better experience going forward.
if you feel like it send me some details on what was most painful and we'll fix it.
Just from looking right now, I'm a bit puzzled by being told right away that it has all open APIs in a warning in the install guide. Would I really want to tell someone to try starting something for our security that is an immediate attack vector?
Since docker/k8s I've started to encounter containers that just start with a default user and no password. The Cuckoo's Egg was published in 1989. Choose a random password if you don't have one and print it to the console.
I'm very familiar with Keycloak, and I don't see this replacing it any time soon. As soon as I read:
>
The Ory Enterprise License (OEL) layers on top of self-hosted Kratos and provides:
Additional enterprise features that are not available in the open source version such as SCIM, SAML, organization login ("SSO"), CAPTCHAs and more
I knew it couldn't compete. Good luck to this product.
You can use other parts of the Ory ecosystem to add these features, such as Ory Polis for SAML/SCIM support: https://github.com/ory/polis
CAPTCHAs aren’t a big help anymore in my personal opinion, but you can easily integrate them on the frontend when using Kratos. The commercial offering just bundles all of this out of the box for you.
If Keycloak fits your needs well and you see no room for improvement, that’s perfectly fine; by all means use what works best for you.
This is a nightmare for security for companies that aren't big enough to pay the tax - which is most companies.
Every product, every fucking product, if it does anything, should have RBAC and SSO. These are the bare minimum. You want to hold off on SCIM for large customers, fine. Do that.
These are fair concerns, and I want to clarify what's included versus what's paid.
The confusion here is about two different types of SSO:
_Admin SSO (for managing Ory itself)_ - Ory is fundamentally an API. For self-hosted deployments, you control access however you want - through your infrastructure, reverse proxy, or using Ory Polis. This is not gated.
_Organizations SSO (for your end users)_ - This is the paid feature. It allows your B2B customers to bring their own identity provider. If you're building a SaaS product and BigCorp wants their employees to authenticate using Okta or Azure AD, Organizations handles that federation.
The distinction matters because maintaining integrations with enterprise IDPs is continuous work.
For example Google randomly changes their OIDC implementation on a Saturday evening. Someone needs to wake up and fix that. For products serving other businesses at scale, that operational burden is real.
Organizations is one of the few areas where we charge, specifically targeting the B2B SaaS use case. If you're self-hosting for internal use or building a consumer product, you don't need Organizations.
If you're selling to enterprises that require SSO, you're generating revenue to support the cost.
If every plan is not getting access to at least SSO / RBAC, you are contributing to a weaker security ecosystem that disproportionately impacts non-Enterprise organizations (most organizations).
Hmm, good to know. But given Google's history, I assumed that it would stop working.
I also need to sell my Google Chromecast with Google TV 4K. Brand new, still in its shrink wrap. Bought it last year, to replace a flaky Roku. It was a flaky HDMI cable instead. I trust Roku more than Google for hardware support.
In absolutely shocking news, it did stop working and then Google went out of their way to fix it.
I genuinely thought all the chromecast audios I owned were useless bricks and was looking around for replacements and then they just started working again from an OTA update. Astounding. I assume someone got fired for taking time away from making search worse to do this.
This isn't exactly what you're looking for, but it may fit the use case.
I've recently been replacing some of the wiring in my house as part of a renovation, and I discovered that Leviton sells outlets with PD USB-C built in now! Not talking about the useless 2A USB-A "built-in" chargers of yore, now they actually have proper PD up to 60W!
They do also sell non-PD, so it requires some careful checking of the model numbers. And the 60W one is pretty large (the in-wall part) so it might not quite fit in an existing wallbox if it is a small one. But briefly:
- T5636: two USB-C PD, up to 60W total / 60W individual or 30W each if both in use
- T5635: two USB-C PD, up to 30W total / 30W individual or 15W each for both
- T5634: one USB-C PD and one USB-A. USB-A is 10W and USB-C is up to 50W (even if both are in use)
They also make T8xx versions of these that have 20A receptacles (NEMA 5-20R) but those are harder to find.
They also make other T56xx/T58xx which have non-PD USB-C, good for places like bathrooms where shavers/etc work fine on 5V.
I've found that putting a few of these around has eliminated a lot of the Anker chargers I used to have sticking out everywhere. They're completely in-wall and they leave both outlets free. If I need 100W for my computer, I'll still use a separate charger, but otherwise these are fine.
The only point they don't hit on your list is the ports facing down, but because they're flush at the wall, that means they don't interfere with furniture (any more than having any plug plugged into the outlets at all would).
If you're in Europe/elsewhere, not sure if other manufacturers make similar devices. I know Legrand makes some 30W PD ones in the US market, and as they're French, maybe they make them for others as well.
I might use these in my basement remodel since I can easily install deeper boxes. A right angle connector cable would also solve the issue of the port direction.
I'm still not totally sure why these names were deprecated in the first place...
I mean, the folks who run the tz db definitely know what they're doing, it just never 100% clicked with my thinking.
I always prefer `US/Eastern` over `America/New_York` -- it seems more "canonical" to me. New York is _currently_ the anchor city for ET, but will it always be? The place I live (Boston) is currently on ET, but in the future it might be on Atlantic Time. If there was an `America/Boston`, I would use that to be safe, but since there isn't, it just seems better to be to be specific that I mean "Eastern Time" and not "whatever the time is in NYC"... At least then if Boston switches to a different tz, I could intentionally switch to "Atlantic Time" -- doesn't that make more sense? Versus I guess what I'd have to do, which is switch to `America/Puerto_Rico`? (I had to actually search that one, too bad there's no `US/Atlantic`...)
> the folks who run the tz db definitely know what they're doing
It's one guy. He demonstrably does NOT know what he's doing.
> I always prefer `US/Eastern`
As you should. It's the actual name of the timezone as published by the entity that defines it. Outside of the goofy definitions in the tz file it's what everyone living _inside_ of that timezone would call it and see it referenced as.
To call this "backwards" is an absolute insult to civil time keeping and drives me insane.
> doesn't that make more sense?
I always thought it should be served through DNS. Then each country can just define it's own TZ record type and embed it at the root of their country code domain and could expand on it however they like.
eastern.timezone.us
Also, since domain names have punycode for internationalization, you could actually call timezones in countries like Mexico what they're actually named for end users.
If New-York shifts its timezone, then it will still be New-York and America. And the new tzdata will reflect that shift so your data will always be correct (as in reflecting the time it is in new york). For local time, you will switch to a new city and the date will still be correct.
Exactly, but that is my point: usually my data is not intended to reflect the time it is in New York. Being tied to a (semi-)arbitrary city changes the actual meaning of the zone slightly. If every city was represented and I could choose "Boston" then that would make sense (for data is intended to reflect the time it is in Boston) but of course that's not entirely practical.
(I'll note that I agree with the general wisdom to store data in UTC; here when I talk about zones I'm either talking about user local machine time or display)
FWIW if Boston switches, it won’t be America/Puerto_Rico, it’ll get a new zone name (probably America/Boston). Tzdb zones express that everywhere in that zone has always been on the same time, since the advent of standard timekeeping, so they always fracture when some subset moves to a different zone.
QGIS is free software, so it can be somewhat excused vs a billion dollar company. But they could really benefit from some UX expertise...
reply