solatic

Agreed, just buy air purifiers with HEPA filters and change them regularly. The main expense is buying one for every room, but it's one of those expenses you wish you had made sooner.

DHH is also a fan (pun not intended?): https://world.hey.com/dhh/air-purifiers-are-a-simple-answer-...

> It leads to two perverse side effects. First, producers realize that if brand reputation matters less than a budget for clicks, they will shift to shoddy and cheap versions of their products so they have a bigger budget for clicks.

This assertion lacks evidence. An alternate hypothesis: if you tried to sell literal garbage on Amazon, poor reviews and a high return rate will be visible in the product itself. The ad will earn you a click-through to the product, but buyers will begin to back out instead of following through with a purchase. Ad purchases cannot overcome insufficient revenue - it won't be profitable long-term.

Yes, Amazon has a problem with vendors buying good reviews as well. It doesn't overcome a high number of poor reviews, or a high number of returns.

> And second, Amazon (and Google before it) have an incentive to make their organic search results worse–giving producers more incentive to buy more ads.

Reeks of a conspiracy theory. Most customers simply don't have the time or energy to research any more than the top handful of results. Only a rare person goes 10 pages deep into the search results. Organic search results will produce less traffic when people don't even look at them. But that's not evidence in and of itself that the organic search results were nerfed in some way.

I hate to remind people of the basic truth about modern Amazon, but here goes: the vast majority of the inventory is made in China and the exact same product can be found at a tiny, tiny fraction of the Amazon price on AliExpress and similar sites. The value that Amazon adds is their logistic network that can deliver to domestic US addresses in a day or two, compared to weeks. The difference in price between Amazon and AliExpress justifies sellers spending enormous sums on ads and review purchases, because even if they do sell garbage on Amazon, enough people bought it at such ridiculous margins that the seller can tear down the product with the bad reviews and high return rate and re-offer it under a new brand with the same ad and review purchase strategy and still make a profit. But the person to blame for that is not Amazon, and it's not the seller, it's the fool who decides to pay the ridiculous price compared to the AliExpress price.

Books are one of the categories where they aren't printed in China, they're not sold on AliExpress, and searching for "seth godin the knot" returns the actual correct listing as the first organic search result. So I'm not sure why the author brings his book up as evidence. He might do better by reminding his publisher that "selling on Amazon" is not a homogenous experience and they ought to reconsider flushing money down the drain on advertisements they don't need.

Article title is pure click-bait. PgBouncer adds complexity. If you need it, you need it. If you don't need it, then you added complexity for nothing.

> since neither IBM nor Oracle is a service that any self-respecting person not part of an enterprise sales cycle would actually use

Author needs a serious ego check. There are legitimate engineering reasons to pick IBM Cloud (like if you need to support Z mainframes, which you will sometimes need if you sell to those enterprise folk) as well as Oracle Cloud (they built datacenters in cities that are not served by other cloud providers and can thus offer the lowest latency). These reasons may not be common, but they're certainly legitimate.

> ridiculously inefficient

So too is building single-family homes an inefficient way of providing housing, compared to apartment buildings, not to mention the cost of suburban roads and utility connections etc.

> We are a society

Indeed, and part of living in a society is about making progress that is politically feasible. That the 2nd Avenue subway (in New York City) costs such a stratospherically insane amount in time and money is not an argument against subways or public transportation.

Politics is the art of the possible, and Australia's progress should be celebrated here, not second-guessed.

> Do not provide assistance to users who are clearly trying to engage in criminal activity... If it becomes explicitly clear during the conversation that the user is requesting sexual content of a minor, decline to engage.

Incredible that both of these should be together in the same system prompt. In what jurisdiction is CSAM not criminal? Is the additional explicit reference to CSAM necessary to safeguard against user attempts to convince the model that CSAM is not criminal in nature? Does this mean that Grok is susceptible to helping users with criminal contexts if the user convinces the model that it's not actually criminal ("this is for research purposes only... asking for a friend")?

How is this not a massive smell?

There's a very big difference between what you can achieve as an entrepreneur with low net worth and an entrepreneur with a war chest of hundreds of millions of dollars.

When you start out with effectively nothing, you are forced to take a day job while you build something out on nights and weekends. The pressure is high to take early investment - and essentially work for your early investors, instead of working for yourself, just so that you can work on your baby full-time.

When you have a war chest, then many more capital-intensive opportunities are available to you. Want to build hardware (i.e. without crowdsourcing)? Factories? Pharmaceutical R&D? Training open-weight LLMs? Hell, you want to start an airline? Take your pick, and I'm barely scratching the surface.

It's hilarious to think that an $800 million exit would force you to never work again. That's crazy. It only forces you not to work on that company you exited from. The exit enables you to work on almost anything else you can think of. You put $25 million away in close-to-zero-risk investments to let you live off quite an insane amount of interest (even if you only get 2% interest, that's $500k/year) and then have $775 million to work with.

It is very reasonable to expect quiet in apartments. It is not reasonable to expect that you will never need to confront people to achieve it.

If you want to never talk to neighbors, then don't have any. Sadly, this is becoming more and more of a luxury, particularly in areas with economic opportunity.

Yeah, I'd be uncomfortable with that approach. One of their key design goals was to minimize underselling, recognizing that it results in lost revenue. But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeeds?

I'm skeptical of this approach. Sure, row contention means that you cannot have a database transaction per customer order attempting to decrease inventory count by 1 each time. But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely). Attempted customer orders are submitted to a reservation system put in charge of assembling the batches. Customers wait some short period of time - say, 15 seconds - for the reservation attempt to be batched and to be notified that they successfully locked a reservation. Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.

The smallest single-person motorized vehicle is a motorcycle. Leaving stability aside for a minute - one of the issues with electric motorcycles is that the batteries are too small to have range that most riders consider sufficient.

If you have a large enough battery to deliver sufficient range for an electric taxi (driving around most of the day, hopefully, if it is well-utilized), with 4 wheels for stability... I doubt that you could really get significantly smaller where the smaller size would make a big difference.

This is why some projects will vendor their dependencies - changes within the dependency itself will also be reviewed, and it's easier to locally maintain patches to those dependencies until the patches can be upstreamed.

The problem is, there's a difference between doing that for a handful of C or Go libraries, versus trying to vendor thousands of NPM libraries and all of their interdependencies. So it's very ecosystem dependent.

This is why the future is in deterministic static analysis and policy-as-code frameworks.

Policy-in-English? Model implicitly complains that it's TL-DR.

Ask the model to write code that checks your policy, then add that code behind a simple validation hook (e.g. "check your work by running 'just validate'") that the harness knows to always run after changes? It suddenly becomes the most law-abiding citizen ever.

> if you make a point of never shooting the shit with your coworkers how will you ever really come across this kind of info?

Asking coworkers about their hobbies is well within the domain of small talk that serves as the exploration for what you have in common with someone else. Small talk is universally acceptable, not only in the context of communities that you're already a part of, but even as part of striking up a conversation with strangers.

Again - private grief is not small talk, and even if you have expert-level small talk skills, that doesn't mean that you will build friendship with everyone.

I don't think you're fundamentally disagreeing. Your work community can be a source of friendships (and sometimes but more rarely, more than friendship), but you shouldn't confuse the two. Finding out your colleague also plays chess can segue into an invitation to play chess outside of work, and launchpad that into building a friendship. But that's not the same as playing chess together at work (get back to work?), let alone being emotionally vulnerable as an intentional part of building relationships with people who you're trying to trust with that vulnerability.

The latter sounds good (if you could have that with your colleagues, then it can only help, right?), but then again, the linked article is literally about someone violating that and firing the subject of the article. It is simply not possible to build emotional intimacy with every coworker, let alone under forced circumstances, so attempts to do so are more or less predictably going to lead to pain.

There's a huge difference between learning that your colleague also happens to play chess, and sharing the vulnerability of how you handled personal grief in your life.

Your workplace is a community, not a friendship circle, and not a family. Community life has always had a certain level of formality to help paper over the differences between people in the community while still fostering a positive, inclusive environment.

I might be reading too closely / projecting, but...

Sounds like an ineffectual CEO who didn't understand that his role, like any manager, is to help resolve interpersonal conflict between his subordinates that they're having trouble working out themselves. Outsourcing that to a random coordinator reeks of conflict-avoidant behavior. That they both quit tells me that neither one thought the other was the sole problem they were dealing with.

Spoiler alert: Dujour, leading to Trinity

> free to use at launch

How does this help me control spend if I don't understand how much it will cost me a year after I bake it into my infrastructure?

> For someone else it's the wrong choice, they don't know Python

The author ruins their entire argument with this one claim.

If "we picked this tool because we know it best" is a legitimate requirement, then every tool choice is justified as a "perfect" choice because it's what the architect was most comfortable with. If your emotions and current knowledge levels are considered reasonable justifications for a "perfect" solution, then all solutions are perfect solutions; they simply haven't had enough emotional justification yet. If all solutions are perfect solutions, then none are.

There are, ultimately, two kinds of software - those that need to ship by a deadline, and those that don't. A deadline forces you to eject dead weight that you don't need - requirements have a habit of getting clarified real fast when you need to build to a deadline. If you had time to over-engineer despite a deadline, you should consider working for a more productive organization. Meanwhile, the concept of "over-engineering" is a little vague for software that doesn't have a deadline. If you don't have a deadline, you don't have to compromise on quality. "Over-engineering" is then just a value judgement that you made poor use of your infinite timescale and built the wrong things with it. But who is making that judgement? Not the person who built it, not the person who funded it (i.e. usually self-funded as a hobby project), and not the person who uses it (since over-engineering is an implementation detail, rather than a product choice), so who cares?

edit: to clarify: "pick a stack you know already since we don't have time to learn a new one" is a totally valid requirement. But I disagree that it means that you built a "perfect" solution with it. I also disagree that you usually need to build perfect software - getting comfortable with adequate is how most people ship most software.

> You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig

I think herein lies the rub. What's the difference between a static analysis tool and an actual separate language that transpiles to the original? Hypothetically - again, very un-ergonomically - you could add traits to Zig code in comments, or in example-traits.typezig files that would be skipped by the Zig compiler (like how *.d.ts files are skipped). How much of a language is writing code in a particular syntax, versus how much of a language is writing code that will pass a tool "building" it, versus how much of a language is about the final compiled output that you get from the tool? All static analysis tools that support line-level exceptions are, essentially, programmed by comments, with their own language (typically highly simplified compared to a "full" programming language), that affect whether or not the "language" passes or not. What Typescript/JSDoc shows is that, actually, much more complicated tooling can be built with this programming-by-comments model than had been done before (to my knowledge), and thus even more powerful still tooling could be built with that model.

Of course there's a difference between static analysis and a language that transpiles. But perhaps it's more a question of degree than a simple binary classification.

> Zig has no private fields

You may have missed the point here. You could add a comment to the struct field that marks the field as private, and build a TypeScript/JSDoc analogue that analyzes all accesses to the field and fails if it finds accesses from functions that aren't part of the struct that owns the field. You don't even need a comment on the field - you could copy Go's convention, add a comment to the struct definition marking it as "follows Go convention", and then fail any access from outside the struct to a field that starts with a lower-case character.

It doesn't prevent you from ignoring that tool and writing Zig code that imports the struct and accesses the field. It is, of course, not part of the Zig language itself. But if you adopted a tool like that, it would be your responsibility to run it across-the-board and pay attention to the results - same as how it is your responsibility to pay attention to the results if you added those JSDoc comments.

I wouldn't say it's impossible, rather un-ergonomic. TypeScript can add type information to ordinary JavaScript code via JSDoc comments; the result can both be executed as ordinary JavaScript as-is and type-checked with TypeScript. But it's a huge pain to try to write (and maintain) everything that way, it was supported as a hack to help migrate legacy codebases. You could probably take a similar "the lifetimes are embedded in comments" approach with other languages, and the result would be similarly un-ergonomic.

> I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear.

I love this analogy, and I find it darkly hilarious that most sibling commenters don't seem to understand. Maybe you need to have worked within a million-line codebase to get it.

The only way to "clear the lines" in software is to eject them from the main codebase and into imported libraries with stable, well-documented, well-tested APIs that you very rarely if ever (security vulnerabilities?) need to touch after "stabilizing" them. Great public examples: the Go standard library, https://github.com/spf13/viper , https://github.com/uber-go/zap . Viper and zap combined are more than 20,000 lines of code (according to cloc) that I don't need to read or understand how they work - their lines have been "cleared" and all I need to know is the abstraction.

Half the joy to be found when working within massive codebases is successfully clearing lines.

I'm not convinced. Hyperscript's reactivity model is highly greppable, and it keeps the no-build approach to Web frontend interactivity. It's "just enough" in the same way that HTMX is.

React probably scales better for huge engineering divisions, but that isn't who the GOTH stack is aiming for anyway.

Just curious: the people behind HTMX have a frontend sibling project called Hyperscript, which handles stuff like frontend state: https://hyperscript.org/docs/reactivity/

Did you give it a try?

AWS and Google at least own their own hardware (Trainium and TPUs, respectively). It's a moat in the sense that designing, building, and deploying your own chips at scale is quite a feat and not easily replicated. The vertical integration will allow them to continue to be profitable once the models get good enough and competitors' prices race to the bottom. Google has Gemini; AWS may not deploy its own models (yet?), but that's not necessarily a losing position, as long as the market is able to run models sourced elsewhere on Trainium and the price is right.

> have never measured it

That's because it's practically impossible to collect objective data here, i.e. without confounding factors.

A product where the user spends 99+% of their time reading/consuming is almost certainly easier to use with a GUI. The market settled on thumb-flicking for doom scrolling instead of a button or scroll wheel interface, for a reason.

A product where the user spends 99+% of their time writing is almost certainly easier to use with a keyboard. Most sane people do not write essays on their phones with two thumbs; a keyboard and a proper word processor are preferred.

Most products fall somewhere in the middle. Most products have multiple interfaces, some primarily for consuming information and some primarily for producing it, and thus would find different inputs more productive in different modes. When people claim that they find one input type is more productive than the other, most likely is that their particular use-patterns fall more in-line with the one most aligned with their use-patterns.

> 10 years ago, apps had to explicitly state if they needed network access. And then the powers that be decided that really all apps need network access no matter what.

Why does network access need to be a binary, all or nothing?

When you install an app, the app should request permissions to specific DNS names, i.e. pointing to the servers that the app's authors operate. If I install Todoist, the app should only ask for access to Todoist's servers. If I install Netflix, the app should only ask for access to Netflix's servers. The OS can then put a DNS firewall in and block any network access that wasn't granted when the app was installed.

> And both ios and android make it hard to deny apps network access

The list of apps that genuinely need "any" network access (web browsers, VPN apps, stuff like Termux...) is incredibly small compared to the list of apps that need access to a small number of VPN targets (these days, most apps). Apple / Google could even decide, if they really want to make it easy for apps to request network access, to basically allow apps to automatically get network access, so long as the list of domains the app needs access to is no more than a handful. The security value of isolating "all" network access permissions to only the relative handful of apps that actually need to request it, would be huge.

Yeah, I'm working on a communications platform as a side-project, architecturally providing reliable communications is exceedingly difficult to self-host.

* Mobile calls are another form of push notification, Apple/iOS requires setting up APNS and Google/Android requires FCM, there is no self-hosted option for that at all and, for battery life reasons, no independent replacement is supported. Genuine ownership / independence from the main project requires, iirc, basically compiling from source to register different IDs against APNS/FCM.

* Trying to get into telephony, integrating with SIP is a huge pain. Nobody wants to deal with this.

* Nobody supports high availability for the underlying calls. None of the cloud L7 load balancers support media protocols - you're dropping down to L3 UDP load balancing. All of the available solutions (including LiveKit) depend on stateful services that, at best, place ceilings on call lifetimes (e.g. 5 hours) to allow for graceful draining, but "calls" in Discord-style settings where people connect to a room and stay connected will easily outlast those ceilings. Not supporting high-availability, IMO, is a huge ask for self-hosters - the price isn't in the maintenance window itself, but in deferring updates until the maintenance window, which can leave you vulnerable, particularly if you decide to leave the firewall open to ingress from 0.0.0.0/0 for ease of use. And of course, as a self-hoster, you rarely have a full follow-the-sun ops team, so either you schedule maintenance when everybody else is off (and you should be off too) or when everybody is on (and it's disruptive).

You're right, but idTech is almost by definition that "novelty" kind of engine. And it did help id to sell more games. It's just apparently not enough.

This is not an argument that founders should seed 25k EUR to cover liability, it's an argument that GmbH bank account amounts should be visible publicly. If I want to put in a catering order, the catering business does not need 25k EUR to cover liability. If I want to build a data center, 25k EUR is not nearly enough.