MerrimanInd

Like any opposition party, the anti big tech crowd is actually a loose coalition of different goals and interests. I've noticed that as these platforms get through the earlier stages of "will it even work" the differences in values are becoming more pronounced and controversial. The primary two groups seem to be those who value federation and see centralized control and algorithms as the threat and those who value encryption and see surveillance as the threat. Obviously these two things aren't mutually exclusive and we all want to see new platforms that can solve for both. But there's a quite distinct difference in the primary priority and consequent technical decisions.

I hope maybe if we can be aware that this is a broad set of technologies being driven by a broad set of goals then we can be a bit more gracious when a project isn't perfectly aligning with our personal values and find the common ground and values.

I'd go a few layers even broader than this article and say that the modern tech industry has an abysmal track record when building tools for non-software technical fields. Tech builds either their own software-oriented workflows or the most dumbed down consumer-oriented workflow they can. Law is an excellent example of a field with a very high degree of fidelity, philosophy, and process yet it can only ever have partial crossover with software development methodologies. Tech often treats someone like a lawyer as either a substandard developer or an advanced consumer without making a real effort to understand the context and needs of highly complicated yet non-software professions.

Yeah it is and that's a great effort, I've worked with that team on various things. But the industry is still itching for a second compiler with no crossover (can't just be another LLVM frontend or rustc fork) for those certification reasons. Not that people want to replace rustc! It's just a cert requirement.

Another reason to have a second compiler is for safety-critical applications. In the assessment of safety-critical tools if something like a compiler can have a second redundant version then each one of them can be certified to a lower criticality level since they'll crosscheck each other. When a tool is single-sourced the level of qualification goes up quite significantly.

IMO Zen Browser fixed a lot of the Firefox UI painpoints while keeping what I like about it. It would be a smart move to make the Zen UI the canonical version of Firefox. Especially since features like vertical tabs, folders, pins, split screen, and new tab previews are more in the power user use case and Chrome has entirely dominated the casual user demographic.

I think you're right but there's also an opportunity to sell picks when everyone is digging for gold. Like AI-driven VS Code forks, you have AI companies releasing their own browsers left and right. I wonder if Mozilla could offer a sort of white-labeling and contracting service where they offer the engine and some customization services to whatever AI companies want their own in-house browsers. But continue to offer Firefox itself as the "dumb" (from an AI perspective) reference version. I'm not sure exactly what they could offer over just forking Chromium/Firefox without support but it would be a great way to have their cake and eat it too.

> This would be career suicide in virtually any other technical field.

The cognitive load is unavoidable and in some ways worse in industries with highly technical names.

At one point in my career I was an engine calibrator at a large automotive OEM. Our lexicon included physics industry terms (BMEP, BTDC, VVT, etc), a large software package where every variable, table, and function was an acronym (we had about 75k tunable parameters, each with an acronym), and all the internal company jargon and acronyms you'd expect in a large corporation. But every name was as technical and functional as the author would desire.

During my first month I was exhausted. I would doze off in afternoon meetings or pass out in my car as soon as I pulled in the driveway. I finally mentioned this to a more senior coworker and his insight was that my brain was working overtime because it was busy learning another language. He was entirely right! The constant mental load was a very real and tangible load. He relayed an anecdote when he went to S. America on his honeymoon and despite him and his wife having taken ~4 years of HS/college Spanish the mental work they had to do to function basically nixed half the daily activities they had planned due to exhaustion. That was what I was experiencing.

The idea that more technical and specific names reduces mental load does not track with my experience. The complexity is intrinsic not incidental and I don't think it has much to do with the specific names chosen.

I worked for a company that had 8-12 different employee passwords across various systems. There was no SSO, they each password had different requirements, and required changes at different intervals ranging from 30-90 days. Consequently every employee had a post-it note directly on the laptop with most or all of their passwords. The outdated IT policy security was so strict that real world security was abysmal.

Meshcore is another alternative. I haven't done a deep dive into either but have heard that they both fix some Meshtastic issues.

https://meshcore.co.uk/

> And again the question why not simply write something new.

There is a ton of new stuff getting written in Rust. But we don't have threads like this on HN when someone announces a new piece of infra written in Rust, only when there's a full or partial rewrite.

Re automotive and other legacy industries, there's heavy process around both safety and security. Performing HARAs and TARAs, assigning threat or safety levels to specific components and functions, deep system analysis, adding redundancy for safety, coding standards like MISRA, etc. You don't get a lot of assurances for "free" based on time-proven code. But in defense there's already a massive push towards memory safe languages to reduce the attack surface.

I've heard two arguments for these rewrites that don't always come up in these discussions. There are fair counterpoints to both of these but I think they add valuable dimensions to the conversation, or perhaps may explain why a rewrite may not seem justified without them.

* It's becoming increasingly difficult to find new contributors who want to work with very old code bases in languages like C or C++. Some open source projects have said they rewrote to Rust just to attract new devs.

* Reliability can be proven through years in use but security is less of a direct correlation. Reliability is a statistical distribution centered around the 'happy path' of expected use and the more times your software is used the more robust it will become or just be proven to be. But security issues are almost by definition the edgiest edge cases and aren't pruned by normal use but by direct attacks and pen testing. It's much harder to say that old software has been attacked in every possible way than that it's been used in every possible way. The consequences of CVEs may also be much higher than edge case reliability bugs, making the justification for proactive security hardening much stronger.

> I hope you can see why _genuinely_ “free, forever.” is in our best commercial interests, long-term.

I actually can't but I'd welcome hearing more about the strategy. I suspect what you're alluding to is maybe an open-core model? Generate free value for the entire ecosystem and then capture a portion of it with value-adding paid features? I'd be interested in that but I don't see where the FOSS layer is here.

> I hope we don’t let cynicism prevent mission-driven companies trying to do good and customer-positive things from succeeding

I also want to do mission-driven and moral work in the tech industry but I think there may be a disconnect between how the general population sees the tech industry and how it sees itself. This is my motivation to make these comments; not to be antagonistic and unpleasant for no reason but to attempt to hold up a mirror and show the tech industry the crisis of confidence that it faces. It would be like Philip Morris - after decades of subverting science and pushing cigarettes - launching a vape and expecting to receive the benefit of the doubt that the product has no downsides. Gone are the days of Silicon Valley being the warm and cuddly companies saving the world from their beanbags and open concept offices.

People complain about Adobe's subscription model but it's superior to free-to-play consumer software because it still keeps an alignment between the consumer interest and the company's income. Despite its other faults, you could even argue that a consumer subscription model can be better aligned than single purchase software because the customer needs to continually choose to pay the company for its use and it incentivizes continually improvement and competition.

> Would you prefer they just kept charging you for the product?

Yes, exactly. Knowing that my interests, my consumer spending choices, are the direct feedback path to their profitability is one of the only ways to provide some concrete assurances that they'll be building for the customer's needs and not for data collection, AI shovelware, or some other play.

I understand where y'all are coming from and this is not a judgement against Canva specifically. But you can't be surprised that people are concerned after so many years of anti-consumer anti-patterns in software that start exactly like this. This has nothing to do with Canva or Serif but the industry as a whole has squandered goodwill for so many years that actions like this no longer get the benefit of the doubt.

So unfortunately due to the rug pulls of many bad actors y'all will have to explain exactly how this doesn't end poorly because damn near every other time a company has followed this trajectory it is not in the consumer's best interest.

My roommate in college worked at GE's Global Research lab in Schenectady. As a bit of a relic from the heyday of US corporate research they still had an in-house glassblowing department for producing all the necessary glassware for all the labs and chemical/material research!

I used existing templates from the [typst universe repository](https://typst.app/universe/) for the resume then built something much simpler from scratch for a secondary document, a sort of cover letter/case study of projects I've done.

If there's interest I can maybe take some PII out of my repo and make it public. Not like there's anything wildly private in there, would just prefer to not get any more spam calls than I already do.

After over a decade of occasionally updating that one ancient .docx file, I recently rebuilt my CV/resume using typst and it's been a really fun project! My resume is now a private repo with my personal, career, and styling data stored in TOML files. Then I can pull any interesting typst resume templates, populate the information from the TOML files by looping over arrays of jobs/projects, and populate it into the doc template. It's absolutely overkill but it was a fun project and I really enjoyed working with typst. Didn't even do a tutorial, just threw myself into the language and assumed it would be intuitive enough with some examples and it absolutely is.

What's the overlap between the offline-first and local-first paradigms these days? Both technologically and philosophically?

And shockingly one of the engineers on the call still complained to their coworker later that day "that meeting could have been an email".

/s

Every mechanical engineer educated in the USA knows the name of two famous collapses: the Tacoma Narrows Bridge and the Hyatt Regency balcony in Kansas City, MO. With an engineering ethics class being part of nearly every undergrad curriculum, these are two of the classic examples for us. I'm curious; do software engineers learn stories like the Therac-25 in their degrees?

It just might. But if people generate a bias against AI generated code because AI can generate massive amounts of vaguely correct looking yet ultimately bad code then that seems like an AI problem not a people problem. Get better, AI coding tools.

I'm a big fan of Zed and having met much of the team I think it's some great people building a great product. But I do echo concerns that while the intentions are all honorable the incentives of the pricing structure, business environment, and now a funding round are concerning in the long term. I don't think anyone at Zed has a single ill intent or a secret master plan but these days anything I'm not paying for I just assume is going to be enshittified eventually. Especially for an app where the only paid features are AI-centric and there's a VC expecting to make multiples on a $60m investment.

So here's my ask: let me pay for it without paying for AI! None of my use cases will stress your servers; I have `"disable_ai": true` in my settings.json. Give me a $5/mo "support the devs tier" or a $10/mo tier with some random app quality-of-life features and I'm there. I specifically want to pay for good software without paying for AI to signify the value proposition that still exists there cause I don't think a VC would believe me otherwise.

I don't think that BBC article is technically detailed enough to make that case. The actual study may be, so I'm not saying you're wrong, but "generative AI" is far too large of an umbrella term that encompasses two very different views. The common thesis here is that AI is a wildly powerful tool to do fundamental science, and I think most technologists with any knowledge of neural networks would agree that's true. But the problem is that the Sam Altmans of the world are applying that thesis to the promise that GPT5 is on the path to AGI and they just need to keep scaling and pouring more billions of dollars into these massive models to get there. When I see actually interesting applications of AI in fundamental science the studies are usually of custom programs starting with smaller or more purpose-built foundational models, being hand tuned by knowledgeable researchers with deterministic/testable validation feedback loops. So what you're saying can be true while what Altman is promising can also be absolutely false. But it's hard to say without actually reading that MIT study.

While that may be true, I don't think the specific name of the team at Microsoft absorbing GitHub is what's concerning users. I can't think of a team up there that wouldn't be a red flag in this case.

That's very interesting because in their episode on hiring practices they said that they hoped the materials would be a valuable exercise for anyone deeply engaged in a job search. Hearing that same feedback from the other side of the process really closes that feedback loop!

There's also an excellent Local First podcast that interviews the engineers building local-first apps and infra!

https://www.localfirst.fm/

Historically the entire engine tuning industry's loophole was some text on their website and product packaging that said "for off road use only". But over the years they've become more brazen about marketing for street use while expecting that disclaimer to protect their liability. IMO the real breaking point was the diesel truck guys. They were both far more active in marketing their defeat devices for road use ("improve towing fuel economy with a DPF delete") as well as the coal rollers just being so hilariously anti-social that there was bound to be pushback. They really pushed the uneasy look-the-other-way truce that the industry had with the EPA and even as a longtime car enthusiast (and engineer who's worked in both emissions engine calibration and electrical vehicles) I can't fault the regulators on this.

So to answer your actual question, while technically actual off road use is still legal a lot of bad actors in the industry used every bit of leeway that the regulators gave them and now this crackdown is the result.

>Much of the anti-OOP noise is the result of people that have suffered from others creating hierarchies of the world too literally.

I think one of the problems is that a heirarchy is inherently opinionated. You have to choose the criteria around how to group the objects/nodes in your graph and that criteria is context-dependent. The example I've used with animal taxonomy is grouping your objects via things you can eat vs things you can pat. Thsoe are two very different graph structures of the same group of objects and if you started with one then realized you need to change, how you use your objects you're gonna have a bad time. Multiple inheritance is the bandaid solution that usually comes with more hassle than it's worth.

Building a UI is a good example of a heirarchical structure where you know exactly how you want to use your objects and how they'll relate to each other, Not having access to that programming structure would be frustrating and just feel like a loss. But I've also done multiple large refactors of Python projects because I relied on OO inheritance models that turned out to not be quite the right implementation. In those situations, Rust traits are a breath of fresh air for offering the right kind of polymorphism.

I love a long, deep-dive, nerdy talk like this! I'll check it out, thanks.