Except, I only use services I pay for and set tight privacy settings.
EDIT: sorry for the initial short reply, your comment deserved a more reasoned response: I build my digital life on two primary service providers:
Proton: mail, cloud storage, and Luma private LLM chat (integrated web search tool with a strong Mistral model: my default tool that replaces plain web searches, 90% of my routine ‘LLM chat’ use)
Google: Gemini APIs, occasional use of Gemini for deep research, very occasional use of AntiGravity for coding using Claude and Gemini models, YouTube Plus for entertainment (philosophy talks, nature videos, Qi Gong exercise, etc. etc.)
Also some use of:
DuckDuckGo: when I still do web search, DDG is my default.
Author argues against strong typing systems and language features to prevent classes of bugs and instead encourages developers to "writing lots of tests" for things that a type system would prevent.
The authors thesis seems to be that it's preferable to rely on the programmer who wrote bugs to write even more bugs in tests in order to have some benefit over a compiler or type system that can prevent these things from happening in the first place?
So obviously it's an opinion and he's entitled to it, but (in my own opinion) it is so so so, on-its-face, just flat out wrong, I'm concerned that that it's creating developers who believe that writing so many tests (that languages and compilers save you time (and bugs) in writing) is a valid solution to preventing null pointer defeferences.
There's also another strong argument against favoring tests over types, which is maintainability. If I go ahead and change a variable type from being non-nullable to nullable, I instantly get a complete list of all the places where I have to handle that, which makes it much much faster to generalize the logic. But in a dynamic language, all tests that were written by the previous developer was written at a time when this variable was assumed to never be null and uses non-null values for all test vectors, so good luck using that to find the places that need to be fixed.
On top of that, every test that could have been omitted due to a type system incurs an extra maintenance tax that you have to pay when you change the API.
I think you you're missing the point though, he did not say that adding those constraints was a bad idea per se, but they are leading to a bad path. If the path is "just add more guard-rails" then we will get to a point where we lose the "soft" part of "software" and you'll find yourself restarting each time you need to change something because at that point the language you chose was already the first wall of a bad program architecture (ease of change).
My UserService doesn't know that it's talking to a UserDB (ironically I learned this from Uncle Bob).
All UserService knows is it has a dependency which, if passed a UserId, will return a User (+/- whatever the failure mode is .. Future<User>? Promise<User>? ReaderT m User?)
When I change my mind about what UserService requires or what UserDB provides (which I frequently do), I immediately look at all the red underlines that my compiler & static types tell me about.
I've seen the actual videos. While tragic, then she was trying to drive away, not obeying the approaching officer's orders. At that moment, the officer towards she was driving was the one that shot her.
It also seemed that right before the event she was doing some kind of traffic regulation there which is why the officers approached her.
You can't start at the point the ICE agent had already set up his pretext to execute her. That's equivalent to equating legality with morality, which doesn't work when talking about what ought to be. Rather you have to examine the entire situation, which was an extreme escalation by ICE in response to what was essentially protesting.
There was no pretext to execute her. It's when she started driving (even spun the wheels I think) towards the officer were shots fired. In your mind, does police getaway equate with protesting now?
The pretext is deliberately standing in a position such that if the car moves he can claim to be acting in "self defense". This was directly contrary to ICE's own procedures about how to approach vehicles. This particular agent had even previously fucked around and found out about moving vehicles, so it's a reasonable assumption that this positioning was fully deliberate - the agent set the situation up so that he'd have an excuse to kill the next driver who didn't respect his authorituh.
If you look at the video, then the woman turns the front of the car towards the agent, who comes from the other side. Do you mean that he knew the movement that was going to happen and risked his life to do that.
Would you say the woman was in her right to attempt a getaway?
"As I said, you're starting at a point where the ICE agent had already set up his pretext to execute her."
Sitting in front of a screen and Monday-morning-quarterbacking, it's easy to say that driving off was wrong. But nobody really knows what they themselves would do in a fight or flight situation when being assaulted by a group of masked men, especially when one of the group is aggressive enough that they are indeed going to end up killing you.
The point is these "public servants" should not be escalating to create such high-stakes situations in the first place, especially with regards to citizens who are protesting. There is zero excuse for it, and under any halfway-sane administration such an event would be, at the very least, a moment of investigation and reflection.
Wut? You do realize that being in the presence of law enforcement officers is much different than the situation of being actively assaulted by them, right?
For example, the other day I interacted with a few police officers in person by virtue of being tangentially-involved with a car crash. I laughed and joked with them, then went about my business. But if they had instead been surrounding me with guns drawn, it would have taken me the rest of the day to come down from that.
When driving towards a law enforcement officer, it is you assaulting them, not the other way around. Fleeing is against the law as well. Why did the woman attempt this? Ot, if it was so dangerous, what was she doing there?
That's a weird way to frame the perspective of someone whose primary job responsibility is physical aggression. It's also not too hard to jump out of the way of a vehicle that you're focusing on if it starts moving. The argument you're effectively making is that the agent's positioning was entirely non-deliberate, even though he had been dragged by a car previously.
So the argument you are effectively making is that the police officer was planning to jump out of the way and this posed reasonably little health risk?
Do you think the shots through the driver window, after the agent was 100% out of the way of the vehicle, were justified?
From the medical examiner we know it was one of these two shots that killed her. We know they did not come in through the front windshield when the agent was at the front quarter panel. We see them clearly occur on video while the officer is definitively out of the path of the vehicle.
It also is quite clear from the results that shooting her did not make the situation safer after he was clear, either - it directly causes the car to accelerate while not under the control of a living human being.
Personally, I would still argue about even the first shot - but I have yet to be able to find any common ground in discussions with people that defend the 2nd and 3rd shot.
You describe a world where human skill is required to prevent these class of bugs, time and time again we've proven that people are people and bugs happen.
Systems must be _structurally architected_ with security in mind.
Security is layered, using a random key with 128-bit space makes guessing UUIDs infeasible. But _also_ you should be doing AuthZ on the records, and also you should be doing rate limiting on API so they can't be brute forced, either.
I have two moonlanders but wound up giving up because I just couldn't adapt to it. And when writing code, finding the symbols like {, =, }, and other common coding ones was just too difficult to retain muscle memory. I tried many layouts, I tried to make my own, and at the end of the day it was just too different. I wish I had a better experience.
Muscle memory is exactly what it sounds like, you need more repetition. If you are becoming frustrated, you can try to reduce your cognitive load. ZSA has an app for all platforms called "Keymapp". It's primarily used for flashing firmware but shows the key assignments in real time. I use only 1 monitor but I've repurposed my laptop screen to always display keymapp so I can see which key/layer has the symbol I am looking for when I don't have the mental capacity to remember.
The default layers are pretty good, but I found programming the keys/layers to what made sense to me to be more beneficial. I use the heat map to see which keys get the most milage and program layers around that. Then I only program a few new keys at a time and get a feel for things. My words-per-minute went down initially but now it is back.
I have been tweaking my layout for about a month and am close to being happy with it. I've set myself a milestone that when I don't make any tweaks for 6 months I will buy custom keycaps that have my exact symbols/layers on each key.
I didn't like the default layouts for symbols either and wound up building this layout[1] (there have been a few minor tweaks since but nothing substantial). The parens as double taps on the shift keys is the big one for me for writing code. The other brackets on the inside are convenient enough to use but not occupying "prime" space, and I have "auto-shift" enabled so a top on "[" give that character, but holding it down (for > 160ms) gives "{" (and same for all the other keys and their respective shifted versions. And in case it isn't clear what's going on in the thumb clusters, the two enter keys and the space key do their respective actions on tap, and do Left CTRL, ALT or Right CTRL respectively when held down. Might be a place to start if you wanted to try again.
Also on the "muscle memory" thing, I decided early on to not try to modify any other keyboards in my life. Just the ergodox get the middlemak and super custom layout. I found that preserves muscle memory for laptop built in keyboards and using other people's and allows my brain to form a completely separate set of muscle memory that kicks in on the ergodox and neither seem to conflict with each other. Works for my brain, might work for you too.
- Learn their default layout first, then iterate on your personal preferences. I similarly tried a bunch at first, but realized switching layouts constantly was making it impossible to build up the new muscle memory.
- Spend time practicing away from important coding tasks (e.g. gaming, writing, a side project, a one-off script, etc.). Being able to learn in a forgiving environment, outside of deadlines, gives you the space to allow mistakes and time to correct them
I've mapped paired symbols to the same finger on opposite hands, so ()[]{}<>/\'" are mirrored, and then also I've got numbers and symbols corresponding as well so the 123... pad on my right is a !@#... pad on my left. It gets me pretty far, but not everything has a mate so I occasionally have a brain fart moment and suddenly I'm hunting for | even though I have years worth of muscle memory on this layout.
So I guess I'd say: design to lean on familiar structures as much as you can and then just commit to using it a lot and don't give yourself too hard of a time when it gets wierd. Whatever you come up with will surely beat the pain associated with having your right on of pinky in charge of 50% of the symbols plus enter.
It's still mechanical, it's still split, it's still QMK programmable, it's got hotswap sockets so you can try different switches... but it's also an extremely normal staggered layout with function keys and everything.
I think it's worth trying the ortho 'n' layers approach, because it has real wins to it; but if you've tried it and don't like it, this is one step closer to normalcy, while still keeping many of the wins.
How long did you spend trying to adjust? it takes some time. I consistently made typos for about 2 months and then it quickly became very natural to type. My only advice here is to slog through the typos for a couple months. Our brains are flexible enough to adapt.
Their point is that Golang has seen adoption and use outside the Google ecosystem, which is perhaps surprising, and something few other "company languages" have managed (e.g. Swift is actually quite a nice language design, but almost no-one uses it unless they're deeply involved with the Apple ecosystem).
Sure, if you forget about C, Java, TypeScript, SQL, and many others.
Swift isn’t gaining much adoption because Apple aren’t putting much effort into promoting its use outside of the Apple ecosystem. And why would they when they don’t care about non-Apple stuff
> Sure, if you forget about C, Java, TypeScript, SQL, and many others.
C has had multiple implementations from multiple implementors for decades. Java wasn't really tied into Sun's ecosystem, and had an enormous marketing blitz. TypeScript was even less of a Microsoft "company language" - and I think it's interesting that Dart felt a lot more tied into everything Google was doing, but ultimately lost out.
Go has two things going for it, it was created by legends, so it gained a lot of interest from the beginning, and it has an excellent and unique runtime, making it really ideal for network services that constantly wait for something, yet still being able to do CPU intensive work. The language itself is just "OK" and that's kind of the point of it.
I think being able to just create cross platform binaries + having good tooling out of the box as well. You can get started with go very easily and sharing programs as binaries just removes a whole lot of issues you'd have in other languages.
I think they mean success in terms of Go being used outside Google? Versus hack/hhvm which had a pretty narrow window where it saw some limited outside adoption.
At least President Dwayne Elizondo Mountain Dew Herbert Camacho cared about things enough to make things better for his people, hired the smartest person he knew and genuinely tried to fix things.
I don't like the Tidbyt v2. I hated it from the minute I unboxed it, would not recommend. The pixels are very blurry and the image is not crisp at all. The v1 was pretty good, looks more like a dot oriented board (far less resolution). more discussion: https://discuss.tidbyt.com/t/gen2-blurry-screen/6654
I mean, the middle class finally died a decade ago and all the money was siphoned off to the top. I don’t think is has much to do with growth in it of itself
The upper classes have extracted growth from a slowing curve by carving more and more out of the middle and lower classes. To them it looks like growth, but it's really just stealing from the bottom to pad the curve.
> I guess really the bigger issue here is the dynamic nature of the prefixes. If I could go log into IANA and click a button and get assigned a /48 then log in to my ISPs' sites and attach it to my connection and be on my way... I'd deploy it today, no problem.
Yes, this right here. It should work like a phone number where you can take it from provider to provider. You setup your gateway with your IPv6 prefix and then go.
Problem is all the technical and non-technical stuff to actually make that work.
- Verifying ownership of the prefix (rPKI or IRRs) and which ASNs are allowed to advertise it.
- Limiting allocations to someone? I guess phones solve this with SIMs
- Getting your ISP to route the traffic to your device
- Getting the device to announce it with RAs
- Dealing with asymmetric return routing over a slow "path" since it could be multi-homed
- Dealing with routing aggregation since IPv6 routing tables would explode with all the /56s in there
reply