omegalulw

Your argument is essentially that just because you don't need/like Uber doesn't mean it's useful? The problem Uber is addressing is not just a US problem - with Uber you essentially don't have to deal with all the shit taxi drivers pull, like refusing rides if they have to go to a slightly less profitable area, overcharging for rides for people new to the area/tourists, etc. Not to mention that with Uber you know exactly when the driver is coming, how much you will be charged up front, etc. You may not like how Uber is addressing these problems - and indeed there are fair criticisms, but ride sharing apps are most certainly solving a real problem.

You are saying two very different things here. The stuff that we make today is built on millennia of knowledge - obviously it won't be trivial to understand or fix. That's not a problem - unless you want to force everyone back to the stone age.

Your second point is valid, a lot of stuff is shipped with stuff that isn't useful for end consumer or even anti consumer outright. The solution to this is to push for right to repair laws, patent reform, open source, etc and not decry modern technology altogether.

/thread

My first thought was that most people use TikTok on mobile, whats the point of this (if the ad takes them to play store/app store or to the Uber eats app). Then I realized that this is probably aimed at tracking for new signups, they probably send them to the app stores with a redirect to their site in the middle. TikTok probably doesnt forward them the user identifier hence the tiktok pixel on their page, so they can see the effectiveness of the ad on some TikTok ads dashboard.

He is saying that many programs are written to use "free RAM", ergo unless defender is still using 2GB ram when your PC is at your RAM limit you don't have a problem. Every OS does it, let your OS manage RAM.

That's whataboutism. I absolutely do not want Microsoft grabbing stuff from my PC without asking me, it's so insidious. And then they put the switches to turn these off behind so many loops and registry flags that's it's a nightmare to turn this crap off.

It's not always an antipattern. Another example would be a public API that exposes more state/info than it's users need, just for better tests. It's still kind of not the best practice, I will concede, since almost always you want to focus on testing the contract, but sometimes, exposing some extremely critical state info is ok to improve tests.

I found this to have many questionable claims for example:

> Ensure that all Logic classes can be constructed without providing any parameters (and without using a DI framework). In practice, this means that most objects instantiate their dependencies in their constructor by default, although they may also accept them as optional parameters.

When you do the latter, it kind of defeats the purpose of dependency injection and what you are testing won't be what you use in prod. And when you don't do this, you have to set up dependencies properly - at that point it's almost becomes an integration test. IMO the right thing here is to mock dependencies in unit tests so you can properly test the class in question.

Fundamentally, it seems like the author hasn't worked on or considered complex distributed systems where stuff like dependency management, sequencing (back and forth interactions), etc really matter - you can't test those properly in unit tests, you need integration tests.

Unit tests and integration tests complement each other, you can't reasonably test and update complex systems without both.

As someone who has had to manually satellite TV dish, AFAIK, there's always guidelines on the specific angles you need to orient your dish at. Couldn't an adversary place satellites to also broadcast noise in roughly the same direction?

Financial markets almost always tend to price future growth in, it's not really a surprise.

It really depends in coding style. For example, I always like to write the smallest possible change to address a feature and bug fix that's testable, then I start writing unit tests, then back to code, then back to unit tests and so on. So it's not uncommon to do a lot of incremental builds (but yeah 30/hour is on the high side). Sometimes this is not feasible, e.g. working on a complex component which has a simple public API but does a lot of heavy lifting internally - in that case it takes a while to get to a testable change.

Just because people cannot tell generated content from natural content doesn't mean ML classifiers can't. Training GPT-3 to recognize GTP-3 is w lot simpler than you think (more specifically, we do t have a good way of sampling from the long tail when generations which a model like GPT-3 can pick up on in a jiffy), especially since vast majority of people won't be able to find tune the model enough to diverge from base statistics. Throw in other features like domain trustworthiness, user click rate, etc and search engines should remain fairly reliable for mainstream searches. If you are searching niche content though, yes, there could be degradation

From FCCs doc that the other counter linked

> Radar altimeters used in civil and commercial aviation operate using either unmodulated pulse radar or frequency-modulated continuous wave (FMCW) radar technology, with FMCW being far more common among models developed in the last few decades. In either case, the above ground level (AGL) altitude of the aircraft is measured in the radar altimeter by transmitting radio frequency (RF) energy down to the ground and receiving a portion of this energy back through reflection off of the terrain or other obstacles, and determining the round-trip propagation time of the RF energy. The radiated power levels are low, typically on the order of one watt, and thus highly sensitive receivers are required for radar altimeters to function properly. As such, radar altimeters are highly susceptible to RF interference entering the receiver, which can negatively impact their performance.

The planes use the band to bounce signals off of the ground and that needs to be super sensitive. That's why they probably can't afford to properly filter within the 200 MHz guard band.

With GPS you can measure time with <100ns person.

> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits.

This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in?

Not to mention that another benefit of an index is being able to change commits and git replaying your working diff.

Do you imagine how long it would take to compile the Linux kernel if it were rust only? Not to mention the kernel has to allow for third party closed source stuff like drivers, wouldn't that force you to allow unsafe Rust and put you back to square one?

I'm confused, enterprise users probably won't get ads either way,

> writing explanatory code comments in natural language is seen as unnecessary

It IS unnecessary. Having to write a wall of text to explain what your code is doing is one of the simplest code smells.

A little bit of very short comments is ok, but in general any verbose comment should always be for explaining the why, listing out some invariant, etc.

As a side note, another reason not to write comments about what the code is doing is because those comments then need to be updated too - and often they would not be leading to more confusion.

> ML breaks down such classifications. Finding a fruit without having already figured out that it's a banana is pretty hard.

Can you elaborate? If I train a fruit detector that just gets the fruits bounding box vs a fruit detector and classifier, are you saying the latter will work better?

Apples codec is for the hands free profile (synchronous mode). Are you saying aptX works with that?

Not at all for software. You have many resources to do your do diligence and figure out what's the range. For top companies it's okay to put off the compensation talks for later.

Lol verifying with small amounts takes like 5 extra minutes, messing up and having to jump through hoops to fix your errors will take days, especially if you do it on weekends or holidays. And they may not be reversible easily, e.g. IIRC one bank accidently paid off the loan of one of their boderline-default customers to another bank and then couldnt get the money back.

+1 when I write code I always think about how my reviewers would perceive it before sending it over and I refactor based on that. You should aim to write code that's easy for others to follow.

Unicode has more than enough space and text is rarely a blip on the amount of traffic carried on the internet, emojis are fine.

> have certain amounts of time which they need to take in order to tie voltages high or low, to either read or output a bit.

When you overclock you add voltage which helps with this which goes a long way. You would often hit thermal limits first, so heat dissipation is a major factor.

I think a nuance people are missing is that for big O, it is sufficient for the existence of any positive C and x, but for small o there must always exist an x for every c.

> Obviously that doesn't imply you should do this everywhere. I'm just pointing out it's not "wrong".)

I have to disagree here. const-int everything except stuff truly needs to be optimized significantly helps with readability, and when someone is updating their code they can other be warned of invariants if they inadvertently try to modify something that is const. Yes, it's a little verbose but worth it IMO. It also helps the compiler :)

The direction is opposite IMO. As you grow bigger on prem starts making a lot more sense.

A big reason for joining startups, even with a lower offer, is the IPO upside. I was wondering if that was relevant to your case.

> Do you really think we, with a real world distribution of programmer abilities, could do all this without massive division of labor? How much would be missing if we insisted on understanding everything before we use it?

I agree that you don't want to spend time becoming super familiar with everything that you use but you should ALWAYS have a high level idea of what's happening under the hood. When you don't it inevitable leads to garbage in garbage out.