Orou

Are there any major benefits to using Tailscale over vanilla Wireguard?

> This cycle of having a few years where the costs of an approach aren't acknowledged, to a few years where the benefits aren't acknowledged, is very lame.

Well said. I do sympathize with some of the criticisms but only insofar as people who didn't have experience with microservices get sold on a lot of hype, the tradeoffs aren't made clear, and they get burned. The cycle seems to be "This is the silver bullet for programming complexity!" for a few years, followed by a few years of "This isn't a silver bullet!" before the Next Big Thing (TM) comes along and the cycle starts over.

> The more hardcore UBI defenders talk about paying Malibu surfers to surf all day, or to write haikus

I've been following the UBI space for a long time and I've never seen anyone use this as an example - that's just a strawman. What people discuss is the work that is valuable to society but is unpaid such as raising children, caretaking for the elderly, community support, and so on.

A few hundred dollars a month isn't enough to live on, but it moves the needle for those most at-risk for going hungry or becoming homeless. And for everyone else, it gives extra breathing room and negotiating power in the workplace.

Anyone who's had to parse free-text international addresses can tell you that this is terrible advice. People type things into computers incorrectly all day long. We prompt users to select things like country from dropdowns with good reason. Imagine having to delete user data for GDPR compliance and needing to determine which of your 1,000,000 users are in the EU from a free-text field. Oh, this user wrote "Czechia" instead of "Czech Republic"? What do you mean they wrote the name with accents? Oh they wrote the name in their native language and not English? Have fun parsing all this:

https://en.wikipedia.org/wiki/List_of_country_names_in_vario...

This makes me really curious about how people with legal mononyms (Ye, Cher, etc.) have their taxes filed or medical forms filled out.

> always just about 'good enough' to solve the issue at hand

I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.

You're not missing anything, the argument is for how long this duration should be.

The lifetime of the original creator plus $YEARS should be more than long enough for the original work(s) to be made 'canonical'. How is a corporation buying up an IP because it is profitable going to guarantee it remains true to the original author's intentions, or to the desires of fans? If we care about the consumer they should be free to engage with the original works or any derivation thereof as they choose. IP isn't about expanding consumer choice, it's about limiting it - and it certainly isn't a mechanism for guaranteeing the ongoing quality of a series.

I agree libraries are great when dealing with very specific domain problems (who wants to hand-roll a datetime module?). But there are also a ton of libraries that aren't for such specific domains or which attempt to bridge multiple domains (i.e. frameworks).

The argument made by functional languages like Clojure is that by making heavy use of pure function composition, you don't actually need a million libraries to build large/complex systems. You can do it with a much smaller number of libraries where necessary and take advantage of the language's natural extensibility for the rest.

Is the interleaving of redis and db transactions atomic?

The author of Noria, Jon Gjengset, gave a great talk about the system: https://www.youtube.com/watch?v=s19G6n0UjsM

The speeds achieved are impressive but you do not get consistency.

I was just reading an article earlier today on the same subject. I thought the "pedagogy" section was interesting when considering if `mut` is the right term to be using for exclusive references.

https://docs.rs/dtolnay/0.0.9/dtolnay/macro._02__reference_t...

> I would strongly advise against using python for anything other than PoC/experimental endeavours.

I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.

> it forever mystifies me that it isn't standard

I can give a few thoughts on why here:

- it doesn't work for collaborative efforts unless everyone is using the same linter or IDE with the same configuration. Not friendly to edits outside of that ecosystem (e.g. open source). - there are other ways of writing SQL (e.g. dbt style guide) which are still very readable while also being much faster to write by hand without the need for an auto-formatter. - some of these patterns such as the from and join indentations have nothing to do with readability and are purely stylistic. Nothing wrong with that, but there's nothing objectively better about this pattern - it just comes down to how you're used to reading SQL.

Wholeheartedly agree with this. The problem isn't aliasing, it's lazy aliasing which is more I think what GP was referring to (e.g. emp.id instead of employee.id).

> Separation of "developer" and "user" is artificial and more should be done to recognize that.

I've seen some company ROI models built in excel that I think would change your mind about this.

Most ML requires collecting, cleaning, and transforming datasets into something that a model can train on for a specific domain. Codex and Copilot aren't good examples of this because they are training on terabytes of public code repos - meaning that there is no code cleaning step. It's relying on the sheer volume of data that is being processed to try and filter the 'unclean' data (think buggy code written by a human) out of the model.

These are really the exception rather than the rule when it comes to collecting data for ML/AI applications.

This is right on the money. Everyone wants to do new and interesting work on a product, which naturally means changing things even if it isn't really an improvement. No one is going to put "maintained system that wasn't broken" on their resume.

One thing that has likely exacerbated this issue in recent years is "data-driven" product design. While I'm fanatical about evidence-based decision making, so many of these products are designed around a vague concept of "engagement" which is all about getting users to interact with the app as much as possible. While this is the natural end state for ad-driven companies, I find it very frustrating that a subscription-based service like Spotify feels the need to take as much control away from the user as possible.

If you're used to writing embedded code then I'm not surprised - you want to be able to fully introspect everything that is happening since understanding performance is so important.

Syntactic sugar is often better in high-level languages because it provides a level of indirection and allows for more flexibility in API design.

Mikovits' claims are bold-faced lies regardless of your opinions on the pandemic.

Probably the most hilarious claim from that video was the line: "The controversial article sent shockwaves through the scientific community, as it revealed that the common use of animal and human fetal tissue were unleashing devastating plagues of chronic diseases".

None of that is true, her [research](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3073172/) had nothing to do with autism or vaccines. Many people tried to replicate her research, which contradicts her claim that she was being shut down by the government/big pharma/the boogeyman.

The fact that people don't care to distinguish between Mikovits and someone like Tyrone Hayes just shows how easy it is for grifters to take advantage of people's strongly-held opinions about the health system. Sorry to say, but if you buy into Plandemic just because you're critical of vaccines/shutdowns/whatever then you fall into that group, and you hurt your position rather than reinforce it by buying into such garbage.

Agreed. I'll admit I didn't notice it on first pass and just thought the Jim Morrison bit was sloppy writing, but reading it again it has all the hallmarks of GPT-generated text. It even talks about the etymology of the word "elite" for no reason!

If it isn't GPT-3, then it's writing at a high school level at best and shouldn't be on the front page.

> By contrast, most knowledge work today operates with no deliberate structure at all. Instead of carefully constructed processes to get the most out of each person, we just hand out tasks and leave people to organise themselves organically in whatever way feels easiest to them.

I've very much felt this pain in a few of my roles. I understand the need for this sort of many-hats-wearing, elbow-greased approach to solving business problems in a startup. But it's infuriating working in late-stage startups (or even mid-sized tech companies) that fail to get away from this 'throw people at the problem' mentality and spend the time and resources to explicitly define what the business' core processes are and how they work.

I know not everyone thinks about problems in terms of process flows, but it still drives me crazy!

The command line is much more productive for programmers. The entire issue with open source OS adoption is that these systems are not being designed with non-technical users in mind, and their GUIs are lackluster to say the least.

I really don't understand this attitude. It's like a woodworker talking about how much better handcrafted furniture is than the mass-produced stuff you'd buy online. Of course it's better! But does that really mean the answer is for everyone to spend years learning furniture-making? Same goes for computer systems: most people are not, don't want to be, and never will be technical users.

If we want open-source systems to beat closed-source, consent-engineered spyware from dominating people's online lives then we need to meet them where they are.

I would also vote for "data engineer" (it's my current job title).

You very likely don't want a data scientist to be doing a data engineer's job (and they probably don't want to be doing it themselves!). While there are similarities, data engineering tends to be a lot closer to software development than data science. If you're advertising for a data scientist role, don't expect them to be happy if 80% of their job is writing ETL scripts and cleaning datasets.

I think the reason there has been a flattening in data scientist job growth more recently is that lots of companies hired data scientists to build cool ML applications but had no infrastructure in place to support advanced data analysis. These companies didn't realize they needed to walk before they could run, and that what they really wanted was data analysts and engineers to build the foundation for a strong data science function.

Tools like dbt have been great for advancing an ELT approach to managing data pipelines, where modeling for BI tools, business users, and data scientists alike can all happen in the warehouse and ensure consistency in data usage across the company.

Genocide was committed on both sides, and from a purely numerical standpoint the Haitian slaves had it worse. Why shouldn't France have been forced to pay back Haiti for the enslavement and genocide that it committed? Or should we just forget about the Vicomte de Rochambeau and his attack dogs?

The Haitian revolution ravaged the new nation's economy. The machinery used to process raw materials for Haiti's valuable export products, in particular sugar and coffee, were mostly destroyed in slave uprisings, and they could not be produced locally. Haiti also lacked the natural resources necessary to develop an independent industrial base, and even if plantation outputs increased again (as many tried to make happen), luxury goods like sugar and coffee are only valuable as trade goods.

Simply put, Haiti was highly dependent on international trade for the resources it needed, which meant that the embargoes from major powers crippled the nation.

Mike Duncan has an excellent series on the Haitian revolution in his Revolutions podcast series, which includes a final episode that summarizes the history of the nation up to the mid-20th century.

Isn't it more intuitive for OP codes though?

You could just as easily argue that the owners of the building must be at fault because they have a financial incentive not to repair structural damage for as long as possible.

We can also look at this from the lens of outcomes if we lean too far one way or the other with our approach to safety standards - too strict, and we allocate money poorly. Too lax, and people die.

You can get travel insurance for extended trips. I'm American and I've taken multiple 6-month trips abroad (usually after quitting a job). Backpacking just isn't part of the American culture.

Naive question: in Python, isn't this solved by .copy and .deepcopy if you really have to get a copy of an object rather than create a new instance of something? I'm curious where the bad API design is, unless you're saying that Python's assignment behavior itself is bad and everything should be immutable by default.

Legitimate question: how useful is Google trends for understanding interest in a subject for other languages, or in regions where Google's presence is limited (e.g. China)?

This seems like a really poor data point when also considering that it shows relative rather than absolute interest in a term so we can't compare countries.