Also the complete lack of critical thinking in tech journalism. Just a few years back reputable publications heaped praise on SBF as it was fashionable to jump on the crypto miracle bandwagon. Now it's fashionable to jump on the crypto crookery bandwagon. As an industry, it seems to just play to and reinforce the readership's prevailing biases. It's a good case for why reading tech journalism is a waste of time with very little net insight gain coming from it.
In the early stages of product dev I tend to do direct customer interaction (user research, customer troubleshooting, frontline support), instead of farming it out to junior team members the way I do with more mature products. This gives me a deeper sense of what users think about our product.
I was introduced to the scene at 15 and was active in it until about 17. Too young to travel to proper demo parties, but old enough to contribute code and music, and to enjoy the demo disks that came in the mail after a swap party.
It's interesting to rationalize it as an art form today. It sounds reasonable, but I don't think I or my friends thought of what we were doing as art, at the time. We were trying to impress each other with things that looked cool. To the extent that art was involved, yes, we needed music and graphics and fonts and creative designs, but we did these things out of necessity, without calling ourselves composers or graphic artists or type designers or art directors. Watching what others sent you and contributing your own stuff created a sense of belonging which I feel was really the primary motivator for my friends and me.
Regarding tools, there was one thing that was frowned upon in my circles: the use of demomaker software. These point and click apps allowed people to call themselves demo makers even though they did nothing technical. Boo!
In the country applying export sanctions, what companies draw short-term benefits? Usually most commercial actors would rather be able to export anything anywhere.
> more work was shifted to be done in the restricted country
Yes and it cost them more overall. People who design sanctions know well that they provide a powerful incentive to the development of indigenous alternatives in the target country. The calculus is that on balance, it is more desirable to force the target country to waste their resources on catching up (or on circumventing sanctions). The point is to make things more expensive.
I don't think this is for tracking. If this was just for tracking, there are much simpler and discreet ways to do it (just add a background ping). I think this is to allow intercepting the user if Google determines that the link destination is harmful (eg malware distribution).
Capitol cops might disagree... This country has had a recent armed insurrection and people convicted of seditious conspiracy. Meanwhile the people who organized it see themselves as the victims of weaponized law enforcement and call for violence against law enforcement institutions such as judges, attorney generals, etc. It's not the entire real world, but you've got to admit it isn't just a Twitter bubble that's crazy polarized.
The question isn't really whether you got some useful service in exchange for your 3%. Monopolies and cartels don't always rob you blind. The question is whether you had a choice and meaningful competition on price.
Making something you like, and not some BS trying to triangulate the needs of some hypothetical user, is a very enjoyable way to go about a career in design and engineering. I'm lucky to be in that boat and have the ability to work on something I personally use as well. It makes so many things easy: I can have an insight from using the product myself, build a solution for it, ship it, and in general users share the same insight and appreciate it.
However, as I enjoy this, what often gives me pause about it is thinking about fields like medical device development, or services for the poor, where most people working on the product aren't in the market for that product. I don't think the same ethos applies as well there and it probably means that to accomplish something meaningful in these domains, a hefty dose of cognitive empathy is necessary, as well as checking one's own insights regularly to make sure we're not imagining things.
In my observation, to a first approximation, cable operators take off-the-shelf equipment, connect it, power it on, and bill customers for it. They don't really have the r&d capability to innovate and create new monitoring solutions quickly.
It might happen that an equipment manufacturer sees an opportunity and builds something, but then they have to go into a long sales cycles to convince operators to use it. Operators are in a duopoly situation in most places, so quality of service is kind of a secondary concern for them - customers may get annoyed, but as long as the competition is not vastly superior, few actually switch. It is not a market prone to innovation.
Stats class role of thumb: if you need to calculate the relative probability of two outcomes, you can get to within about 10% once you get 100 samples of each outcome (so, need more samples overall if the distribution is skewed).
This is what I think about when I see people wiring a bunch of Google assistant devices and compatible widgetry in their homes. Home tech is supposed to last 20 years+, so why be okay with putting things in the walls from a company that has a pretty thick-faced history of leaving markets that it finds itself unable to milk for advertising?
Financial transactions are already typically transparent to the government (they can just ask the registered banks for data). As for commercial communications, it's already the case in many jurisdictions that every service provider operating in that country must provide their private keys to a key escrow. That does not cause a visible collapse of Internet-based services in these countries.
Is this the same argument as "bad people will always flout rules, might as well give every person a machine gun so the good guys can have an even fight"? Looking at China, I think that it is very possible to make it least very uncomfortable, so uncomfortable as to be an effective deterrent.
Unpopular puffin opinion ahead, for the sake of argument only. Pls respond with arguments vs just downvoting.
Throughout history, encryption has always been a government privilege. Only very recently, and then only in the West, practically speaking, is encryption that is safe from the eyes of government available. The liberalization of encryption has been concomitant with a naive "end of history" belief that once everyone was connected as part of a global network, we'd see an inevitable global rise in liberal forces that would make governments unable to control speech. See Bill Clinton's on "nailing Jello to the wall". Clinton whose administration did liberalize encryption quite a bit.
That "end of history" mindset was wrong. We are back in a quasi cold war, with an active proxy war on top of it and a few more smoldering. And so my prediction is that we will see a reversal to the mean of history, and cryptography become again a govt granted privilege with conditions attached. (Yes yes I know public implementations of every algorithm exist, but China showed the blueprint of the machine that nails Jello to the wall anyways.)
The article is not very clear about whether this kind of abusive data collection is actually happening and they can prove it, or whether they found the text of the privacy policies to be overly broad. I have no idea how a car would infer my sexual orientation.
Kia driver here. There is a screen in my car, but also actual knobs and steering wheel controls for everything I might need (audio controls, climate controls) and when I use the screen to project my phone, almost all functions there can be activated through voice control.
Ehh... Sometimes. I tried this modular approach with a project, some things worked very well, others not well at all. In particular I have a ton of EF interference noise in my audio circuit and no idea how to get rid of it.
Your take is right, but a bit extreme. One thing I feel people forget is that speed is a feature. Having used a code editor with excellent AI suggestions for more than a month, I can say that I'm very frustrated when it doesn't work and all of a sudden I have to type the boring boilerplate again and make the innumerable, stupid mistakes that any human manually doing it will make. My prediction is that saving the stupid stuff for the LLM will lead to much increased productivity and ability to concentrate. Will it be 30x throughout? No. But with enough 30x moments in your day, you become maybe 10-20% more effective, and a lot more than that when prototyping (as is the case here). I think we'll look back on the time before LLM with the same puzzlement as people looking at punch cards today.
My policy is no phone until middle school (11). Even then I intend it to be strictly for family comms while away from home, no social media or texting with friends.
Re. FOSS the problem isn't the software, it's what they can access through it. Instagram, tiktok etc are horrible for self esteem, education, emotional growth.
Even with something as simple as a Kindle (which we don't restrict as much) I've had to drop Kindle unlimited because my kid was reading age inappropriate material on it. Children have very very poor impulse control and all that the online stuff does is basically exploiting that.
We show example by putting cell phones away at 8pm when at home and not using phones while eating.
Also it's a matter of skill fit. To take extremes I worked with engineers experienced in mobile app game engineering, who were thinking about UI latency in obsessive detail, and engineers skilled in thinking about ML ranking problems, who had deep knowledge about the strengths and weaknesses of various ML approaches. You could've swapped their roles and it would've been a disaster, not because they're not proficient, but because it would've taken a long time to ramp up on what's important in the other's area
No amount methodology is going to make gold come out of a team that doesn't deeply understand the reasons for building what they're building.
I work with a small-a agile team, and the devs who "get it" just make it happen without a waterfall. The ones who don't get it get a super detailed spec to minimize the chances they'll mess it up, and still mess it up. The ones in the middle know when to reach out to ask for an out-of-cycle product clarification before building a useless pile of code.
The main difference is, do they understand why they're building what they're building? Or do they show up, punch through a bunch of tickets, go home? Really hard to fix that with process when that's not working. It starts with good hiring, building a vision together for what we're building, and communicating it repeatedly.