I ride rental scooters almost 10k minutes per year and would really like to get my hands on my own ride data to plug it into something like this (or simpler) to find the optimal routes for my regular trips.
Google Maps (or others) works good to find a resonable route, but I can do better on my own. One-way streets where bikes are allowed to go do opposite way is sometimes missing, short desire paths connecting bike ways, crossings where it's safe to do an (illegal) right-on-red etc.
Tried a GDPR data claim from Voi but got nothing back :( But I hope the data is somehow available for urban planners, think it would be a great source of truth to use in tools like this.
Unfortunately it is not that easy to simulate traffic, especially not on city scale or larger.
The most important input to a traffic simulator such as this is the so-called "traffic demand", i.e. the routes that vehicles follow. Typically this is provided in the form of origin-destination matrices, but this data is not freely available.
Next up is the way in which traffic lights work. Reality is very hard to model here, again because the data is not freely available.
And then, due to numerous modeling errors in vehicle density, in the way that roads differ from e.g. OpenStreetMap, and how traffic behaves, the simulations are highly unrealistic, unless one spends some time to calibrate it.
It costs quite a lot of money to set up a realistic simulation, and most governments use commercial tooling that is easier to use, such as Vissim or Aimsun.
Many people with mosquito issues around here (Sweden) uses something like https://www.clasohlson.com/se/Mosquito-Magnet/p/31-7190 which burns propane to produce Co2 to lure in mosquitoes and then sucks them in with a fan towards a metal grid to zap them with electricity.
Non-poisonous and from what I've heard fairly effective. Not sure if these exists in the US?
I used one of these for two weeks. It killed many mosquitos, yes, but it killed far, far more non-mosquito pollinators which ultimately is not acceptable to me. If I didn't care about the other insects, I'd just spray my yard with poison and be done with it.
you usually use a chemical attractant insert along with the device. I have one of these. Success seems to be hit or miss. I've run one for a year and it seems to only accidentally catch mosquitos, and that's not a unique outcome. But then others seem to have massive success.
I thought it couldn't be that bad but wow, that's bad. The first font-family entry is Clas Ohlson Sans Web, so presumably a font developed for Clas Ohlson? Looking at samples online, J and to a lesser extend t are similarly hideous.
My in-laws use a system like this, maybe the same one. It uses a CO2 tank rather than burning propane. He runs it 24/7 and he needs to refill the CO2 tank every 1-2 weeks iirc so it's definitely more expensive to run than the death bucket. I think it's a 20 pound tank like you'd see on a homebrew keg system. When he showed it to me, it had caught an absolutely nightmarish number of mosquitoes over the course of a couple days. Like maybe half a liter to a liter in volume squirming around in the net. It made me queasy honestly. I didn't notice anything like bees or butterflies in the trap but I didn't look very closely.
I guess it depends a lot on your situation, but for OP's method to be effective you need to out-compete other breeding grounds in not only your backyard but also X feet/meters away (whatever distance mosquitoes typically fly to "hunt").
If there's a nice shallow pond on the property line 100 feet from your porch (or water filled tires at the sloppy neighbour or whatever it might be), I seriously doubt the efficacy of the method in the article.
This thing would lure in any mosquitoes (and unfortunately other things, as per sibling comment) that fly in your backyard, wherever they come from.
For electricity: That also of course depends, but around here it's not uncommon to have an outlet on the outside of some garage or outbuilding or something. The product I linked have a 50 feet cord as well. The fan noise has not been noticeable at all when I've seen it.
I've been occasionally using Microsoft's RDP Client [0] on my iPhone with external keyboard + mouse with a usb-c cable into my external monitor (with a Logitech RF dongle connected to the back of it).
It worked okay, the mouse support is somewhat of a hack, but keyboard works awesome.
The biggest annoyance was actually getting RDP to work satisfactory on a linux box with no external monitor plugged in to it (hetzner box).
I thought someone would have created an app to run browser on the external screen in full resolution, so I could skip RDP and use vscode server via the browser. But the only option seems to be infinitex2p which is not available in the EU :(.
[0]: Which in typical Microsoft idiotic fashion semi recently got renamed to "Windows app"...
[1]: https://x.com/infinitex2p
I've run vscode over ssh via tailscale before and it was pretty good, I'm mostly connecting to a remote using rustdesk however, that also requires a "dummy" hdmi to operate. The only thing it needs to make it perfect would be if there were officially supported forwarded web browsing windows in vscode. I wish apple would actually let us use "our" usb-c as.. usb-c
Allianz have more than 150k employees with offices in 50+ countries. Not all of them need access to the CRM of course, but I think going back to on-prem is just asking for different kind of trouble.
We don't have any details now, but I wouldn't be surprised if the cloud-based CRM provider didn't have a very technical interesting weakness, but rather that some kind of social engineeringy method was used.
If global companies like this instead had stuff running on-prem all around the world the likelihood of more technical vulnerabilities seems MORE likely to me.
(Air gapping is of course possible, but in my experience, outside of the most security sensitive areas the downsides are simply not acceptable. Or the "air gapping" is just the old "hard shell" / permitter based access-model...)
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination.
I've come to the same conclusion after dealing (and reporting) jankyness in both the Azure (ARM) API and especially the CLI. [0] is a nice issue I look at every once in a while. I think an installed az cli is now 700 MB+ of Python code and different bundled python versions...
Why do all these use Python? AWS, GCP, Azure, all three CLIs use Python; they're slow, bloated, heavy to install... what advantage does Python really offer here? You can't in any sensible way rely on it being installed (in your linked issue we see that they actually bundle it) so it's not even an 'easy' runtime.
Python takes up less than 16 MB on disk (python3.11-minimal + libpython3.11-stdlib on Debian) so whatever Microsoft did to make their Azure CLI package take up almost 700 MB, I don't think the language is the problem.
It might well be part of the problem. Certainly any language can be inefficient, especially in terms of size, if you don't pay attention (have certainly found this with Go recently). But as I said it's also slow (interpreting code, or dealing with cached versions of it) and it's not obvious to me why all three major cloud CLIs have chosen it over alternatives.
I don't understand the Python hate. What would they use instead?
Python is installed on most systems and easy to install when it's not. Only Azure is dumb enough to bundle it, and that was a complaint in the bug - there's no good reason to do so in this day and age.
The performance bottle neck in all three is usually the network communication - have you seen cases where the Python CLI app itself was using 100% of a CPU and slowing things down? I personally haven't.
Looking at the crazy way Azure packaged their CLI, it's hard to believe they weren't making it bloated on purpose.
And which Python are you talking about? I mean, Python3 is forward compatible but you SoL if you have the bad luck of having an older interpreter installed and you want to run a script which uses a new construct.
I don't understand why Windows people are completely okay having to install all kinds of crazy service packs and Visual C++ runtimes anytime they install anything, but then having to install Python seperately makes it a no-go.
Also, AWS is 10 years older than Rust, and C# only runs on Windows (at least it certainly only did when AWS was created, and is laughably more difficult to get running on Linux or OSX than Python).
As mentioned in the thread and expanded on the blog [0] moxie is also against the whole idea of federation and multiple clients.
I think my perception has changed in the last ≈ 10 years, to be more leaning in moxie's direction. It's hard enough to design something secure and usable, having to try and support all different implementations under the sun makes most federated approaches never reach any mass adoption.
Even though it's not a one-to-one analog I also think e.g the lack of crypto agility in Wireshark was a very good decision, the same with QUIC having explicit anti-ossification (e.g encrypted headers). Giving enterprise middle boxes the chance to meddle in things is just setting things to hurt for everyone else.
I don't think it's a problem that they're against federation. I think federation is nice, but it has some clear trade-offs, and I don't feel like it's something Signal needs.
I don't even think they have to officially support third party clients or provide a stable API. I'd have no problem if they just occasionally made API changes which broke unofficial clients until their developers updated them.
But I really don't like that they're so openly hostile to the idea of other people "using their servers for free", with the threat of technical blocks and legal action which that implies. Especially not when their official client is as bad as it is. (Again, it's fucking blurry!)
Something similar again is my little tool hemlis [0]
It uses Shamir's secret sharing algorithm to generate shares where the private key is split in n shares with k needed to reconstruct it. The bytes are encoded as word on a PDF (either 'burnt in' or written manually with pen to minimise the risk of storing them on printers etc).
That way you can spread the risk of loosing the physical key, while still maintaining some assurance that e.g your friends can run away with the key (or be compelled to hand it over to some threat actor).
Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option).
I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's.
> Containers achieve sub-second start times using an optimized Linux kernel configuration[0] and a minimal root filesystem with a lightweight init system.
> Surprised to see no discussion of other data structures like dicts/maps, or arrays of arbitrary type. Hopefully they'd be a straightforward extension. IME, apps need collaborative data structures more often than they need pure collaborative text editing.
Totally agree. I guess an array of "atomic" objects, where the properties of the objects can't be changed can be done just by replacing the string with your own type. Changes inside of the object is probably trickier, but maybe it's just about efficiently storing/traversing the tree?
I've also always thoguth it should be possible to create something where the consumer of the helper library (per OP terminology) can hook in their own lightweight "semantic model" logic, to prevent/manage invalid states. A todo item can't both have isDone: true and state: inProgress at the same time. Similar to rich text formatting semantics mentioned in the linked article.
Every year or so I've been toying with the idea of a thin client dev environment. Smallest possible device that can run Linux (or a RDP client) and support being plugged in to a single USB-C dock cable (display, usb for keyboard/mouse and power).
Maybe this is the answer? Even though I don't need the screen, the footprint of a smartphone is smaller than almost all SBC supporting the above requirements.
I had a project related to this in a big telco about 10 years ago.
We used Citrix because a lot of apps were not native (yet).
Women in tech loved the concept: instead of carrying a laptop they could use the medium-size tablet we provided and have a wireless mouse and keyboard both at the office and at home. We also provided a monitor for both home and the office.
The project didn't lauch commercially because in our tests the microusb to micro-hdmi cables caused a lot of issues and management decided against it.
Google Maps (or others) works good to find a resonable route, but I can do better on my own. One-way streets where bikes are allowed to go do opposite way is sometimes missing, short desire paths connecting bike ways, crossings where it's safe to do an (illegal) right-on-red etc.
Tried a GDPR data claim from Voi but got nothing back :( But I hope the data is somehow available for urban planners, think it would be a great source of truth to use in tools like this.
reply