avl999

I was recently in India a few weeks ago for a friend's wedding. I am not an Indian national/citizen/whatever and my experience related to anything tech and money was absolute awful (esp the obsession with OTPs)

* The problems start as soon as you land at the airport. I land at the Delhi airport, my friend has sent a driver to pick me up and gave me his contact info. I try to connect to Airport wifi and bam it's asking me for an Indian number to text an OTP to connect to the public WiFi. Why is having an indian number at the Delhi INTERNATIONAL AIRPORT an expectation? What do they expect foreign travelers to do? Ridiculous. Luckily I found someone and asked to use their phone to whatsapp the driver and figure out where he was.

* Foreign credit cards are hit and miss. I have 2 credit cards, I let my bank know I would be traveling and I still could not reliably use them, they worked maybe a fraction of the time. Apparently Indian government added some "security" requirements earlier this year to "prevent fraud" that ices out a large number of foreign cards at many payment tills. This essentially makes India a cash-only economy for foreign tourists.

* If you try to use your foreign cards while shopping, many places will ask to send an OTP to your (indian) number even for relatively small amount of money involved, and again as a foreigner you are out of luck.

* Since I can't use my cards reliably, I am now forced to carry around cash. Worse... the highest denomination available is 500 rupeees, which is equivalent to about $6. This means that if you are planning on doing any type of shopping as a foreigner you have to carry a fat wad of cash on your person the entire time. I intended to do some shopping, eating out and drinking which meant I had to carry around 20,000 ruppees at all times, which was neither comfortably due to how fat that wad of cash is, not relaxing as I am constantly worried about losing it.

* I finally decided to get an Indian phone number to get around all the OTP nonsense and get some data while walking around. And bam to get an Indian sim card you need an indian ID or as a foreigner go through an application process involving a bunch of documentation (and not trivial documentation, requirements like a picture that matches the exact dimensions accepted by them) and it's not a quick process. Red tape upon red tape to get a sim card for normal usage! Thankfully, someone helped me out with a SIM card they purchased via their govt ID and gave it to me saving me the pain.

* The pain doesn't end here. After I get my sim card, I realize I need to buy a bit more data. Easy enough I think in my head... there's even an app from the provider! I pick the upgraded plan and try to buy via my credit card and boom, international credit cards are not accepted for e-transactions. I literally just want to give them the equivalent of $10 to get an additional 25 gigs of data and I can't do it online. Again, I asked someone to buy it for me and paid them in cash.

* Then I wanted to buy a friend a gift that is only available on Amazon. The red tape strikes, apparently as of this year Amazon India can no longer accept foreign credit cards as methods of payment due to "security and anti-fraud requirements" by the indian govt. Again, I have to find someone to buy it for me from Amazon using their card and pay them cash for it.

The bad is that everything is so needlessly complicated and red-tapey for foreigners. Things that should be trivial are hard.

The good is that you can always find someone to help you circumvent the red-tape by paying them cash :).

> But in such cases surely there's some kind of rate limiter in place?

Not really, our team maintained a reverse-proxy that fronted all requests that came into amazon. And whenever we would have a self-ddos event, we'd get a request from the backend team whose service was getting self-ddos'd to shed traffic before it reached their service hosts to prevent it from browning out. In many case ddos's were coming from kindle devices which were not even easy to update so deploying a "fix" wasn't even always an option.

I am not disagreeing with you but self-ddos is not entirely uncommon. When I worked at Amazon this would happen a few times a year. Not on the main amazon.com website but on supporting services often initiated by but not limited to kindle devices. Having something like this slip through the cracks of even experienced engineers isn't uncommon.

First thing I would try is seeing if the front end has a different retry strategy for a different status code (say 503). If so I'd change the status returned for throttling to be that (503).

Barring that, turning off server side throttling or atleast making it less aggressive to slow the retry storm seems the most reasonable.

> If it’s a conceptually complex system then the devs weren’t really that good in the first place.

Spoken like someone who has never worked on a sufficiently complex system.

Exactly, severance was absolutely a no brainer based on that email. I have gone "hardcore" many times in my life working crazy hours but all of that has either been in exceptional circumstances or me doing it because I was having fun. If someone emailed saying that "going hardcore and crazy hours" is the baseline for acceptable performance (note, not even good performance, just acceptable performance), I'd be outta there too.

I feel bad for all those who are on visas though and may not have the flexibility to accept the severance offer.

I didn't want to use that word but that's the only thing that comes to mind describing what you are saying.

Why in the world would you find it acceptable to work at a place where the baseline is extreme hours and where extreme hours are required for just an acceptable performance review if you have other options?

I have worked extreme hours in many jobs but that has always been because either it was an exceptional situation or I was doing it of my own accord. Other than those two situations the only other reason I would do it is either:

1 I am working at a startup (preferably it's my own or I own a lot of equity)

2 I needed the job that badly

3 There was some "higher mission" associated with the work (eg manned space travel to mars, rushing to find a vaccine)

2 doesn't apply to twitter engineers and 3 certainly doesn't apply since twitter whose "higher mission" is selling ads.

If you are willing to work significantly over normal work hours, for market value pay for a company with no greater mission beyond selling ads so that Elon can service the interest on his debt then by all means go for it. That is literally cuckold behavior but some people are into that so if that works for you good for you.

I know my value and won't work in that type of environment.

`&varName` is not equivalent to C version of the superficially similar looking operation.

I reject PRs every day at work with varying level of "badness" and it works just fine. Normal people can put 20 seconds of thought and come up with a response that explains why a patch is unacceptable without resorting to name calling, even in this PR response Linus does that for the most part but in the end just can't help himself from throwing in a couple of petty jabs. There are other open source communities where this behavior would be unacceptable (for example the GoLang core team).

I am calling this out because Linus specifically said that he wants to handle himself better in public, he is aware of how he comes across and wants to change, it is not an RMS type situation where the guy has no self-awareness. Reading the rest of the thread I bet he regretted his response esp considering the response of the branch maintainer.

There is nothing wrong with rejecting the patch... there is something definitely wrong with calling it "unintelligent" and "idiotic". Esp since a year or two ago Linus publicly committed to toning down some of his more toxic behavior.

The article links to this PR comment by Linus https://lwn.net/ml/linux-kernel/CAHk-=wie+VC-R5=Hm=Vrg5PLrJx... :

> End result: no way will I accept this kind of completely arbitrary and frankly not very intelligent patch.

> If people want to disable console printing, that's THEIR CHOICE. It could be a new config variable where you ASK people about what they want. Not this kind of idiotic tying together of things.

I thought Linus had committed to changing how he behaves in public forums? Even if he didn't like the patch, calling it "unintelligent" and "idiotic" doesn't accomplish anything. He could have just left the rest of the comments in there without using inflammatory language and it would have the same affect.

My reading of the situation is that India is not necessarily pro-Russia, instead its position on Russia vs the West and Russia vs Ukraine is to quote Trump "very fine people on both sides" which may be problematic in of itself but is less red-flaggy than "pro-Russia".

My point is that Linux is a great desktop environment and people shouldn't write it off based on isolated complaints from people for whom it didn't work for as there are a lot of people who never encounter these issues that keep getting brought up in these threads.

Designing Data Intensive applications- specifically chapter 3 and 4 which deal with strategies and algorithms for storing and encoding data to be stored on disk and their pros and cons.

Once you read that, I'll suggest reading the source of a simple embedded key-value database, I wouldn't bother with RDBMs as they are complex beasts and contain way more than you need. BoltDB is a good project to read the source of https://github.com/boltdb/bolt, the whole thing is <10k lines of code and is a full blown production grade system with ACID semantics so packs a lot in those 10k and isn't just merely a toy.

> - only one speaker works so volume is low

Never had this issue.

> - finger print scanner doesn’t work

Can't speak for this as I don't have a device with an FP reader

> - battery life is poor compared to Windows on same machine

I get ~6hrs on my laptop running Ubuntu + XFCE. I haven't ran windows on it but Amazon reviews claim ~5-5.5 hrs battery life for the same machine so seems to be inline for me.

> - suspend and hibernate doesn’t work

Works for me

> - random freezes

I can think of only 1 freeze I've had in the last year and that was due to me dropping the laptop

> - charging indicator unreliable

Pretty reliable for me except when it comes to the last 5%... my work macbook pro seems to have the same issue though when predicting how long that last 5% will last.

> - boot failures after OS updates

Never had this problem, on the other hand our work macbook pro has nothing but problems when upgrading os major versions. Atleast 1-2 people on our team always end up losing an afternoon whenever we are forced to upgrade it.

> I have now switched to a Mac with Apple Silicon.

> I really tried with Linux for philosophical reasons, but honestly what professional developer has time for all this?

What professional developers have the time or patience to deal with a Mac with:

* It's proprietary hardware without any ability to upgrade components

* Garbage oversized trackpad which registers false positives all the time

* Terrible built in keyboard

* All the nonsense with "we have a physical escape key, now we don't, now we do" actively making it unusable if you use Vim/Vim key bindings

* Whatever nonsense they have done replacing physical function keys with that touchbar thingy

* Actively user hostile decisions like putting the headphone jack on the right side of the laptop

* A complete inability to connect peripherals unless you buy a (often expensive) dock.

* Docker being a complete hog on these machines, yes that is not the fault of the mac but still something developers have to deal with every day

I am forced to use a macbook for work and the only reason I can even bear working with it is connecting it to external keyboard/mouse and using it in clamshell mode.

Shellcheck https://github.com/koalaman/shellcheck : Shell scripts are unavoidable, you have to write one every now and then but shell is a terrible language with massive footguns around every corner. I don't write shell scripts extensively enough to remember all those footguns and even if I did, not sure I'd want to waste brainpower remembering all that archaic trivia.

Shellcheck makes writing shell scripts bearable and dare I say somewhat enjoyable. They have managed to collate all the shell scripting potholes and tribal knowledge into one static analysis tool. No shell script now gets checked in at work or on my personal machine without being pumped through shellcheck.

SQLite, KVM, Firecracker, GraphQL, Serverless... if this was written in Rust it would hit the holy trinity of all the HN buzzwords that pull a post to the frontpage ;)

With that setup you have essentially lost any benefits that SQLite provides, specifically any performance benefits by making a DB read/write a network call instead of a local call in the same process that manipulates some file on the same machine. You are closer to a postgres/mysql patterne except now your writes don't scale as well. What are we actually gaining with this setup other than perhaps easier administration of the "db service" compared to a mysql/postgres deployment?

I wonder how an alternate timeline might have played out if Richard Hipp had not named it "SQLite" and instead called it "SQLightning" or "SQLExpress" or something like that. For much of its lifetime, SQLite wasn't taken seriously despite being an extraordinary technology and part of me is convinced it was in large part due to "Lite" being in the name.

Software isn't written once and left to run in production for it's lifetime, it is constantly being iterated on and changed. And a lack of tests will inevitably result in a slowdown of the rate you introduce new features as now you need to spend longer convincing yourself that the change you made didn't inadvertently break something else (plus rolling back and outages that will result from such an event).

Most tests written by people working on the product will of some baseline level of quality and even if they weren't, even if they were "bad tests". It is much easier to fix bad test than it is to deal with an application on a day to day basis which has no tests.

Only the most religious TDD evangelists will force you to "drive the design" using tests. That advice is not relevant for most developers except for perhaps absolute beginners who don't have the experience or mental models to determine what a good design is and TDD might force them to come up with a decent design by the sheer fact of making their design testable, which alone goes a long way (but not necessarily all the way) in making a "good design".

Most experience developers will come up with the architecture/design of what they are working on through a combination of intuition and experience, write tests after and then use TDD to fill the gaps once they have nailed down the architecture.

I do TDD some of the time and my workflow often look like this:

1. Start implementing an object/class, defining APIs of its key methods while having a higher level picture in my head of how it will fit with other components

2. Implement a good chunk if not all of that object (not more than a few 100 lines typically)

3. Write a test to verify that what I did worked.

4. Start commenting out parts of the code I wrote to make sure the applicable test cases fail. Uncomment after verification is done.

5. Use TDD to cover and implement edge case handling and anything leftover

6. Repeat 1-5 for each class/component/module until done

I only get into TDD once the architecture and high level design are finalized, and I have some code written for them and I have some reasonable level of confidence that it is not gonna drastically change. I also generally go "bottom-up" starting from the leafs of the object graph up and use TDD maybe ~50% of the time (just a rough guess).

Trying to force yourself to let "TDD drive the design" will likely result in frustration as you have experienced and slowdown.

> How do you implement healthcheck?

> Does the loadbalancer know how the healthceck is implemented?

Write a ping/sping endpoint like people did pre-Kubernetes? LBs provided by Cloud provider all have a trivial way of setting a healthcheck endpoint. If you are not in the cloud, nginx and HAProxy make it equally simple to configure a healthcheck. There is no k8s secret sauce behind healtchecks.

> How do you determine it's time to scale?

Monitor relevant metrics (CPU/Memory/DB), have alerts and add new vms or whatever when they hit a specified threshold. Or use your cloud provider's "elastic scaling".

> How do you implement always-on-process? service unit, initd, cron?

Yes. And the problem with that is? Processmanagers have been around forever, are simple to use and a well understood technology.

> How do you export the logs?

Cloud providers generally have a built in mechanism for pumping logs out, if you are not a cloud provider log export daemons exist that much simpler to work than running k8s deployment.

> How do you inject configs? /etc/environment, profile.d, systemd config, /etc/bestestapp/config?

Do whatever your organizations feels comfortable with... config files, json, .properties files, env vars whatever, it doesn't really matter, since the code needs to be aware of the configuration mechanism anyways it doesn't make a difference. And again not worth the tradeoff of running full blown k8s deployment with its significant complexities

> What about secrets?

Cloud providers have convenient ways of solving this problem without involving k8s. If you are not on the cloud one can use cloud secret solutions (AWS Secret Manager, Google Secret Manager, Cloud Vault). All of which are much simpler to use than k8s secrets

> Service discovery? Is unbound/bind9?

DNS works well enough for most projects. Static configuration which lists domain names of whatever services you depend on (which are behind a load balancer) likely works for 90% of all applications.

I am not trying to be argumentative just making a point that "standardizing" all these things you mentioned "the Kubernetes way" are not worth the significant complexity of running and managing k8s for most organizations. And certainly, non-k8s ways of doing these things are much simpler to reason about for developers. A team of 2-3 developers can handle of these things and be able to keep the entire state of their system in there head, whereas with k8s it is suicide to have a k8s cluster without having a dedicated devops team.

And I disagree that there needs to be an industry wide standard of doing these things in the first place (and certainly not a standard like k8s that adds mountains of complexity). The standardization if needed, needs to happen at a team or organization level. Individual organizations should be free to pick and choose how they solve these problems rather than be pressured into the complexity of k8s.

What is frustrating is TDD evangelists insisting everyone do purist TDD in their regular development (like the guy being quoted in this article).

You set your standards as a team of what you will consider acceptable tests and as long as the dev submitting the PR meets that standard why does it matter if they did TDD or not? TDD is a means to end, it's not a religion. As long as you write tests that meet the standard it doesn't matter when you write those tests.

The level of micromanaging that TDD evangelists seem to want in people's workflows is infuriating. It's literally cultish.

Edit: I realize this came across more negative and abrasive than I intended. I think TDD has some good parts (primarily around gamification of writing tests and giving a serotonin hit whenever a test goes from red to green). I practice TDD around 50% of the time when appropriate, but most people who have worked in the industry that TDD as sold by purists is impractical and adds negative value.

I am practically incapable of navigating without GPS/Google maps.

Using a JetBrains IDE (or whatever IDE) + Vim plugin is the best of both worlds. Writing code is composed to two tasks:

1. Pure Raw Text Editing: This stuff like jumping around within a single file, making edits. Vim really shines here with keybindings that become muscle memory & are portable cross platform- for example I am forced to use a Mac for work but use Linux for my personal stuff, the keybindings for the exact same tool are often different between mac and linux. Vim really shines here

2. Work that requires you to consider the language AST: Stuff like refactoring- renaming something through the entire codebase, jumping to definitions and implementations, auto-completing symbols. This is where I fall back to IDE features as they are unambiguously better at it than Vim. (Yes I know you can get this type of stuff kinda working in vim but it has never worked well enough to my satisfaction... you have a to install dozens of plugins, often a plugin for each language that you want syntax support for which adds bloat and in my experience I have never gotten them to work quite right in a reasonable amount of time)

I am not saying it's UFOs but many of the UFOs observed by the US Navy/Airforce were spotted on top of oceans and many have been reported to "disappear" into the ocean. The famous Tic-Tac UFO for example notably disappeared "into the ocean".

This also results in easily breaking production.

In 2022 there is no reason to prefer these dynamically typed languages over statically typed ones for production code. When languages like PHP, Ruby, JS blew up the knock against statically typed languages was the verbosity of the resulting code, slow development cycle and general cruft, these languages solved a real problem at that time. That is no longer true today- TypeScript, Go, C# code feels as fluid as a dynamic language and even Java has come a long way with type-inference that Java no longer feels as unwieldy as it used to.

I legitimately can't imagine willingly not using a statically typed language for anything that matters that's gonna have more than just me working on it.

Why do front-end developers have such masochistic tendencies to put themselves through this kinda crap?