mmerickel

This level of entitlement is the reason that FOSS has a maintenance / support epidemic. Maintainers don't owe you anything. They put the work in, not you.

Connect on your phone or other device. Connect to travel router. Clone the mac address of your device. Connect router to wifi. Adjust device to not auto login. Good to go.

This is just flat-out untrue, OIDC or SAML plus SCIM should be the default for any enterprise-focused service provider or "you're doing it wrong". You can offer your own IDP as the default, but all of the problems that need to be solved to allow your customers to configure their own IDP are important to the design/architecture of your service and the only reason these providers are treating it as special is because they didn't build the integration between their service and their IDP correctly the first time. Provisioning and authentication are critical to security and you're actively harming your customers if you require them to use your own IDP solution in order to use your service.

It's really fun when your ISP starts using CG-NAT as a security feature in marketing. You ask them for a static IP and they have you sign an agreement that you won't be getting the BENEFITS of their CUSTOMER FIREWALL. Yeah ok, so if that's the language around this then we're just screwed aren't we? And you also can't tell me when you're planning to support IPv6 of course.

Remember even if timestamps may be generated using a monotonically increasing value that does not mean they were committed in the same order to the database. It is an entirely separate problem if you are trying to actually determine what rows are "new" versus "previously seen" for things like cursor-based APIs and background job processing. This problem exists even with things like a serial/autoincrement primary key.

I'm a huge proponent of using SQLite as an abstraction over a filesystem. One warning I will note though, is be aware that a SQLite database does not shrink unless you vacuum it (basically copies the data into a separate file and deletes the original). This is a manual operation you have to do at points where it makes sense within your application. So be careful with disk usage when just writing binary data and then deleting it.

SQLAlchemy and your efforts are so amazing and appreciated. Thank you and the team for all of your hard work on 2.0 as well as the heroic effort that was put into 1.4 as a stepping stone for existing codebases!

To be fair they are quite up front when you stake Ethereum that you cannot withdraw it before the network itself supports it... Hope they re-activate your account though!

That's for using macOS input devices to control iPadOS. I was interested in using something on my phone to control my mac. From what I can tell "Switch Control" is probably it, but it looks pretty tricky to setup so far!

Is there anything like this on iOS for controlling macOS?

I have plenty of shortcuts that work on iOS but don't work on macOS. It's fun when you use siri on the mac and it tells you it can't do something halfway through.

The promise of thread versus reality I feel will be a big problem - I'd love to be wrong though. I'm on the outside of things (haven't used thread, only read about it... use zigbee a lot though). But the way I understand it is that once you join a device to a particular bridge you will still need to use that bridge's ecosystem to communicate - even though the device has its own IP address. For example, when a thread device joins to homekit and establishes an encrypted handshake, it's not like I'll be able to use that device's IP address to talk to it. It's not going to trust me - only homekit. But at least it'll be able to talk to any homekit bridge on the network and avoid a SPOF if I unplug one of my homepod minis.

There's an open issue to try to enable it - Gitlab issues a unique JWT to every pipeline but it's not directly consumable by AWS right now so you'd have to write an intermediate service that could convert the gitlab token into an AWS session: https://gitlab.com/gitlab-org/gitlab/-/issues/216259#note_44...

My project, hupper [1], isn't hot reloading but it's worth mentioning in this thread alongside other code reloaders. It is a general purpose tool to monitor python code and reload the process when code changes. You can use it with any script that you're working on via `hupper -m foo` and your `foo.py` is then reloaded/re-executed everytime you change it. It's used under the hood in other tools to implement things like `pserve --reload` in Pyramid and is used in Warehouse (the codebase for PyPI) to ease development workflows.

It's an improvement on some previous attempts at the solution that would crash when reloading invalid code. Hupper does not have this problem due to its multi process design.

[1] https://docs.pylonsproject.org/projects/hupper/en/latest/

Quite a few of these packages have undergone significant backward-incompatible changes over the years and are intertwined with specific version ranges of other packages. The churn complaints are caused by the cadence of this happening and how difficult it is to stay on a combination of stuff that actually works together. Babel may have been released in 2015 but nothing written back then would work in babel today. Same with webpack. I can't write something and then come back in a year and expect even an ounce of stability in my project. It's good that things keep improving but it's also exhausting having so much time spent performing upgrades and re-learning best practices in tools you were previously comfortable with.

It seems like something could be written around useRecoilCallback() to watch/get the current value of an atom outside of a React component. Does that sound right?

Is there any support for changing multiple atoms at once / batch? This is where reducers shine to me - dispatching a single action from the ui in redux that multiple reducers can listen to and use to update their state.

Also is there any support for getting the values of atoms outside of a hook? For example from an async action that is not coupled to the render loop which also wants to know the current value.

The distinction is whether the resource is owned by another tenant or not. Often a user can view a resource but aren't allowed to edit it, at which point 403 is correct. However if it's something owned by another tenant entirely, and is not public, then a 404 is correct.

Yep, until we eventually move everything into `pyproject.toml` which is explicitly documented to support `[tool.foo]` config namespaces.

https://www.python.org/dev/peps/pep-0518/

I'll take a chance to plug `vrun` https://pypi.org/project/vrun/ here as well which is a very lightweight wrapper around activate that only applies to the current command. You can use it to start a subshell if you wish.

The fundamental problem is that virtualenv scripts are not actually bound to their actual virtualenv. If you forget to activate and a script shells out in a subprocess to execute another script it will not find the version installed into the virtualenv. This should be fixed upstream but so far it doesn't look like it is.

    $ python3 -m venv env
    $ env/bin/pip install vrun
    $ env/bin/pip install foo # assume foo depends on bar and tries to start bar via subprocess
    $ env/bin/foo # fails because bar is not on the path
    $ env/bin/vrun foo  # works

`foo` is now executed in a process in which the virtualenv is fully activated and will find appropriate dependencies on the path if it tries to run a subprocess, etc.

If you want readonly access using dot notation instead of keys then I have a simple gist [1] I use that works well for tracking nested dicts - even nested inside lists. It's a good way to pass a dict into a function expecting an object in some scenarios.

[1] https://gist.github.com/mmerickel/ff4c6faf867d72c1f19c

If you install the client there is an "i" info button in the upper right of chat that allows you to add participants.

> And the developers seem to think this is totally ok.

To be clear the core maintainer-ship of pyramid is about 2-3 people. We would love more contributors to the core codebase, but with that level of commitment we're obviously not able to provide a comparable level of support to a project with more contributors. This is the nature of open source and it is the rare exception to the rule to find packages / projects that have grown to be able to offer such a level of support.

2010 was a major transition for pyramid as it was re-branded from repoze.bfg and merged with the pylons project.

This is awesome. I ran it on pyramid for fun. http://imgur.com/a/KZ9KR

The fundamental issue is that you should not be exposing the encryption keys to the database. If you're using pgcrypto then you're issuing SQL statements in the database with the key. You should do your encryption client-side so that the key is never passed over the wire at all.

After listening to the call it does seem like Apple didn't do due diligence and notify all parties involved. They notified the owner of the dev account, but not the owner of each account that was going to be deactivated. Doing this could have prevented the misunderstanding.

I believe a channel can only have one receiver and one sender, no? So you can't share the channel between multiple workers.

That depends on a lot of factors. The advantage of an approach like this is that every package is built in a clean-room container independent of the host. For example my host is os x and I'm building binary tarballs to run on ubuntu. If you have a build server obviously this is less of an issue.

The idea is actually to do something similar to a heroku buildpack where you have a container with build tools that generates binary assets. You then inject the built binary into a new image that has only runtime dependencies installed.

I've experimented (and use) a variant of this workflow myself built around my marina tool [1]. The basic idea is to define a file that uses a dev/builder image to build, then exports a tarball into a runner image.

[1] https://pypi.python.org/pypi/marina