I see that Docker doesn't actually offer an AWS-style enterprise account that one can use to hand authorization to developers without requiring those developers to make individual accounts.
It feels pretty sassy of docker to give everyone 2 months to shove credentials everywhere when docker themselves haven't done the minimum to make enterprise accounts realistic. Instead, they're adopting the github model of "oh, just ask everyone to make personal accounts and then include their personal accounts in the org team". That has problems.
Firstly, it puts employers in the unpleasant position of attempting to compel employees to make legal agreements with third parties (docker, in this case). The correct way to do this is AWS-style, where the org itself makes /one/ agreement and then delegates that agreement via access keys. This is the minimum I expect from enterprise account systems, hard fail for docker.
Secondly, it's a clusterfuck to manage. You end up with an org filled with random-arse account names that you can't really audit, and you don't know who has access to what. If employees leave the org, it's hard to ensure that their access is revoked because the access takes place entirely outside the standard account domains.
Github has recently improved this a shade by adding ADFS authorization to org accounts, but that involves asking employees to tie their personal (and all github and docker accounts /are/ personal) account to their work ADFS account, which is a shitty half-solution.
All things considered, docker made this problem for themselves. They've spent /years/ working hard to get everyone to make docker accounts and push everything to docker hub instead of fostering an ecosystem of registries by different orgs for different purposes. All of a sudden it's now "too expensive" and they're dropping the hammer on everyone to sign up and push credentials everywhere with very little warning, whilst not doing their half of the work by making a proper delegated authority account system.
Doesn't fill me with confidence for their future as a stable platform on which to base a business.
c) injecting them with hilarious overdoses of drugs and crossing our fingers
then why would we pay for police?
If that's ok, we might as well go back to old west times and just have everyone carry revolvers, possibly calling the town apothecary with his bottle of ether if we think we need it. It'll be way cheaper than maintaining a standing police department.
The whole point is that police are supposed to be trained and equipped to handle disturbances without harming the person being detained. There are options for this, including that so rarely used tactic, defusal.
Like, we pay police overtime. Cordon the person off, give them space but don't let them leave, wait until they get hungry even if it takes 12 hours, and then bribe them with pizza to come quietly. Build rapport with them over the entire incident. How often do we see that strategy deployed before we fall back to injecting ketamine?
>I also don't think that appeals to "is that legal" are all that satisfying
I've always used the rule of thumb that if the best thing someone can say about their behavior or decisions is that they aren't illegal, that person is probably the arsehole in the situation.
Yep. The late 90's and early 2000's was littered with people trying to make "light" copies of MS Word. The problem is that journalists need the wordcount feature, and teachers need the wordart feature. Remove either, you lose a demographic.
That having been said, there are a lot of products out there that made their product intending it to be free, and then when they hit 1m users they started thinking "hmmm, if I could get a dollar out of every user, I could buy a house". They try to stuff a monetization model in sideways and damage their product in the process. Taking a moderately successful product that's crippled by attempting to shoehorn in monetization and redesigning it to have reasonable monetization from the beginning might be a better strategy.
When I first set up my requirements.txt's, I usually set up a venv, install the things that I need and then run "pip freeze" to get a list of all deps including transitive deps, and put them all in the requirements.txts.
I do sometimes feel that people are making rube goldberg machines out of their package management in an attempt to avoid just writing down all their deps.
Leaving aside my visceral reaction to attaching mandatory trackers to people:
>The “BioButton” is wearable technology that monitors your vitals, including temperature and heart-rate, in real time. It can last for up to 90 days. It’s meant to be worn on the chest and connects to your mobile device.
Once again, technologists attempting to make covid solutions have forgotten that not everyone uses smartphones. On top of that, what're the odds that this doesn't work on any version of android older than oreo, or that don't have google play services installed?
Basically sqlite is public domain if your country recognizes that kind of thing. If it doesn't, then sqlite doesn't care and will never pursue you. However, if /you/ care, sqlite will sell you licence. This licence costs $6000, looks very official and shiny and whatnot, covers all your bases as if public domain did exist in your country, and sqlite uses the money to continue funding development.
I'd be inclined to do something very similar with an additional clause stating that if dedicating to the public domain doesn't free me from liability, then see $6000 licence. (I thought sqlite had this, but either they've removed it or I misremember).
I also prefer appimages as the "least worst" of the three.
However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept.
Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter.
From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported.
[1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/
I use ublock origin to selectively block the consent boxes. I've never yet seen a website which says "our backend has noticed you have not yet consented, you may not continue".
I gave quite a few statically-compilable language a try a few years back before settling on nim as my "fat binary" language of choice.
D was a contender, but ultimately the reason I dropped it was I was unable to compile a hello world on my laptop. Now, that machine is not fast, but it is actually pretty new, it's a very low end 2017 dell machine, and it turned out that bootstrapping a D environment requires a midspec machine or it literally cannot complete.
I donno man, D seems to have a "last 5%" problem. It looks good on the surface, but as you start looking into it you discover that the bootstrap tools are fat as hell, the core library has a weird split in GC styles, the doc is inconsistent. Everything you do in D is 5% harder than it needs to be, nothing is buttery smooth. Overall, all those 5% multiply together to make it a 20-30% worse experience overall, although I couldn't point at any one thing and say "that is what has killed D".
I've not yet found that to be the case, although I fear that one day it will.
I generally find that all you need to do is tell people their solution is not acceptable. All the banks in Iceland are trying really hard to convince people that phone based 2FA is the only option. However, I went to my bank and informed them that I don't take my phone with me when I travel overseas and I require another option. They tried a few other variations of "but you could use your phone this way", but once they realized I wasn't joking when I said "I often just don't have a phone with me, find me something else" it turns out that the physical 2FA tokens totally still work, they just don't like telling people.
Generally speaking, the people providing these things have a boss who expects them to make sure things run smoothly. They'll try to force you to use the app if that's the easiest path, but as soon as they realise that trying to force you to use the app will be much more painful for them than just giving you another option, they'll find another option.
>It's that I, a user, cannot choose to sideload an app
That's only half the equation. I run android, but have no google account. I have always used a combination of aptoide, f-droid and manually downloaded apk's for my apps.
When all the covid apps were released and governments were encouraging people to download them, do you think they put the APK on a government website for people to download?
Nope, just links to the app store. Of course, most of those apps relied on google play services API's for a bunch of stuff, so it's not like they would have worked anyway.
It's not enough to merely allow sideloading. If the expectation isn't that mobile devices are a diverse ecosystem and that it's not good enough for developers to pick one store and bugger the rest, you've achieved very little. Most people could not be bothered going through what I do to keep my phone clean.
That's probably why. I use addons that autodelete cookies as soon as I leave webpages because no one has the luxury of pretending they don't know how badly cookies are abused at this point.
I guess the inevitable next step was for companies that abuse cookies to start punishing people for refusing to take their shit.
I reiterate: paypal is a shit company. Pine, please provide an alternative.
I've been waiting for this to come out. Unfortunately, I tried to buy the pinetime late last year and discovered they only sell through paypal and you need an account to make the payment, you can't just pay by credit card.
If there's anyone from pine watching: Please, add a normal credit card option. Paypal is a horrid company. I'm prepared to pay directly with a credit card via them, but I _will not_ make an account with them just to buy your stuff. Please let me give you money without making a legal agreement with a third party :(
>and it does further protect the users password from being harvested from passive MITM'd SSL like it is on some corporate networks.
It might protect the password if the user is reusing it elsewhere, but it doesn't protect the account the password is securing during the intercepted transmission.
That's the opposite of a smart appliance to be honest.
You can use minimodem[1] to scream a file across the room from one computers speakers to another computers modem.
It's a cute trick but requires very little in the way of computation, and is a far cry from the bluetooth infested dumpster fire that is found in the modern app-controlled smart appliance offering.
It's also not significantly an improvement from giving your products clearly labeled short model names and having a two digit code on a 10c LED screen, preferably with a corrosponding entry in the manual. I'd happily give it up in exchange for a washing machine with minimal electronics, so that it will last 20 years and can be fixed with duct tape and epoxy.
I see that Docker doesn't actually offer an AWS-style enterprise account that one can use to hand authorization to developers without requiring those developers to make individual accounts.
It feels pretty sassy of docker to give everyone 2 months to shove credentials everywhere when docker themselves haven't done the minimum to make enterprise accounts realistic. Instead, they're adopting the github model of "oh, just ask everyone to make personal accounts and then include their personal accounts in the org team". That has problems.
Firstly, it puts employers in the unpleasant position of attempting to compel employees to make legal agreements with third parties (docker, in this case). The correct way to do this is AWS-style, where the org itself makes /one/ agreement and then delegates that agreement via access keys. This is the minimum I expect from enterprise account systems, hard fail for docker.
Secondly, it's a clusterfuck to manage. You end up with an org filled with random-arse account names that you can't really audit, and you don't know who has access to what. If employees leave the org, it's hard to ensure that their access is revoked because the access takes place entirely outside the standard account domains.
Github has recently improved this a shade by adding ADFS authorization to org accounts, but that involves asking employees to tie their personal (and all github and docker accounts /are/ personal) account to their work ADFS account, which is a shitty half-solution.
All things considered, docker made this problem for themselves. They've spent /years/ working hard to get everyone to make docker accounts and push everything to docker hub instead of fostering an ecosystem of registries by different orgs for different purposes. All of a sudden it's now "too expensive" and they're dropping the hammer on everyone to sign up and push credentials everywhere with very little warning, whilst not doing their half of the work by making a proper delegated authority account system.
Doesn't fill me with confidence for their future as a stable platform on which to base a business.