The reason was sillier: China forced Ford to sell Mazda to enter the Chinese market, because Mazda entered the Chinese market before Ford and China considered them the same entity subject to the same outside manufacturer limits).
Mazda handled the small vehicle chassis design for Ford. So without Mazda, Ford no longer had the knowledge for continued development of their sedans and crossovers based on sedan platforms.
Ford was with Mazda in China with a joint venture with a Chinese company (as required): Changan, and they were building those shared Ford/Mazda platform vehicles there.
Ford wanted to also build trucks for the Chinese market, with a different joint venture. However, the rules limited companies to two joint ventures, which was a problem because Mazda also had a joint venture with FAW. Which meant it counted as part of Ford's 2 joint ventures.
So Ford sold Mazda. Changan Ford/Mazda got split in their respective halves. FAW was no longer associated with Ford and left with Mazda. Ford could then pick up a new joint venture for trucks, which they did and I don't believe they're doing well.
Ford just really wanted to double down on trucks, in more than one market.
Not sure why you want to have purpose-built OS as the hill to die on since many of those Android-based mp3 players absolutely outclass the old iPod classics in snappiness and compatibility and output quality.
Plenty of choices that meet your other criteria once you're OK with it being Android powered.
Like a SnowSky is very obviously stripped down Android that can only run the music app it's shipped with, but it's otherwise everything you want.
Only speaking for myself, but the problem with Android is that it and the hardware needed to make it run acceptably are absurd overkill for the use case, which drives up cost, cuts down on battery life, and adds a layer of unnecessary complexity (suddenly you need to think about what player app to use, for example).
Basically part of the charm of a single-purpose device is that it can be built to serve it purpose ridiculously well and do nothing else, and the second general purpose software enters the picture much of that is lost.
The endless amount of Chinese Android-based single purpose mp3 player devices that are obviously iPod Nano/Classic clones basically cost ~$30 and have 50hr+ of battery life. You don't have to think about what player app to use, they ship with the only one that runs. The rest of the Androidness is stripped out.
Then yes, there's obviously the other end of the extreme where the mp3 player is very obviously a phone without a radio with a price tag to match. And everything in-between.
I'd say there's actually too many choices cause the silicon and battery cost required to simply play music has gotten so cheap that it doesn't make sense to optimize the OS further than Android. I'm sure the economics of scale means the actual hardware wouldn't be cheaper by any noticeable amount either.
> Only speaking for myself, but the problem with Android is that it and the hardware needed to make it run acceptably are absurd overkill for the use case, which drives up cost, cuts down on battery life, and adds a layer of unnecessary complexity (suddenly you need to think about what player app to use, for example).
The battery life is fine on modern DAPs. Excellent, even.
I understand why an engineer would want a completely application specific, built-from-scratch OS that does one thing perfectly, but that's a pipe dream for a niche market.
A powerful and efficient SoC that runs Android is ultra-cheap these days. Less than $1. Hiring an engineering team to write and maintain a custom OS for a niche product would incur so much R&D cost that it would wipe out any money you'd save by using a smaller microcontroller and drive the final cost up.
Just think: How much salary would you have to pay a team of engineers to write the custom OS and maintain it? If you could optimistically sell 500,000 of these devices (good luck) then how much would you have to save in order to pay for the R&D?
You don't need "OS" to play some music, drive display and talk via USB/BLE. It's trivial task and could be done with a few event loops. A lot of firmwares is being written without OS. May be FreeRTOS/Zephyr to somewhat simplify the programming, but that's definitely not "OS" in a commonly accepted sense. You don't need team of engineers, one hobbyist could easily do that. I wrote firmware for a device of similar complexity (work with ADC, implements USB, BLE, some UI with buttons and leds) and I'm not even a professional.
There's no way to win in these threads. It's a very common pattern on HN that somebody will say, "X doesn't exist!" And then people will proceed to point out that in fact does exist. And then you'll find out that the original poster has a bunch of non-functional requirements that were baked into their original request that they didn't state, and I usually don't agree with (typically because they are either not practical or only of theoretical concern).
They'll typically defend them using highly charged language, like claiming that having to carry a 200 gram device will pull their pants down because it's so heavy, or that managing a Bluetooth stack and USB doesn't require an OS, but rather just a couple of event loops that a non-professional could code directly in firmware.
I've simply stopped participating because in my efforts to try to help people, I find that I just get into silly arguments.
Odd, I didn't even know Proton had an AI feature until I read this article. Didn't get an email or tooltip while using the app. Didn't previously explicitly opt-out either, and when I check my notification settings, Lumo product updates is set to disabled.
Maybe someone's feature gate isn't working as intended?
I did get the Github Copilot spam email today though.
I do think the same too, I have a Proton subscription (non-business), my "Lumo Product Updates" is toggled OFF and I've never received a single Lumo email so far.
I suspect it's because the technical staff have already been let go or replaced with outsourced maintenance-only staffing firms, which means the non-technical leadership doesn't know whether the source code would contain damaging information.
If you open a standard sized receiver up, you'll probably see that 50% the space is empty for airflow, 25% of the space is for a large heatsink because they're passively cooled to minimize noise (thus the need for airflow), and 20% of the space is really big capacitors.
They do make half size receivers, but they typically only have half the power output. The space savings comes from removing space for airflow and the heatsink, and using smaller capacitors for less heat and smaller power output.
If you only need 2.1 output and a quarter of the power, there are offerings that are basically the size of the minimum amount of ports: 2 pairs of speaker terminals, a pair of RCA terminals for subwoofer out, a HDMI port, a optical port, and power. But then it's not really a receiver and more just of an amplifier+DAC because they only have one HDMI input/output, having space for multiple HDMI ports or speaker terminals basically increases the size to the offering above.
They're big mostly because consumers demand a lot of big connectors on them.
Sometimes I see cheap "amplifier only" designs that are about the size of a small 2U rackmount, but then you usually give up a lot of inputs and controls; they seem to be used either as PA amplifiers or as "extra room" units in the weird whole-house audio systems that apparently thousands of people had at one point and all dumped in the Goodwill.
I always figured Bun was the "enterprise software" choice, where you'd want to use Bun tools and libraries for everything and not need to bring in much from the broader NPM library ecosystem.
Deno seems like the better replacement for Node, but it'd still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.
Yes, both can pull in open source libraries and I can't imagine either dropping that ability. Though they do seem to have different eagerness and competency on Node compatibility and Bun seems better on that front.
From a long term design philosophy prospective, Bun seems to want to have a sufficiently large core and standard library where you won't need to pull in much from the outside. Code written for Node will run on Bun, but code using Bun specific features won't run on Node. It's the "embrace, extend, ..." approach.
Deno seems much more focused on tooling instead of expanding core JS, and seems to draws the line at integrations. The philosophy seems to be more along the lines of having the tools be better about security when pulling in libraries instead of replacing the need for libraries. Deno also has it's own standard library, but it's just a library and that library can run on Node.
Lobsters feels a lot like the HN of a decade ago, when the community was more technical than business, and the topics were technical instead of tech business culture.
HN was originally called "Startup News". It was founded by tech business people and originally its userbase was largely startup tech people https://en.wikipedia.org/wiki/Hacker_News
I've been here 12 years and I don't remember HN focusing solely on technical topics, unless the word "technical" has widened to mean "anything one engineer finds intellectually stimulating".
HN was never only technical, but at least it felt like the discussion was from people who build, which naturally segued into technical discussion. It felt like the majority back then were tinkerers and builders.
Nowadays it feels more like sales, marketing, management, and investor interests, and topics they find interesting which has far more popularity than anything at the implementation level.
Granted, HN probably better matches what matters these days to launch a successful company. But we're all older now and working for companies that became what we once tried to disrupt, and it shows.
You give way too much credit to the technical abilities of most venture back founders.
Good founders have always been more about sales, marketing, funding, etc.
And that’s not meant to be an insult. I’ve always been more of a fan of the people who create successful businesses from technology than the technology itself.
I have the same impression. If anything, it’s become more “generic technical” topics and less “insider founder” ones. There seems to be a lot more institutional representation here than circa 2010-2015, probably because many of the new founders then are now running establishment companies.
There used to be a lot more “hustle culture” and “growth hacking” stuff on here (10+ years ago) most of which I find disgusting, so I’m glad for that shift.
I wonder if there is some sort of bias depending on the timezone people visit because i've been visiting HN for more than a decade and for me HN always had a lot of technical discussions and topics - in fact i see it as one of the most technically oriented forums i know. In fact if it was all (or mostly) business stuff i wouldn't stick around as long i have as i do not find those topics interesting.
HN 15 years ago wasnt technical, it never was. HN is about startup business and sometimes a tech toy like whatever JS frontend is hyped this week.
The discussions are shallow and pointless, lots of actors arguing in bad faith and lots of commercial hype, lately mostly around AI to the point that the site is barely interesting for the tech-curious.
And then there's dang's moderation where he deletes comments or requires users to remove comments themselves to avoid being banned.
I'm convinced Okta's entire business model is undercutting everyone with a worse product with worse engineering that checks more boxes on the feature page, knowing IT procurement people aren't technical and think more checkboxes means it's better.
"Enterprise Software" is what Tobi Lutke called that in a keynote once. A focus on hitting as many feature checkboxes as possible at the cost of quality.
I definitely think people will regret adopting Golang in time. It's this generation's Java, except without an smooth off-ramp in Kotlin/Scala and even less of the benefits.
My previous employer already had a product offering that could do this for a better part of a decade by triangulating with WiFi/BLE and cross referencing with surveillance footage. It was deployed in malls and retail chains.
It generated interesting information, but not interesting enough to be profitable.
We weren't the only ones with this capability either, most major retailers had this level of analytics through surveillance footage that previously existed for loss prevention purposes. Then simply link the data to a rewards number or credit card and you got a stable tracking identity.
I've worked with a major retailer on similar backend systems and can echo the post above - all of them are running these systems and they almost never discuss the specifics (until someone like Walmart sues Everseen and we get a glimpse behind the curtain from the court documents).
If you go to an org's website offering these tools (eg, Everseen mentioned above, RetailNext, etc), they don't directly advertise the full breadth of their capabilities until you have them in a room for a sales pitch. They can combine multiple data streams such that an individual can be traced throughout the store via cameras, wifi, and bluetooth, which gives the retailer an opportunity to sell that information. Did a customer pause in front of the corn chips but then decide not to buy? Print them out a Frito-Lay coupon at checkout and see if you can't get them next time, and Frito-Lay will pay you to do that.
I have no first hand experience outside of North America so I won’t speculate. There is a cost of entry so you need to be moving enough volume in a market already working on razor thin margins. I’d expect that this means it’s only for the regional/national players here.
Sorry, "cost of entry" meaning that the software and the supporting hardware platforms makes it cost prohibitive for a small org that isn't moving a lot of volume from their shelves. Grocer margins are razor thin already.
Theft is only one cause of loss. Stocking/admin/counting mistakes, accidental damage, spoilage, or simply people moving stuff around or misplacing items so they're not where it's expected all fall under loss.
The industry tends to use the even harder-to-understand term "shrink". Not always theft, just any loss of product versus what the books say they should have.
"Theft" is such a value-loaded, moralizing term. It collapses a wide spectrum of socioeconomic realities into a single criminalized label, ignoring the structural inequities that often shape people's choices. When we say "loss prevention", we're deliberately reframing the conversation away from individual blame and toward systems, environments, and institutional responsibility.
Loss prevention isn't about vilifying people - it's about acknowledging that harm occurs within a broader context. It centers the idea that organizations can design safer, more equitable spaces that minimize material loss without resorting to punitive narratives rooted in classism, racism, and centuries-old assumptions about who is "dangerous". Calling something "theft" externalizes accountability onto the most vulnerable actors; calling it "loss" recognizes that institutions have agency, too. And preventing that loss focuses on proactive, compassionate strategies rather than reactive punishment.
Mazda handled the small vehicle chassis design for Ford. So without Mazda, Ford no longer had the knowledge for continued development of their sedans and crossovers based on sedan platforms.
reply