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.
RA is primarily used by independent promoters in the States, which tend to be much smaller and have smaller or less frequent events.
Large promoters who regularly throw events or have the budget for larger events would use their own promotion mechanisms and general population ad networks instead of listing on RA.
> Large promoters who regularly throw events or have the budget for larger events would use their own promotion mechanisms
No (at least in the US) - it’s because of exclusive contracts with the ticketing platforms.
Whereas you can list on RA and other platforms too, the biggest clubs and venues get lucrative deals with eg AXS to only list tickets on their platform.
That's ticketing. There's plenty of listings on RA that don't use RA's ticketing service.
Large promoters that use or have exclusivity deals with AXS or Ticketmaster/LiveNation or Dice still advertise/promote on platforms like Facebook/Instagram, EDM Train, Radiate, etc alongside the ticketing platform's promotion platforms.
RA is the biggest site for electronic subculture since forever, and it's an excellent resource to find out the cool stuff that happens in your city. I don't know why you consider it small, maybe it's a US thing? In Europe, RA is the best resource to find about parties and electronic music in general.
Otherwise, the schema seems to be derived from the class being serialized for typed languages, or otherwise annotated in code. The serializer and deserializer code must be manually written to be compatible instead of both sides being codegen'd to match from a schema file. He's the example I found for python: https://fory.apache.org/docs/docs/guide/python_serialization...
You don’t need to hand‑write serializer code. In typed languages you just define your class or struct as usual; in dynamic languages you can use type hints.
When running in compatible mode, Fory automatically derives a compact schema from those definitions at runtime time and sends it along to peers for the first time serialization. That way, both sides know the structure without needing a separate schema file.
The idea is to make cross‑language exchange work out‑of‑the‑box, while still allowing teams to add an explicit IDL later if they want a single source of truth.
Exactly, i'm using protobuf, i've got those proto files which generate code in python, ruby, go and typescript. I can share the package into those different services and i'm gonna be sure i'll use common interface.
It's not clear for me how to achieve the same with fory?
The connection between the furnace and the thermostat probably shouldn't go through the internet.
So it's perfectly reasonable for the furnace to turn off when it is disconnected, because disconnection would be a very strong signal for an error state instead of regular intermittent network/service issues.
They're not, "smart" thermostats have a WiFi frontend that allows devices to connect to it from the network but the thermostat itself is hardwired to the furnace/HVAC.
You could in theory put one next to the furnace in your machine closet but that would be dumb and expensive
Certainly, the standard smart thermostat set up is that your ecobee is connected to the Internet, but controls the furnace using good old-fashioned signal wires
Which is only extremely tangentially related to "if I pull my thermostat off the wall"
The overwhelmingly most common connection between a thermostat and furnace is a contact closure when calling for heat, with no ability to differentiate between “thermostat is present but not calling for heat” and “thermostat is not present” as both present as "these T-T contacts are not closed/shorted together".
the connection to my thermostat is via a cable, if I pull it out of the wall it won't be connected to anything at all. the whole furnace is not connected to anything but mains power.
reply