Ubiquity only did passive PoE in the very early days. Everything has been 802.11 variants for a long while wow. The injectors that shipped a decade ago with my APs were all 802.11af.
What about MiniPCs that support serial console or network connectivity for BIOS / UEFI access? When I looked for a new router, I couldn't find any of the usual "cheap" suspects that supported that. As well, most didn't have anything better than 1 GBit network ports.
I ended up going with a more expensive mini-PC style vendor, but I was surprised there didn't seem to be a ton of competitors.
I was a paying Pocket customer until a few weeks ago. I switched to Wallabag plus https://gitlab.com/anarcat/wallabako/ to sync to my Kobo. It's not polished, but honestly neither was Pocket with their decline in both article parsing and the iOS apps over the last few years.
Hopefully this situation encourages more contribution and improvement to tools like these.
Worse yet is when banks tie authentication notifications to the ability to send you marketing and advertising permissions. My bank's app was sending me weekly marketing messages, and the only way to stop that was to go back to SMS 2FA.
I wish Apple (and Google, I presume) would actually enforce their app store guidelines and at least threaten to ban apps that do this. That seems like the only thing that'd actually have traction.
Are there any ways to do some sort of upscaling for HiDPI displays? I’ve always wondered what MacOS 8 or 9 would feel like with 2x retina style rendering.
This looks to have the effect of increasing the number of PHP versions projects wanting broad adoption of will have to support. Assuming PHP 8.4 comes out at the end of the year, in January libraries will need to support PHP 8.1 to 8.4.
I think that's mostly OK, but I'll be curious to see if other projects like Laravel or Symfony keep to a shorter PHP version support window just to keep support costs down.
The real problem was when Slack added message reactions. Those weren't visible at all in IRC. They absolutely could have been surfaced, like how Apple sends reactions in SMS chats. In a business context that means missing critical acknowledgements of messages and generally forced our IRC bridge users to switch.
It was a pretty user-hostile way to reduce the number IRC bridge users (to then justify killing it), especially given it took them many years after to get the Electron client to the point where it wasn't a laptop-killer.
I was trying to figure out how long I had possibly been running the infected code. I was certainly in a state today where binaries were running with revoked signatures. What I couldn’t tell is if this state was only for a few minutes or hours, or if it was days or weeks.
If Apple only revoked the dev certificate (and possibly XProtect) today, that would make sense. But if it was revoked a ways back, then it would be concerning that it would require a reboot (with no prompting) for a regular user to fully kill the running background processes.
Actually, thinking about this further, if Apple had revoked the certificates before today, others would probably have noticed it and investigated given the “Move to trash” dialog and the strong assertion of “this is malware” in it.
It looks like Apple has revoked the developer certificate. Anyone know if there's a public log somewhere showing when it was revoked?
The app was blocked from loading, but I still saw the two dylibs running. I wondered if it was because the certificate was revoked after they had already started. However, logging out and back in still showed them running. Perhaps they're persisting through log outs?
As well, I got a prompt from the macOS firewall to allow the mentioned AutoUpdate binary to listen for connections. That makes me think all of this was deployed in the last few days.
Edit: A reboot gave me the `“NightOwl” will damage your computer. You should move it to the Trash.` dialog. Allowing that did not fully clean things up (leaving a non-functional `/Users/*/Library/LaunchAgents/NightOwlUpdater.plist` in place and the usual preference files). For me, Hazel cleans those up.
I think for non-technical users who may not be familiar with the terminal would be to direct them to reboot.
You can generate a Kagi login link with a token and save that to your favourites. Then, click that link in the new private tab window before searching.
We’ve been using Task for our (Drupal) web projects for a few years now and are really pleased with it.
Why not Make? We actually used that on a few projects previously, but found it challenging to use with both our teams and with typical tools used in the PHP and JavaScript stack.
1. Most of our newer hires have never used Make before, or anything like it. It seems to have fallen out of many curriculums in favour of other build tools, presumably due to decreasing focus on C / C++ in fundamental computer science classes. The idea that a build tool is inherently files based is a completely foreign concept.
2. File-based dependency tracking being the exception, and not the rule, simply works better with the majority of the types of tasks we run. Those include building docker containers, pulling down CMS databases for local development, and running CLI tasks like database migrations.
3. For those tasks that can be tracked with files, Task supports both timestamps and hashes.
One big win of Task over other tools is that it ships it’s own built-in sh shell. If you have tasks that run on a host and not in a container, it significantly reduces your host dependencies. Being a typical single-binary go app makes deployments easy too.
I’ll also say the maintainers have been very responsive to our few bug reports and feature requests, and responsive to our contributions too.
The worst part is yes, it’s another YAML DSL to learn. And personally, I wish Make had gained more traction in the web and docker world. But given all of the above, the trade offs of switching to Task have been worth it for us.
This summarizes it well. Sometimes you run into apps that don’t ship Docker containers because they expect to not be behind a reverse proxy. For example, while there are third party Docker containers for the Unifi controller, they only support using their apt repos. The controller expects to be able to send low-level discovery packets and not just HTTP. Lxd makes that really easy.
Also, from a development standpoint sometimes a long-lived container environment is easier. I run zigbee2mqtt inside of lxd because if I want to try a PR, it’s `git checkout … && npm ci` and not building a whole container each time.
For the home NAS and server case, I’ve been really happy with Ubuntu server with zfs + lxd + docker. And, a lxd VM for Home Assistant OS. Basically, the right tool for each job and no worries trying to force software into an environment their developers don’t expect.
As a Canadian travelling to the US for the first time in 2+ years due to COVID, I had a very odd experience in the Minneapolis airport. My meal was clearly done, I'd said I was ready for the bill, but 10 minutes later... nothing. I flagged down the waitress, and she was equally confused that I was still at my table!
I was expecting a wireless terminal, or at least a "come to the cash when you're ready". Wireless units were probably at 75% adoption in early 2020, and went to 100% when things started to reopen as a (perceived at least) way to minimize intermingling among patrons. When I mentioned I was surprised the credit card wasn't wireless (and also did tipping on paper, not in the terminal), the waitress said she'd never even seen a wireless terminal before!
Growing up, tech in Canada always seemed to lag behind the US, and it's weird to see it the other way around.