I get that a lot of folks were traumatised by the shift from init based systems to systemd. However the architecture is sound and relatively straightforward given the inherent complexity in managing a diversity of system processes.
EDITED TO ADD:
If you’re looking for a UNIX anti-hero regarding “do one thing and do it well” (that predates systemd), look no further than emacs.
Yeah, well, the Unix philosophy is from the engineering department, not the accounting department.
Funding FOSS projects without advertising, dopamine-hacking, donation-begging into the void, or being subsidized by billionaires that want to influence the electorate is still largely unsolved.
The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
The problem isn't even the billionaires.
The problem is convincing comfortable, ambitious middle-high earners to put a cap on their and their bosses' prospects in exchange for the stability (and subsequent ground preparation for innovation) of a higher floor.
They're the stumbling block because they're the ones who, on balance and en masse, have the money and votng power to excuse and enable the status quo.
> The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
Part of the problem is that there are people who think all rather than only some of those things are a good idea.
High marginal tax rates and taxing unrealized gains are both unintended consequences factories. Especially the second one, but even the first one is basically a trade off between creating perverse incentives and arbitrage opportunities (i.e. massive loopholes) because the high rates don't apply to everything, or supercharging offshoring because the high rates do apply to everything.
Conversely, a UBI is a good idea, and doesn't actually require oppressive tax rates because it replaces most of the existing system of government benefits and subsidies -- which impose even higher de facto marginal tax rates on most of the middle class in the form of benefits phase outs. US federal spending is already >$20,000 per capita.
Not all of that is assistance programs, but a large proportion of it is. And most of those programs are a net negative compared to reallocating their budgets to a UBI. Having separate bureaucracies to administer separate programs for food assistance, housing assistance, education assistance, etc. is foolish even before they create weird marginal rate cliffs and higher marginal rates on lower income people by having arbitrarily overlapping phase out rates.
It isn't about the source of the money. Converting those things to a UBI would cost less money to give people more money because you'd save the amount spent on administration, while improving economic efficiency by not imposing arbitrary restrictions on how it's spent. The primary reason we don't do that isn't upper middle class people demanding a status quo in their own interest -- it isn't in their interest.
It's a combination of ordinary incompetence and bad structural incentives because politicians like to claim credit for creating new programs instead of just indexing the amount of a cash payment everybody gets to GDP per capita and then sending them all home.
That was always little more than unix propaganda. Until GNU came around and held itself to a higher standard, it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing). "Do it well", hardly. A more true to life account of "unix philosophy" is "worse is better". It doesn't have to be good, merely available.
GNU programs do lots of things poorly, starting with "echo -e" and "cat -n" and continuing through to tools like awk and sed. Powershell does Unix philosophy better than GNU does.
It’s still a relatively decent and ambitious thing to aspire to, i.e. a lean interface/tool scope that prevents scope creep. Composability (with pipelines) also works quite well. But yes, it is somewhat propaganda.
> it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing).
You might want to remind yourself what caused the November 2025 Cloudflare outage!
Crazy that this particular feature we’ve all been waiting for hasn’t received first-party support by any DevEx company.
You know, the companies that say security is their number one priority, or companies that scream “developers, developers, developers”. How Google and Apple didn’t come up with something together eludes me, but then again, we have entire ecosystems and categories deployed in the areas they don’t service (auth, application control, etc).
Don’t get me wrong, I like the idea of self-hosting but there’s a reason we don’t manage and run our own email infrastructure.
I think the SaaS is dead meme is really just a “SaaS can’t be lazy anymore”. The days of offering a product that technically does something, but is incredibly poorly designed, or not well integrated, or unsupported — are over.
If your SaaS doesn’t support both Google and Microsoft; macOS and Windows; iOS and Android; automated provisioning, complex/fine-grained RBAC, customisable onboarding.. You’re dead in the water.
The moat of features has evaporated, and your only defence is good UX, stability and TCO.
AI isn’t eating SaaS. It’s eating shitty businesses.
Password Manager SaaS that have been breached are dead.
Auth providers that scale their pricing model to their investors growth expectations are dead.
Platforms and technical products that did something a script could do, with little support for real business software, ecosystems and environments are dead.
> AI isn’t eating SaaS. It’s eating shitty businesses.
AI isn't even eating most shitty SaaS businesses, because it's a weird HN fantasy that your hairdresser or car mechanic are itching to manage agent swarms and risk losing their business if that unnecessary adventure goes sideways. They would much rather pay several hundred bucks for a SaaS product that has a bunch of UI annoyances.
It's likely that there will be an explosion in vibecoded competitors to existing SaaS products, but I wouldn't underestimate the importance of familiarity and stability. I use a bunch of SaaS stuff for my business and it's not like I do a weekly comparative analysis to see if switching to some unfamiliar platform that popped up overnight could save me a bit of money or time. It's just not worth it.
This. Even if you vibecode stuff and outsource most of the decision making to an LLM, the software has to be maintained over an extended period. Not to mention that running the agent also takes money. And if any of the dependencies (including the LLM itself) goes down and you have no idea how the whole system works, you're cooked.
Just like software projects I want to see that company has been around for some time say at least 2 years. At that point it starts to look like they have committed to it over long term. Same would go for any SaaS proven track record of being in business.
Replacing something has cost involved and doing it too often will kill any savings. Which matters when you actually need to stay profitable.
Because sometimes bad architecture is the correct architecture, and good architecture is the wrong choice.
You think we’d have Carmack’s DOOM with “best practice”? Hell no.
I’ve worked for incredibly talented people who choose the wrong technology, approach and design for problems they could have predicted or anticipated, had they seen it or a similar problem before, or had context about the organisation, customer or size of team managing the proposed solution. But they don’t.
AI is great at giving textbook and “Enterprise grade” solutions; but as code production cost reduces — I think the value of simple, digestible solutions will grow. TDD et al can also be helpful, but at a certain point it becomes too abstracted, too complicated, too hard for any one person to grasp.
At that point I think test managers who understand user journeys will be worth their weight in gold, and the real value in any solution becomes good, represented testing.
For TTS I launched this like this week based on a Reddit thread of recommendations, added a new one to it.. I want to say on Wednesday, but this week has been a blur. Problem I’ve found with similar sites is I can’t run a lot of the models, or the results are beyond stale.
But this is only stuff I can run locally, or it’s a cloud model.
I know. It hurts. But I have the feeling that you get what you pay for.
The purchase cost of H100 or B200 systems with comparable VRAM is a one order of magnitude higher. Although I can only guess how much lower the token/sec output of the Mac Studio will be. Probably 2-3 magnitudes lower?
While a cluster has to work with many users simultanously, and is a good investment for a company, perhaps the Mac Studio will be a good use case for a personal larger LLM deployment configuration.
Perhaps someone has the token/sec numbers for larger models running on older Mac Studios?
Back of the envelope is that compute doesn't matter for inference, only memory access speed matters. Tokens/sec is going to be in the ballpark of how much time it takes for the compute element to read the entire model. So you can give GBtok/sec (sec = seconds, GB gigabyte size for the chosen quantization)
Q8 is a nice quant for this calculation, since 1 byte = 1 weight, so Qwen 27B Q8 will be the tok/secGB value divided by 27, and Deepseek V4 Flash 162B, by 162.
NVIDIA B200: 8,000 GBtok/sec
NVIDIA H100: 3,350 GBtok/sec
NVIDIA A100: 2,039 GBtok/sec
NVIDIA RTX 5090: 1,792 GBtok/sec (deepseek only fits at Q2 or less)
Apple M5 Ultra: 1,200 GBtok/sec
NVIDIA RTX 5060 Ti: 448 GBtok/sec (deepseek doesn't even fit at Q1)
Apple M5 Pro: 307 GBtok/sec (can do deepseek only at Q4 or less, at maxed out sped)
Apple M1 Pro: 200 GBtok/sec (can do deepseek only at Q2 or less, at maxed out sped)
Apple M6: 170 GBtok/sec (can do deepseek only at Q2 or less, at maxed out sped)
So a base model apple M6, Qwen3.8 Q8 = 170/26 tok/s = 6 tok/s (or 12 tok/s at Q4), and a B200 will do ~40 times that, or 240 tok/s. Which is kind of sad as a base model M1 pro will beat it comfortably despite 6 years of chip advancements. To add insult to injury an M1 pro ... is cheaper secondhand.
Liquidity providers like Jane Street, Citadel, et al make money on the spread. They also buy order flows from integrators, and retail investor order flows are now a product.
i.e. retail investor → brokerage platform → clearing/execution infrastructure → Jane Street → payment back toward the brokerage side of the chain.
Who captures the economic value created by retail order flow?
Jane Street.
In an ideal market, this product line shouldn't exist. Institutional investors should not be making money on the activity of retail investors.
What incentives determine where that flow is sent, and would investors receive better execution if their orders were exposed to genuinely competitive price formation rather than privately internalised by a concentrated group of wholesalers?
The regulators should be squashing any HFT related or retail order flow, but it's so opaque _by design_ that getting policymakers, or the general public, to understand that retail investors are paying some portion of tax on their $20T USD annual trades to these companies.
Granted, these order flows _sometimes_ work the other way -- and retail users get a better deal on a trade.. But would you really expect the market to be worth what it is, if that was the case less more often than not?
There is a clear and obvious conflict: the broker is supposed to seek the best execution for the customer while potentially being paid by the firm receiving that customer’s order. How can that be, when the broker's in bed with the liquidity providers?
PFOF and HFT are distinct concepts, but they are widely conflated in this thread. I don't agree that PFOF is inherently bad, but even if it were: it is not a valid criticism of HFT.
Thanks for bringing this up and trying it out! We've disabled Cmd+Option+I in the new version and also have a message during signup about sharing chats with Bullet, let us know if you run into any other issues!
OP was providing a userful tips to users, and they weren't giving you a bug report to remove it. If anything, they were suggesting you remove a login-wall.
But now that you blocked the inspector tool, you'll find it harder for users to report bugs. Unless of course those are automatically shared too? /s
We're actively working on implementing a guest mode feature right now for users that don't want to make an account. For reporting bugs, we have an in-app feedback form. Bugs are not automatically shared.
I guess the question is; is this the late-cycle cash-out (aka harvest pricing) akin to Sun Microsystems at the dot-com peak -- or is it a repeat of the crypto pricing hijinks we've already seen from Nvidia, where they're just exploiting the lack of supply?
That's a 90% uplift since the original pricing, in a market that is already showing signs of seizing.
With Apple offering leasing options, CXMT knee-capping Samsung, all of the big tech players on a run to outspend on CapEx by the end of the year..
We're at a point where local models are exceptionally capable, model-on-silicon dies like Taalas (recently acquired by AMD) may be cutting inference cost substantially for the 90% of work we do day-to-day (similarly Alibaba's T-Head division with open-model-forward inference chips being produced domestically in China).
If we shifted all of the design/planning to cloud models like Fable 5/Sol 5.6 Ultra, and day-to-day operational inference to these chips -- it's quite likely we'll squash usage to single-digit percentages of what we're currently using. But we should also expect the model providers to take a similar approach.
In any case -- I'm keen on demand destruction, both as a consumer and someone without skin in the game.
It makes you wonder to what degree they are making more money by raising the prices and restricting supply absent meaningful competition, or, alternatively, by making them in volume until they can supply the total demand. The lack of competition is probably a big part of the problem, but then again, that competition might just increase the price as well if it existed. AMD really could make a killing if they got off their assess and properly supported their cards (and made them competitive performance wise, which is probably a really hard thing for them to do).
i think maybe by pricing up they want to make a reliance for people on their services rather than developing running their own. if these devices are out of reach for many it means less innovation and then less competition. nvidia is now tightly coupled financially to business who offer services that owners of such devices might replicate without using services of their partners.
The unix philosophy prevails!
reply