MikroTik also has a number of cheap devices and I have several of their "discontinued" products that are over a decade old that I'm still updating.
Their releases aren't really for _a_ device, but for a CPU architecture/chipset, so I don't know that I've actually run across any device that went unsupported before I replaced it anyway for reasons of wanting faster networking (i.e., 10/100 -> 1000; 802.11bgn -> 802.11n -> 802.11ac).
The reason Docker Desktop for Mac looks like you're running Docker on Linux is because... you are. It's running docker in a linux VM for you.
Similar issues in our environment, and I managed to swap everything over to Rancher Desktop fairly seamlessly as it does the exact same thing. It runs a Linux VM and if you select the "dockerd (moby)" container engine it runs a copy of docker inside of it. So you get a socket with the same docker API implemented... because it's running actual docker. docker compose and everything else work as expected.
The reason we switched is that Rancher Desktop, along with providing a convenient way to run docker, also includes a full k3s install in that same VM. So we can work on unifying some of our stack/configs on kubernetes rather than docker for local and kubernetes for everywhere else. It also opens up using upstream helm charts and things when a developer wants to deploy and try something locally.
It's also free. Open source and backed by SUSE, who also develops and maintains the k3s distribution among other stuff in this space.
> The reason Docker Desktop for Mac looks like you're running Docker on Linux is because... you are. It's running docker in a linux VM for you.
Yes, but that wasn't what I was talking about. Docker Desktop for Mac goes to a lot of trouble to hide the fact that there are two different virtual filesystems involved (Linux vs macOS) and two different networking stacks too. That means scripts which run on Docker for Linux and do stuff involving filesystem/network integration between the host and the container will often work without change on Docker Desktop for Mac. In my past experience, open source alternatives don't offer as seamless integration, they don't do as good a job of hiding the fact that there are two different virtual filesystems and networking stacks, so those kinds of scripts are less likely to work.
Don't know your use case that precisely so can't say if it does a "good job" versus just "a job", and it's been a while since I've used Docker Desktop or macos (though about half of our dev team is using Rancher Desktop on macos right now), but as far as I'm aware it's essentially identical.
FS: Rancher mounts your `/Users/$USER` folder in the VM that Docker is running in. It supports virtiofs on macos (not sure if it's used by default though). As far as I can tell, this replicates the default Docker Desktop setup.
Networking Container -> Host: Connecting to `host.docker.internal` works as expected. On the host I can listen on a port on my host (`nc -l -p 1234`) and connect from a container (`docker run -it --rm alpine nc host.docker.internal 1234`).
Networking Host -> Container: Exposed ports work as I would expect. I can run a container with an exposed port (`docker run -it --rm -p 1234:1234 alpine nc -l -p 1234`) and connect from my host (`telnet localhost 1234`). I can't connect directly onto the docker network bridge (though I'm not sure if that was ever supported on OSX?).
No skin in the game either way here, just with a bunch of people suggesting buying OrbStack (which is OSX only), figured I'd throw Rancher Desktop out as a potentially viable cross-platform alternative that's also free and OSS.
Probably just a "it's hard for little pay-off" issue.
To use a bluetooth keyboard from the stage of "Press F10 to Enter Setup" we need the firmware (whether BT host, mainboard, or something else) to have a full bluetooth stack, some way to manage pairing/unpairing devices, and a bunch of other stuff.
If we do this outside the BT host, we probably need changes to the operating systems at least to handle how we're going to hand-off the state of the bluetooth stack when the OS takes control. Unless we want to _separately_ manage pairing/unpairing in the firmware, we would probably want some way to expose that to the operating system to be able to push its paired devices down.
And then it's probably still not super useful unless we substantially lengthen the prompt time because the time for you to turn the keyboard on, coax it into connecting, and hit the button is gonna probably have the OS booted already.
If you want this today just don't use bluetooth. Get one of the devices that uses "2.4GHz" or uses "Bluetooth + 2.4GHz" and shove a dongle in there. The keyboard/mouse will appear as a normal USB-connected device and you can use them how you want.
> If we do this outside the BT host, we probably need changes to the operating systems at least to handle how we're going to hand-off the state of the bluetooth stack when the OS takes control.
During the CSR hid2hci era, the adapter would just remember the last N pairings, since a sufficiently smart adapter can technically just store the keys used by the host when it tries to pair, then "impersonate" the host during the HCI part.
> Your compromise sounds far worse to me than all the bots, extremists, vulgarity or whatever other problem it's supposed to solve.
Yeah, but in all likelihood _that isn't one of the options_.
The moral panics and "think of the children" and general ignorance around these things is going to drive action at some point.
The options are "implement the least bad thing we can" or "wait for legislators and regulators to dictate how it will work".
I'd rather see Apple (who already has some semblance of ability to verify your age as you usually have payment methods and things tied to your account) come in and implement some protocol involving a bunch of cryptography I can't even begin to understand that preserves privacy and anonymity, have that gain a foothold, and have eventual regulations either seen as unnecessary or effectively having to support this sort of workflow.
The alternative I see is at some point we're going to get a regulation that involves everyone having to send a photo of themselves holding up their driver's license all over the place in order to access half the internet.
To add on to what others have said, as a habitual "no don't send telemetry" clicker, I think this is heading a direction where I _would_ hit allow.
Two adjustments I could think of that would make it better (besides explaining clearly, etc):
Ask me when you're not actively obstructing me from getting to what I want. Like asking on first boot I've gotten no value from the software yet that I might feel I need to pay back, and I'm actively trying to get _in_ to the game and your pop-up is in my way. The easiest and safest way to get rid of it is "do not allow". Try asking _after_ I finish a game/round/whatever.
And that would also give you the opportunity to do something like collect real analytics information to show to the user. Like "Hey I hope you're enjoying the game it's useful for me to have stats about how people use abilities and items to tune and balance the game systems. Would you be willing to contribute to the game's further development by sending information like that below which was collected from your last round?" And then skip the JSON/etc unless your audience is programmers, just show them a table.
Finishing some play time having had fun and getting a pop-up that explains what, why, and gives me a chance to make an informed decision on whether to send something innocuous like "(offset-timestamp, event-type, item-id/ability-id)"... I'd actually probably allow it.
I am also anti telemetry, but given a direct usability request, I would be somewhat tempted to share it.
A way to package it would be to show end of game stats compared to global averages. Histograms of mana/health/bullets vs the world standard. Maybe a personal historical trendline vs past performance. On that screen, give an option to share metrics with the community. Users can immediately see what the aggregated data can provide and might feel more likely to consent.
To be most user forward, keep a local non-obfuscated log of what is shared. This also makes it possible for dedicated users to potentially mine their performance.
Well, if for any reason you went "hey, what the hell does that mean" and decided to look it up:
- (informal offensive) an unpleasant or stupid person:
- (informal offensive) a person with a physical disability, especially one that affects someone's legs
- (informal) a limp (= a way of walking slowly and with difficulty because of having an injured or painful leg or foot )
- a person who gets sexual pleasure from being hurt or treated badly
And it's not like this is super obscure or anything. The "most influential film of the 90s", Pulp Fiction, literally had a character that was "the gimp". This is pretty mainstream.
This is along the lines of "Hey co-worker, I found the best text editor the other day. It's called pizdă, you should give it a try! Pizdă seems like it would help you!"
I think the issue's with differing laws is more or less covered by "knowingly".
A small company that gets a contract drafted up and uses it in a neighbouring state or something wouldn't really qualify as doing it "knowingly" by any reasonable sense of the word.
A company the size of TicketMaster who has undoubtedly already had lawyers from or familiar with multiple regions review and modify their contracts can damn well be considered "knowingly" doing this. And if they _didn't_ have any other lawyers look at it, well, I think we could call that willful ignorance ("negligence") and apply it anyway.
This really isn't far off of established law, either (at least to my layman understanding). This is more or less how most criminal laws work already. You have to have some sort of intent to commit the crime. Intent can be fulfilled by negligence/etc as well. (You didn't _try_ and do this, but you didn't take the level of care that would be expected so it was a foreseeable outcome of your actions and we're taking that as good as intent.)
> A company the size of TicketMaster who has undoubtedly already had lawyers from or familiar with multiple regions review and modify their contracts can damn well be considered "knowingly" doing this.
Known or should have known is usually how this is phrased.
There are situations where sorting by "number of positive ratings" works, but there are many (I'd say most?) where the downsides are impactful enough to make it a non-option.
The issues are creating a first-mover advantage and a feedback loop. This makes the ranking very... stable, but that's usually not desirable.
The first-mover advantage comes because you're using the absolute number, so things that have been around longer will tend to be ranked higher. Even in a system with positive and negative ratings, sorting by `positive - negative` only reduces the problem... not removes it. Something that's been around for a couple years getting 40% negative ratings is still going up by 20% of the total amount which will quickly be a big number to try and catch up to.
That alone is usually disqualifying, but to make it worse usually the ranking system is creating a positive feedback loop because it's what's driving exposure of the options. People will tend to look at / try / buy / etc the top ranked item before the lowest ranked. So you're driving most new ratings towards the existing top-ranked item and continuing to reinforce its place at the top.
You're basically ranking by "the oldest product that doesn't have net-negative ratings". That may be what you want, but usually it isn't.
(I've never seen it, but I guess if you had only _bad_ options, you'd actually get the opposite effect... the least worst product at the top, getting exposure, and being beaten down until a new least worst product takes center stage and your ranking system just oscillates like crazy.)
Where the simple ranking like this could work a little better would be where all the options are known up-front. There's nothing to "catch up" to since everyone started by the same starter pistol. If you have a positive feedback loop though, you are going to end up weighting earlier ratings heaver than later ratings.
The other case I can think of would be where the options you're ranking are few enough (such that position in the ranking doesn't really create much difference in exposure, reducing the positive feedback loop) and you're collecting few enough votes (further reducing it) and the items are fixed up front (removing the first-mover advantage) that none of this would really have a chance to have any outsized impact. I can't see an issue using this on a poll sent to a dozen people asking them which of 5 places they preferred for lunch.
I've used the "correct solution" from the article in the past. It worked well enough I didn't have to come back to it.
For some reason this all reminded me of a line from the Battlestar Galactica remake:
> "The story of Galactica isn't that people make bad decisions under pressure, it's that those mistakes are the exception."
The story of Debian isn't the mistakes, it's how few mistakes there are. It's an entire operating system that's been release consistently for over 30 years and currently in 78 languages. There are around 122k packages in the official software repository, almost all packaged by the Debian project. In terms of number of possible combinations of installed systems, just in software packages, that's something like 21 googolplex. Or around 445x the number of atoms in the observable universe. Never mind the different architectures and all the different hardware variants they could be installed on.
Even if it wasn't given away _for free_, it would be an impressive achievement.
Their releases aren't really for _a_ device, but for a CPU architecture/chipset, so I don't know that I've actually run across any device that went unsupported before I replaced it anyway for reasons of wanting faster networking (i.e., 10/100 -> 1000; 802.11bgn -> 802.11n -> 802.11ac).
Many of them are also supported by OpenWRT.
reply