Hacker News, Distilled

Scope of “exactly-once”

• Core disagreement is over what “delivery” means.
• One camp: “delivery” is about messages crossing an unreliable channel (e.g., network), regardless of what the receiver does afterward. Under that definition, exactly-once delivery is impossible in general.
• Other camp: you can define the “receiver” to be downstream of a deduplication layer on a reliable substrate, and then that receiver does see each logical message exactly once.

Delivery vs. processing

• Many argue the standard and useful distinction is:
  • Delivery: a message arrives at the system endpoint, possibly multiple times.
  • Processing: the system updates durable state in response.
• Exactly-once processing is achievable atop at-least-once delivery plus idempotency/dedup; exactly-once delivery (at the unreliable-channel boundary) is not.
• Critics say blurring this distinction misleads developers and has caused real bugs (e.g., in messaging/streaming systems advertised with “exactly-once semantics”).

Memory, time, and impossibility arguments

• Objection: any generic dedup requires tracking seen messages; without bounds on time, rate, or size, this needs unbounded memory.
• If you prune dedup state or give up after N retries, you lose strict at-least-once or exactly-once guarantees.
• Some point out that, by the same reasoning, even “at-least-once delivery” is idealized, since retries are also bounded in practice.

Practical engineering vs. theory

• Several comments stress that in real systems, “good enough” (extremely high probability) is fine, analogous to CAP or compression discussions.
• Idempotent handlers, message IDs, expirations, and transactional patterns are common tools.
• Some messaging products and XA/JMS stacks market “exactly-once delivery,” which others denounce as at-least-once + transactions/idempotency rebranded.

Semantics, pedagogy, and human communication

• A significant subthread argues this is largely a semantic dispute that obscures the real lesson: applications must handle retries and duplicates.
• Others say precise, conventional terminology is crucial to avoid confusion, especially for less-experienced engineers.
• The article’s stated intent—to comment on human communication via this debate—was noted, but many participants focused almost entirely on the technical semantics.

What the OP Is Really Asking About

• OP wants a flight search engine that combines flights from different airlines on separate tickets to create cheaper or more flexible itineraries.
• This is widely referred to as “virtual interlining” or “self-transfer,” distinct from traditional interlining on a single ticket.

Virtual Interlining & Example Tools

• Kiwi.com, Hopper’s “Mix & Match,” Skiplagged, and Tripstack’s tech are cited as implementing virtual interlining with some form of connection insurance/“layover protection.”
• Users report big savings (sometimes hundreds of euros/dollars, or large percentage discounts), especially within Europe and for budget carriers.
• Several people say they’d still avoid using it for “important” or time‑critical trips due to risk.

Risks of Separate Tickets & Third‑Party OTAs

• Key risk: if one leg is delayed, the onward airline has no obligation to rebook or refund; traveler is on their own financially and logistically.
• Checked baggage and irregular operations (IRROPS) become much more stressful; stories of being stranded, losing money, or stuck between airline and OTA blaming each other.
• Many contributors strongly prefer booking directly with airlines, using OTAs only for search; others in Europe report routinely booking through third parties with few issues and significant savings.
• Some describe particularly bad experiences with certain OTAs (e.g., hostile airline relationships, inability to use mobile check‑in, terrible support).

Search Engines, GDS, and Data Access

• Traditional Global Distribution Systems (Sabre, Amadeus, Travelport) were meant to be single sources of truth, but airline opt‑outs and fragmentation create gaps.
• Calls for an “uber‑GDS” / meta‑meta‑search are tempered by claims that economics don’t work: low commissions, high scraping/API costs, and users bypassing aggregators to book direct.
• ITA Software (now underpinning Google Flights and ITA Matrix) is praised for powerful search; Google Flights is widely liked but sometimes surfaces OTA‑only prices.
• Data access is hard: scraping low‑cost carriers is brittle and legally contested; comprehensive, up‑to‑date global inventory remains elusive.

Desired Features & Market Reality

• Users want: multi‑city optimization, “explore from this airport” views, multi‑origin searches, and better points/loyalty optimization.
• Several note that many sophisticated pre‑COVID “tricks” matter less now due to route changes, higher or restructured prices, and generally tighter networks.

Nature and Severity of the Vulnerability

• Commenters describe the bug as “catastrophic” and “rookie-level”: client-controlled user IDs in Firebase rules let an attacker take over any Arc account and run arbitrary JS on every page those users visit, including privileged browser UI.
• Many note that browsers are extremely security‑sensitive (on par with OS or SSH daemons), so a flaw of this type is seen as reputation‑destroying for a browser vendor.
• Some point out that the exploit was trivial to find and exploit, which raises fears there may be more undiscovered issues.

Firebase, Security Model, and Responsibility

• Strong criticism of Firebase’s security model: default‑deny rules exist, but it’s easy to misconfigure and “bolt‑on” rules are a common foot‑gun.
• Others push back: Firestore rules deny everything by default, docs clearly explain request.auth.uid and ownership checks; this is framed as a basic “never trust the client” failure by Arc, not Firebase.
• Several argue that letting clients talk directly to a shared DB is inherently risky compared to a traditional backend API.

Privacy and Arc’s Architecture

• Arc’s mandatory account requirement was already a red flag for many; several say that alone kept them from trying it.
• The thread highlights Arc sending visited hostnames plus user ID to Firebase for Boosts, contradicting marketing claims that they “don’t know which sites you visit.” Even if only when certain features are open, this is seen as a serious policy breach.
• Some are disturbed that Arc depends heavily on Firebase at all for a privacy‑branded browser, and wonder what breaks if Firebase is down.

Response, Communication, and Bug Bounty

• Positive notes: very fast technical response (roughly a day) after private disclosure; commitment to move off Firebase, bolster security, and create a formal bounty program.
• Negative notes: $2,000 bounty is widely viewed as insultingly low for a browser‑wide account takeover; many say this signals Arc doesn’t value security highly.
• Several criticize delayed, low‑visibility communication (initially not front‑paging the incident write‑up), seeing it as image‑protective rather than user‑protective.

User Reactions and Alternatives

• Multiple users state they are uninstalling Arc or advising others to do so; others say they’ll continue using it but are uneasy.
• Suggested alternatives with similar UX ideas include Firefox (with extensions like Sideberry/Tree Style Tabs), Zen Browser, Floorp, Brave, Vivaldi, Edge, Safari, and Kagi’s Orion.
• Broader skepticism appears toward VC‑funded browsers with no clear business model but deep access to user data.

Nature of the attack

• Attack uses GitHub issues/comments plus notification emails as a trusted delivery channel.
• Pattern: brand-new accounts open issues mentioning “security” or “vulnerabilities,” include a link, then the issue disappears soon after (deleted by attacker or GitHub).
• Landing page pretends to be a GitHub-related scanner and shows a “CAPTCHA” that asks users to paste a command into a shell / Windows Run dialog, often with admin privileges.
• Some note this is not GitHub “sending malware” but rather user-generated content within issues that GitHub relays via email.

How plausible is the scam?

• Many point to obvious red flags: odd domain, strange “CAPTCHA,” admin warning dialogs, mis-capitalized “Github.”
• Others stress it’s a numbers game: tired, rushed, or less-technical users (including many GitHub users) can and do fall for such tricks.
• Several commenters share anecdotes of smart/technical people getting phished or scammed; “victim-blaming” is criticized.
• Some say that if this had hit them in their first year on GitHub, they might have complied.

GitHub’s role and possible mitigations

• Calls for: better spam detection on new accounts, delaying or suppressing emails for unverified content, stripping links from notification emails, or sending generic “you have a new issue” messages only.
• Others warn stricter anti-spam will burden legitimate newcomers and that case-by-case moderation might be acceptable until abuse worsens.
• Some report fast GitHub responses to abuse reports; others report slow or inconsistent handling.

Developer habits and “curl | sh” culture

• Much debate about how normalized it is to copy-paste shell commands from websites, including official docs.
• Some argue devs are high-risk targets because they’re accustomed to installation commands and curl | sh patterns.
• Others differentiate between piping from well-known domains vs random ones, and prefer package managers with signatures.

Broader security themes

• Discussion of email links in general: many advocate “don’t click unexpected links,” but note this conflicts with common workflows (account verification, SaaS UX).
• Debate over OS design: Windows’ ease of full-privilege execution is seen as either a dangerous flaw or a “freedom” virtue; Linux/UNIX security is criticized as often undermined by sudo habits.
• Cloudflare’s role is discussed: easy hosting for phishing/malware but also more responsive than many registrars; abuse reporting is seen as clunky.

Rationale and effectiveness of the ban

• Many see banning pagers and walkie‑talkies at Beirut airport as a “no‑brainer” response to the booby‑trapped pager attacks.
• Others argue it’s mostly symbolic “security theater,” since explosives can be hidden in many other devices.
• Some expect the rule to last for years and potentially spread to other countries; others question how long political will will hold.

Detection challenges and future security measures

• Consensus that the explosives used were hard to detect with existing airport screening and remained undetected for months.
• Debate over whether modern CT / dual‑energy scanners would reliably spot such modifications:
  • One side claims CT makes airtight concealment irrelevant and should detect anomalous materials.
  • Others counter that many explosive types and dense organics blur this, and human operators are a weak link.
• Ideas floated: AI anomaly detection on X‑rays and harsh regimes like cryptographically attested “genuine” device parts, no small manufacturers, and effectively ending right‑to‑repair for any device that might board a plane.

Communications, tracking, and operational logic

• Strategic view: the attack raises the cost and risk of “untrackable” comms, pushing groups back toward slower or more traceable systems.
• Discussion of trackability:
  • Cellphones are easy to track; walkie‑talkies only when transmitting; classic pagers are receive‑only and largely untrackable.
  • Some note that even “passive” RF devices may leak signatures detectable with specialized networks, but this is seen as difficult and limited.

Supply chain and hardware tampering concerns

• Concern that sabotaged COTS devices set a precedent for turning everyday gadgets into bombs.
• Thread notes reports that the pagers were made in Taiwan, procured via a Hungarian front; some think Hungary or other intermediaries were deeply involved, others suspect the front company was entirely intelligence‑run.
• Speculation that Western states may now distrust foreign (especially Chinese or other) electronics supply chains, while some fear an opposite reaction in the “Global South.”

Legal and moral debate over the pager operation

• Reference to a global treaty banning booby‑trapped “innocent” objects; some argue this makes the operation clearly illegal.
• Others argue international law is effectively unenforced and thus largely symbolic.
• Strong disagreement over civilian harm:
  • One side claims thousands of civilian injuries from detonations in public spaces.
  • Others say evidence is unclear and that primarily Hezbollah members and close bystanders were hit.
  • It’s repeatedly noted that the “fog of war” makes casualty breakdowns uncertain.

Hezbollah, Lebanon, Israel, and Gaza context

• Extensive debate on Hezbollah’s nature:
  • Described variously as a terrorist group, a “mini‑state,” and a broad political party with seats in parliament.
  • Some emphasize its Shia base and alliances with Syrian/Iranian‑aligned Christian parties; others stress it is not equivalent to “Lebanon” as a whole.
• Moral positions diverge sharply:
  • Some frame Hezbollah as an Iranian proxy dragging Lebanon into unwanted conflict and hiding among civilians.
  • Others emphasize that the operation targeted widely distributed devices, so civilians near members effectively paid the price.
• Side debate links Lebanon–Israel tensions to the Gaza conflict, water control, and broader Islamic–Israeli/Palestinian dynamics, with participants disagreeing on root causes, relative victimhood, and whether this is an ancient religious struggle or a modern geopolitical one.
• One view portrays both sides as long‑standing antagonists driven by “memes” (religions/ideologies), with no clear moral high ground; another insists on differentiating state militaries and non‑state actors.

Security theater, civil liberties, and Western spillover

• Some expect US/EU to overreact with new bans; others note that newer scanners may quietly mitigate risk instead.
• Several argue that post‑9/11 aviation security has become excessive; banning personal electronics would be a red line prompting public backlash.
• At the same time, some participants accept more inconvenience (like a pager ban) over living under rocket fire, seeing such measures as a lesser evil.

Role of RealPage and Alleged Price-Fixing

• Several commenters discuss RealPage as an alleged rent-collusion hub: algorithmic “suggested rents,” defaults to use those rents, promises of always-rising prices, pressure on clients who undercut, and facilitating communication among large landlords.
• Some argue this converts fragmented, inefficient price-fixing into centralized, effective cartel behavior once enough units are on the system.
• Others are skeptical: rental markets were already transparent, landlords could see comps before, and RealPage is seen as marginal compared to broader forces.

Housing Shortage vs. Collusion as Main Driver

• One camp: the core problem is a housing shortage; rent is a big share of CPI, and even modestly faster rent growth can dominate inflation.
• Counterpoints: examples like NYC and Atlanta where population or vacancies don’t line up cleanly with rents; suggestions that units are kept vacant, or that latent demand (more space per person) explains tightness.
• Debate over whether vacancy rates alone capture “supply vs. demand,” given incentives to hold units off market and accounting/tax effects.

Zoning, Construction, and “Right Kind” of Housing

• Broad agreement that restrictive zoning (single-family mandates, height limits, long approvals) constrains supply and pushes developers toward high-end or luxury projects.
• Some cite evidence that even luxury construction eases pressure down-market via “filtering”; others argue in some countries demand growth still outpaces this effect.

Landlords, Rent-Seeking, and Ownership Models

• Intense normative dispute: some label landlords as low-value “rent-seekers” or parasites; others defend them as necessary capital allocators and property managers.
• Arguments over whether banning landlording or transferring units to tenants would help or cause worse shortages, financing issues, and maintenance failures.
• Ideas raised: rent-to-own requirements, co-ops, vacancy taxes, land value taxes, and “occupancy credits.”

Macro Policy and Inflation

• A thread attributes much inflation to massive COVID-era money creation and fiscal support, with asset owners ultimately capturing much of it.
• Modern Monetary Theory concepts are invoked: government spends by creating money, then taxes to destroy excess; disagreement over whether tax truly “destroys” money or just reallocates it.
• Suggested remedies include higher taxation on asset gains and wealth-like positions, vs. criticism that the root problem was printing so much in the first place.

HLSL, GLSL, Slang, and SPIR-V Direction

• HLSL is described as the de facto language for both DirectX and much of Vulkan; GLSL is seen as legacy.
• Khronos has reportedly stated GLSL will not get major new work; it lacks modern language features and modularity.
• HLSL is evolving (C++-like features, templates, mesh shaders, work graphs, modules).
• Some hope Nvidia’s Slang might become a Khronos-standard high-level language, but it’s unclear.

Impact on Proton/Linux Gaming

• If DirectX starts emitting SPIR-V instead of DXIL, translating shaders for Proton/Wine should become easier.
• Current DXIL→SPIR-V conversion is described as extremely painful; much of that complexity would vanish with native SPIR-V.
• There is mild concern about a potentially incompatible “DirectX-flavored” SPIR-V, but others consider divergence unlikely at the core level.

WebGPU, WGSL, and Apple/Khronos Tensions

• Many note industry participants originally wanted SPIR-V or HLSL for WebGPU, not a new language.
• WGSL is portrayed by several as a political compromise driven largely by Apple’s refusal to accept Khronos IP/SPIR-V, with formal meeting minutes cited.
• Some find WGSL syntactically unpleasant and a barrier to adoption; others appreciate its simplicity and clear spec.
• Native WebGPU backends typically use SPIR-V; browsers require WGSL, forcing costly SPIR-V↔WGSL conversions that some see as wasted effort.

Future of GLSL and Khronos Strategy

• GLSL is expected to receive only maintenance and vendor extensions, no major specs.
• Khronos reportedly lacks budget and language-design expertise; higher-level language choice is effectively pushed to the community.

DirectX vs. Vulkan on Windows

• Vulkan is considered a first-class option via vendor drivers, but not as deeply integrated into Windows as DirectX (no built-in loader, no WARP-like software path).
• Some argue replacing D3D12 with Vulkan would be harmful: Vulkan’s broader scope (including mobile) complicates design, and D3D12 can evolve faster through private IHV–Microsoft collaboration.
• Others counter that multiple APIs increase developer burden and lock-in; Vulkan is valued as the open, cross-platform option.

API and Spec Quality

• Opinions diverge: some say D3D11/12 and Metal are better designed and more practical than OpenGL/Vulkan; others praise Vulkan’s consistency and documentation.
• DirectX “engineering specs” are lauded as readable and implementation-aware, but criticized for being incomplete and under-specified in some areas.
• Vulkan/SPIR-V specs aim to be comprehensive formal contracts, though they are acknowledged as imperfect and sometimes hard to interpret.

SPIR-V Dialects and Tooling Fragmentation

• Participants note existing fragmentation: SPIR-V for Vulkan vs OpenCL already can’t share compilers cleanly.
• There is concern that a DirectX SPIR-V dialect may worsen this, limiting the hoped-for “unified IR” benefits.
• Some suggest the real blocker is organizational/ecosystem misalignment rather than technical impossibility.
• One view is that DirectX’s move to SPIR-V mainly lets Microsoft retire an old LLVM-based DXIL stack in favor of a better-specified bytecode.

Overall reaction

• Many commenters are excited about zb as a Nix-inspired, Lua-based, early-stage build system, especially for its design goals and Windows support.
• Some see it as “Nix-like but friendlier,” while others say they don’t yet see enough benefit over Nix to justify switching.

Language choice: Lua vs alternatives

• Several like Lua as a DSL: simple, embeddable, and expressive; some mention editor tooling and typed Lua variants as mitigations for lack of static typing.
• Others argue a declarative or statically typed language (Starlark, Scala-like, custom DSL) might better fit reproducible builds and reduce configuration pain.
• There is concern that a general-purpose, mutable language with top‑level variables can easily compromise hermeticity if not carefully sandboxed.

Nix, Bazel, Buck2 and theoretical grounding

• Lots of comparison to Nix: content-addressed store, sandboxes, non-determinism handling, live-bootstrap, and the heavy social/maintenance cost of wrapping arbitrary upstream build systems.
• Discussion of Bazel/Buck2: static vs dynamic build graphs, sandboxing, Starlark, genrules, and remote execution. Some want better Bazel–Nix–zb interoperability.
• The “Build Systems à la Carte” paper is referenced to frame dynamic dependencies and scheduler strategies (topological, restarting, suspending).

Sandboxing, nondeterminism, and hermeticity

• Commenters strongly stress sandboxing as non-optional; zb has Linux sandboxing prototyped and Windows sandboxing planned.
• zb’s explicit support for non-deterministic builds is seen by some as a valuable “escape hatch” that reduces friction when migrating existing workflows, but others worry it conflicts with strict reproducibility ideals.

Windows support and bootstrapping

• Windows support is a big selling point compared to Nix; people discuss MinGW, Visual C++–based bootstraps, and desire for a pure, Guix/ live-bootstrap–style story where possible.
• There is interest in using zb as a cross-platform package/build layer similar to Nix but with less friction.

UX, terminology, and ecosystem

• Multiple commenters criticize Nix’s terminology (“derivation”, “flakes”) and documentation as confusing; some suggest friendlier terms like “build plan” or “recipe.”
• Others defend keeping established terms for compatibility.
• Monorepo-based ecosystems (like Nixpkgs, Buck-style repos) are highlighted as crucial to long-term success; several urge zb not to rely on a fragmented package landscape.

Scope of the Change

• PREEMPT_RT is now a configurable option in mainline Linux, rather than an out-of-tree patchset or separate RT hypervisor.
• Much of the work centered on making kernel subsystems and locking more preemptible; printk and interrupt handling were recurring technical points.
• The RT patchset is now significantly smaller; some pieces (e.g., new printk paths in drivers) still need adoption.

What “Real-Time” Means Here

• Emphasis is on bounded worst‑case latency and predictability, not raw speed.
• RT Linux aims to ensure that high‑priority tasks can preempt others quickly and run to completion within deadlines.
• For strict hard real‑time and safety‑critical uses (e.g., car brakes, avionics), several commenters argue Linux—even with PREEMPT_RT—is still not ideal; specialized RTOSes or formally verified kernels (like seL4) are preferred.

Practical Use Cases and Experiences

• CNC and industrial control: LinuxCNC and similar systems rely heavily on RT; merge is seen as a major simplification for builds and deployment.
• Audio and music: Users report dramatic reductions in audio latency and dropouts, enabling low‑latency instrument setups and complex audio chains while the system is heavily loaded.
• Robotics, SDR, and embedded control: RT kernels reportedly provide microsecond‑scale jitter, making things like software-defined radio and flight control more robust under load.

Programming and System Design Practices

• Real‑time coding focuses on predictable execution: avoiding dynamic allocation, blocking syscalls, and complex variable‑time algorithms in RT threads.
• Designs often use periodic loops/state machines and offline scheduling or strict priorities.
• On MCUs, caches and advanced CPU features are sometimes disabled to avoid jitter; on Linux/x86 this is harder and interacts with power management, SMM, drivers, and multicore effects.

Desktop Impact and Trade‑offs

• Some claim little desktop benefit; others report noticeably better responsiveness and far more reliable low‑latency audio.
• Consensus: throughput is slightly lower and scalability somewhat reduced due to extra locking and scheduling work, but often not visible on typical desktops.
• Misconfigured priorities or buggy drivers can still cause latency spikes; RT is not a magic fix, just a better foundation.

Ethical status of turning gadgets into bombs

• Many see these attacks as crossing a new line by weaponizing ubiquitous civilian tech, eroding basic trust in everyday objects.
• Others argue war has long involved hidden explosives (suicide bombers, car bombs), so this is not qualitatively new, just another delivery mechanism.
• There is concern that once a “respectable” democracy uses such tactics and major powers endorse it, the tactic becomes normalized and spreads.

Israel–Hezbollah pager/battery attack

• Some commenters frame the pager operation as an extremely precise strike on militants, with unprecedented militant-to-civilian casualty ratios, and therefore a “legitimate weapon of war.”
• Others emphasize the civilian injuries (including at least one child killed) and argue this is indistinguishable from terrorism: attacking people in civilian settings using disguised weapons.
• Disagreement over whether such attacks will actually reduce future violence or simply escalate and inspire copycats.

Norms, war crimes, and terrorism definitions

• Several argue for quickly stigmatizing and codifying such attacks as war crimes, likening them to chemical weapons: cheap, effective, but largely unused due to taboo.
• Debate over the definition of terrorism: some stress that using hidden bombs in civilian life by non-state actors clearly fits; others say state use against militants is different.
• Broader disputes appear over proportionality, “state vs terrorist” double standards, and whether condemning one side while excusing the other is coherent.

Technical feasibility and supply-chain risk

• The thread reinforces that booby-trapped batteries are technically straightforward, cheap, and very hard to detect; supply-chain insertion is plausible.
• People worry about downstream effects: phones, laptops, medical devices, remotes, toys, airline safety, and mass recalls or bans if such attacks proliferate.
• Some predict public and infrastructure resilience (“people will move on”); others foresee major security changes, especially in aviation.

Mitigations: openness vs control

• One camp argues for open hardware and FLOSS as a partial defense: more auditability, less “black box” trust.
• Another camp stresses secure, signed firmware and roots of trust controlled by manufacturers as more realistic protection.
• Both sides acknowledge these measures are incomplete against sophisticated state or criminal actors and that tamper-evident design may be necessary but hard.

How to Discover Leonard Cohen

• Many suggest starting with compilations: “Best Of” or “Essential” collections, or a mid-career greatest-hits album.
• Others recommend full albums: early trilogy (“Songs of Leonard Cohen,” “Songs from a Room,” “Songs of Love and Hate”), accessible later albums (“I’m Your Man,” “The Future,” “Ten New Songs”), or the late-career “You Want It Darker.”
• Several endorse live albums (“Live in London,” “Live in Dublin”) as friendly entry points that showcase his stage presence and core songs.
• Advice includes: don’t judge by one song (especially “Hallelujah”); expect lyric-driven, often spoken-word-like music that rewards repeated listening.

Albums, Eras, and Production

• Early work: sparse “man and guitar” arrangements seen as revelatory, with consistently high songwriting and production.
• 80s and later: electronic/synth textures divide opinion. Some call them dated or “chintzy”; others praise the modernization as a smart, distinctive move.
• Late albums are described as elegiac and emotionally intense, with his deep, gravelly voice treated as definitive by some and off-putting by others.

Covers vs. Originals

• Many commenters discovered him through film/TV soundtracks and covers (e.g., multiple well-known versions of “Hallelujah,” “Everybody Knows,” “Famous Blue Raincoat,” “Who By Fire,” “Chelsea Hotel,” “First We Take Manhattan”).
• Some strongly prefer covers, feeling other singers elevate his songwriting; others insist only his own delivery truly suits his songs.
• A tribute/cover album by various alternative/indie artists is highlighted as a good gateway.

Reception of “Hallelujah”

• Opinions are sharply split: some find the original powerful; others “viscerally hate” it yet enjoy certain covers.
• There is criticism of its drift into a generic “Christmas song,” seen as missing the song’s irony and mix of sacred/profane.

Legacy, Persona, and Other Work

• Widely praised as a major poet and novelist as well as songwriter; specific poetry collections and a novel are recommended.
• Commenters recall powerful concerts even in his 70s, documentary narration, and film soundtracks.
• Overall tone: deep admiration for his writing, coolness, and unpretentious personality, with acknowledgment that he remained more cult figure than chart star.

Scope of FTC Report & Government “Cognitive Dissonance”

• Many see tension between agencies pushing mass surveillance (intel/law enforcement) and the FTC condemning surveillance capitalism.
• Others argue this isn’t hypocrisy: government isn’t monolithic, different parts legitimately disagree; hypocrisy lies more with voters who accept corporate tracking but oppose state surveillance.
• Some call the report overdue by ~15–20 years but still welcome.

Corporate vs Government Surveillance

• One side: governments are uniquely dangerous due to monopoly on violence and history of states turning on their own populations; corporate data hoards mainly matter because states can access or buy them.
• Other side: corporations are not “just another actor”; their mass data collection is itself harmful and structurally enables state overreach.

Harms of Data Collection & Telemetry

• Privacy advocates argue:
  • Privacy violations are harm per se; consent is often coerced or opaque.
  • Risks include behavioral manipulation, discriminatory pricing, stalking, identity theft, reduced security, and chilling effects.
  • Ad/RTB data is reportedly used in military/intelligence targeting.
• Skeptics demand concrete consumer harms and claim:
  • Two decades of ad tracking haven’t produced obvious widespread damage.
  • Much telemetry improves security and subsidizes free, high‑quality services (Gmail, Chrome, YouTube).
  • People rationally choose “free + ads” when explicitly given the option.
• Strong dispute over whether “I can opt out / don’t use the app” is realistic, given dark patterns and network effects.

Credit Bureaus, Data Breaches, and Liability

• Deep resentment toward CRAs (Experian, Equifax, TransUnion, Innovis) for collecting data without consent, leaking it, then pushing spam and upsells.
• Several anecdotes of breaches, spam, and even a small processor emailing an entire customer database to one client.
• Proposed fixes:
  • Shift fraud losses from victims to lenders/credit reporters.
  • Statutory per‑record damages so breaches become existentially expensive.
  • Treat personal data as “radioactive”: collect only when absolutely necessary.
• Counterpoints: hard to prove individual harm or trace which breach; concern about who exactly should be liable and under what standard of care.

Snowden, Culture, and Mass Surveillance

• Some say Snowden marked a “last chance” moment; public mostly shrugged (“nothing to hide”), showing cultural acceptance or fatigue.
• Others insist mass surveillance predates Snowden and was legislatively visible; see focus on him as overblown.
• Broader sense that people either don’t understand the stakes or feel powerless, and that younger users grew up inside the system.

Ads, Business Models, and “Free” Services

• One camp defends targeted advertising as a major economic achievement that efficiently matches buyers and sellers and funds free platforms.
• Critics argue:
  • Effective targeting doesn’t require deep identity dossiers; context (e.g., topic groups) is enough.
  • Many FTC‑cited harms (e.g., sensitive inferences like pregnancy or sexuality) are non‑trivial, especially for vulnerable users.
  • True “privacy vs free” tradeoffs are rarely presented transparently; even paid tiers often don’t end tracking.

Policy & Regulatory Ideas

• Calls for:
  • Stronger FTC enforcement and higher liability for mishandling data.
  • Treating shared secrets (SSNs, card numbers) as obsolete; move to architectures that don’t expose reusable tokens.
  • EU‑style opt‑out pricing or independent “tech FDA”-like oversight (some doubt psychiatry/mental‑health science is ready for being a regulatory basis).
• Skepticism about meaningful reform due to lobbying and political tradeoffs; belief that “safety rules are written in blood” and change may follow a major catastrophe.

Practical User Defenses & Alternative Architectures

• Advice: freeze (not just “lock”) credit at all major bureaus; consider ChexSystems; use ad blockers, YouTube downloaders, and extensions that strip recommendations/shorts.
• Interest in end‑to‑end encrypted, decentralized social media designs where platforms can’t inspect content; others argue “E2EE social media” is conceptually hard or incomplete.
• General sentiment that today’s mainstream platforms are structurally user‑hostile and addictive, but alternatives face huge adoption barriers.

Proxy bandwidth pricing & infrastructure

• Many are shocked by $500 for ~200 GB, noting standard cloud egress is around cents per GB, not dollars.
• Commenters deduce the cost comes from residential rotating proxy providers, not normal cloud bandwidth.
• Residential proxy prices cited: roughly $1–10/GB, consistent with the bill shown.
• Some argue colocation and paying for committed throughput would be far cheaper, but others note that datacenter IP ranges are routinely blocked for scraping.

Residential proxies: sourcing and ethics

• Multiple posts claim many residential proxies come from malware, shady “free VPNs,” compromised devices, and browser extensions, effectively forming botnets.
• Others point to “ethical” models: users paid for bandwidth, or free apps/VPNs that clearly disclose proxy usage.
• Skeptics counter that “ethical” claims are hard to verify, users often don’t understand the implications, and such use may violate ISP terms and harm IP reputation.
• Debate over whether working directly with ISPs to host “ISP proxies” in datacenters is more acceptable.

Use cases and “sketchiness” debate

• Some see residential proxies and CAPTCHA-solving as markers for a gray/black-hat ecosystem: ticket scalping, credential stuffing, spam, fraud.
• Others defend legitimate automation: browser-based workflows where no API exists (e.g., CRM data entry, heavy travel booking, price comparison).
• Disagreement on where the ethical line is, especially for bypassing CAPTCHAs or access controls that enforce paid APIs.

Managing dependencies & Chrome behavior

• Several focus on the root cause: Chrome/Chromium silently downloading large updates/extensions, which on expensive proxies becomes costly.
• Discussion about “hard dependencies” on Google: changes can have real financial impact with little notice.
• Suggested mitigations: anomaly detection on proxy usage, documenting integration points, and planning for alternative stacks.

ISP terms, legal risk, and liability

• Concern that residential proxy participants may violate ISP AUPs and risk throttling, bans, or even law-enforcement visits for traffic they didn’t originate.
• One side argues responsibility lies with the end user who consented; another raises potential tortious interference and reputational damage to ISPs.

Broader ecosystem & reactions

• Anticipation of an arms race: more residential proxy usage by AI/scrapers, and more aggressive countermeasures (e.g., serving huge files to suspected bots).
• Frustration that the “open internet” is deteriorating due to abuse, CAPTCHAs, and IP blocking.
• Some note the irony that consumers treat 200 GB as trivial for gaming, while in this context it costs hundreds of dollars.

Use case and purpose

• Product is seen as a way to mount sub‑6 GHz 5G small cells inside buildings while serving outdoor streets, especially where low‑E glass severely blocks RF.
• Commenters note it simplifies landlord concerns (no roof penetrations, weatherproofing) and may reduce visual impact compared to exterior masts.
• Some argue it’s mainly for outdoor coverage; others assume indoor-coverage small cells but are corrected by article quotes emphasizing outdoor service.

Technical design & materials

• Antenna uses transparent conductive films (e.g., ITO / transparent conducting films) laminated between glass layers, tuned together with the specific window.
• Patent indicates a ground plane on the rear so radiation is intended outward, through the glass.
• Clarification that glass itself is not the conductor; it’s a substrate and spacing element.
• Comparisons are made to transparent conductors already used in touchscreens and displays.

Performance, RF exposure, and frequencies

• Product targets sub‑6 GHz 5G, not mmWave. Sub‑6 has better penetration but still suffers from low‑E coatings.
• Debate over power levels near occupants: some worry about sitting close to a base station, others note regulatory exposure limits and relatively low small‑cell power, with one rough calculation suggesting tens of watts could be safe at ~8 ft.
• Some confusion over whether energy “stays in the building,” countered by the presence of a ground plane and outward orientation.

Aesthetics and integration

• Mixed views on how “transparent” or “inconspicuous” the prototype is; visible feeder lines and added glass panel draw criticism.
• Others argue it’s sufficiently unobtrusive for most commercial spaces, and easier to integrate than bulky plastic boxes.
• Questions raised about antenna lifetime vs. building lifetime and whether the glass complexity is justified versus a simple internal box.

Relation to existing technologies

• Parallels drawn to permeable train windows, car glass antennas, and other “hidden” or facade‑integrated antennas.
• Links given to similar or related products (phased‑array glass antennas, window‑mounted 5G repeaters).

Mesh 5G and community networks (tangent)

• Long side discussion on whether community‑run 5G mesh could replace operators.
• Skeptics cite interference, latency, shared‑medium limits, unreliable volunteer hardware, governance and legal issues; experience with past mesh projects supports this pessimism.
• Proponents say it’s technically possible but acknowledge spectrum licensing and operational complexity make it effectively equivalent to running a carrier.
• Helium and LoRaWAN efforts are mentioned as partial/crypto‑driven examples, with limited success.

Critique of the article and media

• Some pushback on IEEE Spectrum’s technical phrasing (e.g., about mmWave “delivering bandwidth”), arguing it’s conceptually sloppy.
• One commenter notes the apparent use of an AI‑generated promotional image and questions the practice.

Faith, spirituality, and “spiritual bypass”

• Some argue faith/religion help people let go of regret.
• Others describe “spiritual bypass”: using religion/spirituality to avoid processing difficult emotions, offloading responsibility to a higher power.
• Debate over Christian ideas like “carrying one’s cross”: some see it as encouraging growth and clean slates; others say it personalizes suffering and traps people in guilt instead of learning and moving on.
• Modern “spiritual” movements (astrology, crystals, “vibrations”) are criticized as shallow and psychologically unhelpful.

Cognitive strategies for handling regret

• Reframe regret as data for future decisions: “focus forward,” blameless postmortem style.
• Some mentally expect to make new mistakes later; this shifts attention from ruminating on the past to choosing a better future.
• Mindfulness: focus on the present; past is unchangeable, future is a mental construct that can fuel anxiety.
• Treat painful episodes as “cheap lessons” that prevent larger future losses.
• Viewing regret as a universal human experience reduces shame (“my brain doing what brains do”).
• Portfolio mindset is seen as limited when one regret (e.g., divorce, long relationship) dwarfs the others.

Stoicism, fatalism, and responsibility

• Stoic-inspired approach: be fatalistic about past and present (they “had to” happen) but active about shaping the future.
• Supporters say this preserves tranquility and avoids irrational regret.
• Critics worry it can become self-deception or passivity; they prefer emphasizing action and responsibility, then self-forgiveness.
• Some reconcile this: accept that you did the best you could with the information and context then; regret is irrational if the decision was reasonable at the time.

Money, windfalls, and life-course regret

• Multiple crypto anecdotes (Bitcoin, Litecoin) illustrate huge “missed gains” and how people rationalize them (would have sold early anyway, or a big windfall might have been destructive).
• Discussion of how large sudden wealth can amplify risk-taking, addiction, relationship breakdown, and fear of loss.
• Others push back on romanticizing poverty; love/fear aren’t strictly tied to wealth.

Emotional complexity and self-forgiveness

• Some find it easy to accept “logical” past mistakes but struggle deeply with regrets involving hurting others or social failures.
• Intrusive memories and lifelong regret are framed as qualitatively different from small experimental losses.
• A few note a “superpower” of low embarrassment about past cringe, enabling faster learning and progress.

Overall market conditions

• Many see a correction rather than a collapse: post-2020 “red carpet” boom is over, but not comparable to past busts like 2002.
• Some argue tech jobs are “drying up,” especially for generic web work and juniors; others report steady inbound recruiter interest, with strong local variation (e.g., Europe vs US).
• Several note that companies are trimming after over-hiring and cheap-money years, not eliminating software work altogether.

AI’s impact on hiring

• Strong view that AI is shifting resources: AI/ML specialists are paid multiples of regular engineers, and budgets for other roles are squeezed.
• Others argue AI mostly boosts individual productivity; work still exists but fewer additional headcount gets approved.
• Skeptics say many AI-driven decisions are based on vibes, not measured productivity gains; tools haven’t truly “replaced” full developers yet.
• Some see AI as a long-term job creator via automation of other sectors (factories, etc.), needing more devs and infra roles.

Early-career paths, degrees, and bootcamps

• Consensus that the market is much harsher for juniors, bootcamp grads, self-taught devs, and non-technical “in tech” roles (marketing, HR, recruiting).
• Multiple comments claim that, compared with mid-career CS grads, these groups now have little edge and struggle to even get interviews.
• Counterexamples exist where bootcamp grads with strong portfolios or OSS work do fine, but they’re portrayed as the exception.

Interview process and competition

• Several experienced engineers report months of applications, many final rounds, and rejections for minor stylistic reasons; surplus of candidates lets companies be extremely picky.
• Perception that employers want “hit the ground running” hires; very few roles allow multi-month ramp-up.

Visas, policy, and RTO

• Some see H1B and similar programs as flooding a saturated market and propose tying layoffs and visa hiring.
• Others emphasize structural issues: employer-tied visas create vulnerable workers and distort labor markets; suggestions include EU-style profession-based visas.
• One view links aggressive return-to-office policies to a strategy for increasing visa-heavy hiring.

Career sustainability

• Burnout and disillusionment appear, especially among mid/late-career engineers seeing rising responsibilities, stagnant interest, and a punishing market.

Overall sentiment

• Many see Tracker’s shutdown as “the end of an era” and express genuine sadness.
• It’s frequently described as the least-bad or best PM tool they’ve used, especially compared to Jira and Azure DevOps.
• Some argue all PM tools/to‑do apps are largely interchangeable and low‑moat, so its demise isn’t surprising.

Why Pivotal Tracker Was Liked

• Praised for simplicity, opinionated design, and staying out of the way.
• Core concepts like a single prioritized queue (icebox/backlog/current), velocity-based auto‑planning, and a small fixed set of states are seen as powerful and clarifying.
• Users liked the dense, one‑screen UX, keyboard‑centric flow, and limited customization, which reduced process bloat.
• It was valued for making tradeoffs visible to stakeholders and improving predictability.

Critiques and Limitations

• Some found it too rigid: missing states around deployment/user validation, weak higher‑level views for multi‑team coordination, and limited “enterprise” features.
• A few felt it was overly simplistic once workflows got complex and preferred more customizable tools.

Alternatives and Migration Plans

• Common suggestions: Linear, Shortcut (with explicit PT importers), GitHub Projects, Trello, Taiga, Basecamp, and various open‑source/self‑hosted tools (e.g., Redmine, OpenProject, Plane, Phorge).
• Linear and Shortcut are most often cited as spiritual successors; Linear is praised for UX and support, Shortcut for being closer to PT’s model.
• Concerns that promising tools eventually bloat (often to chase enterprise/VC returns) and add heavy AI features.
• Some continue to prefer spreadsheets/Google Docs; others list concrete reasons they break down at scale.

Pivotal Culture and Pair Programming

• Extensive discussion of Pivotal’s pairing/TDD culture: many ex‑users remember it as their most productive and enjoyable period; others found mandatory pairing exhausting or incompatible with their work style.
• Some current teams still practice daily pairing and report benefits in quality and knowledge sharing.

Business and Open‑Source / Clone Debates

• Shutdown is broadly attributed to the VMware→Broadcom acquisition chain and Broadcom’s focus on cost-cutting and high-margin products.
• Several ask for Tracker to be open‑sourced; others debate whether law should require code escrow or open‑sourcing after some time or public funding.
• Multiple commenters see a business opportunity to build a PT clone; others doubt the long‑term profitability of PM tools or note that if PT were highly profitable it likely wouldn’t be shuttered.

Adoption, incentives, and “is IPv6 worth it?”

• Some say IPv6 is clearly “here” (near half of Google traffic, strong mobile support) and launching IPv4-only projects in 2024 is a mistake.
• Others argue IPv6 is optional: nothing is dropping IPv4 soon, dual‑stack adds complexity, and running IPv4‑only is “radically simpler” with few downsides.
• Several note cloud and ISP economics pushing IPv6 (IPv4 address charges, scarcity, CGNAT costs), but also that big providers don’t heavily incentivize it beyond basic support.
• There is disagreement whether IPv6 is a success (steady adoption after IPv4 exhaustion) or a “failed project” due to slow, long‑tail migration.

IPv4–IPv6 interoperability and NAT64

• A recurring confusion: IPv4 is not inherently “accessible over IPv6”; an IPv6‑only host cannot talk to IPv4 without translation.
• NAT64/DNS64 are repeatedly cited as the practical bridge: most real‑world IPv6 deployments use them to reach IPv4‑only sites, at the cost of extra infrastructure and some latency/complexity.
• Some see this as an acceptable design (similar to NAT on IPv4); others call it a “missed opportunity” but struggle to propose a realistic native‑compatibility alternative.

Complexity, usability, and design trade‑offs

• Pro‑IPv6 comments emphasize: simpler header, no fragmentation by routers, unified ICMPv6 control, stateless autoconfiguration, huge address space eliminating NAT and RFC1918 conflicts.
• Critics highlight: multiple address assignment mechanisms (SLAAC, RA, stateful/stateless DHCPv6), privacy addresses, and non‑obvious DNS precedence, making it harder to reason about than small IPv4 networks.
• Some see dual‑stack as almost free (OSes and libraries already support both); others focus on human and operational overhead: staff must understand two stacks, tools, and failure modes.

NAT, performance, and operational pain

• Strong sentiment that NAT is an ugly but necessary IPv4 band‑aid, causing protocol contortions (STUN/TURN/ICE), complicated VPN/VoIP/security, and severe issues at CGNAT scale (overload, port exhaustion, extra latency).
• Others counter that per‑packet NAT overhead is microseconds and not a material latency/bandwidth bottleneck for typical home use; problems stem from under‑provisioned ISPs, not NAT itself.
• Several note IPv6 simplifies VPNs and internal addressing (no overlapping RFC1918, easy /48–/64 allocation), and can avoid deep NAT chains that become unmaintainable.

Address space, “IPv5” ideas, and backwards‑compatibility debates

• Some wish for “IPv4 but bigger” (incremental extension preserving all existing /32 blocks), claiming IPv6 overreached and forced a hard migration.
• Others explain why that’s infeasible: routers and hosts can’t handle larger addresses without upgrades anyway; extended headers break legacy return‑path routing; DNS and APIs would still need new types.
• Consensus among defenders: any non‑trivial alternative would require essentially the same global upgrade effort and coexistence story as IPv6.

Obtaining and routing IPv6 blocks

• For independent space, commenters mention: getting provider‑independent IPv6 (e.g., /48), an ASN, and peering via BGP; or having ISPs announce your prefix with an LOA.
• Tunnel brokers (e.g., HE) can give free /64 or /48 over IPv4, but add latency, CDN path issues, and abuse‑related blocking.
• Business‑grade ISPs commonly support BGP for customer prefixes; residential ISPs usually do not.

Real‑world IPv6‑only and dual‑stack experiences

• Some operators run IPv6‑only management or internal networks with NAT64 at the edge, reporting simpler routing, firewalls, VPNs, clustering, and fewer address‑management headaches.
• Others tried IPv6‑only and reverted due to cloud provider gaps and software that assumes IPv4 presence even for local services.
• There is frustration that many modern tools and devices (e.g., some streaming boxes, telemetry servers) still lack proper IPv6 support, forcing continued IPv4 or expensive translation layers.

Concept of Drift and Normalization of Deviance

• People describe how small, local optimizations under pressure (faster, cheaper, less hassle) gradually push systems toward failure boundaries.
• Over time, rule-breaking becomes routine and no longer feels deviant, even when it clearly violates original safety assumptions.
• This is seen as a general pattern across domains, not just in physical safety.

Corporate Culture, Boeing, and Managerialism

• Several commenters argue Boeing is no outlier; it has converged toward a broader US corporate culture prioritizing short‑term profit over engineering judgment.
• Cited drivers: finance/MBAs displacing domain experts, weakened antitrust, “shareholder value” ideology, and a managerial “caste” that believes in perfect plans executible by interchangeable workers.
• Others emphasize duopolies and weak competition as enabling bad products to survive.

Safety-Critical Organizations and Officially Sanctioned Deviance

• NASA’s shuttle program is discussed as a case where deviations were deliberately cataloged and repeatedly judged “acceptable,” making risk routine rather than exceptional.
• Nuclear power and Chernobyl are used to illustrate how planned tests and low‑probability edge cases can expose catastrophic failure modes.
• Healthcare is described via the “Swiss cheese” model: many overlapping safeguards, but rare alignments of small failures still injure patients.

Everyday Tools and Personal Risk Drift

• Multiple anecdotes (angle grinders, chainsaws, table saws, climbing) show how initial caution erodes with familiarity until a near miss or injury.
• Removing guards, using the wrong tool because it’s nearby, and accepting “pro” norms that look risky from the outside are recurring themes.

Software Engineering and Testing

• Parallels are drawn between physical safety and software practices: test coverage starts high then is eroded under delivery pressure.
• Debate over test costs: some see heavy testing as essential risk mitigation; others note long, expensive tests and incidents where test code itself caused failures.
• Frontend/UI testing is seen as particularly hard; visual regression tools are mentioned as a partial answer.

Mitigation Strategies and Limits

• Suggestions: zero tolerance for undocumented procedure deviations plus fast, formal mechanisms to update procedures; defense in depth; treating noncompliance as a design problem, not individual blame.
• Skepticism that individuals can change culture without authority; true safety culture requires coordinated leadership across departments.
• Heuristics for spotting trouble: frequent “if they had just…” narratives, pressure to remove safeguards, and long‑standing deviance that has merely “worked so far.”

Overall reaction

• Many commenters are enthusiastic about the tool’s simplicity: “two commands” to get from bare VPS to running app, with zero-downtime deploys and automatic TLS seen as standout features.
• Several people say they already have custom scripts/Ansible/Docker Compose setups, but would still try this because it lowers friction for side projects.
• Some feel they’d rather keep manual control (Compose + reverse proxy + certbot) and see this more as a convenience layer than a necessity.

Intended use case & comparisons

• Target use case is clearly personal apps/side projects on a single VPS, not large multi-node deployments.
• Compared often to Fly.io (“imagine fly.io on your VPS”), Kamal, Dokku, CapRover, Coolify, Portainer, and homegrown Ansible setups.
• Distinction from Kamal: Kamal is described as more “one big app per VPS” and more Rails-centric; this tool explicitly aims at multiple projects on one box.
• Some see it as close to “Dokku + provisioning/setup,” which they consider ideal.

Docker, deployment model, and registry

• Tool is container-centric; some Docker skeptics argue simple binaries and systemd are easier and more reliable for single-OS deployments.
• Others strongly defend Docker/Compose for isolating dependencies, simplifying migrations between servers, and running mixed workloads.
• Question raised: why require a registry? Author’s rationale (from thread) is: build images on the dev machine, keep source off prod, and push images instead of building on the VPS.
• Alternatives suggested: docker save/load over SSH or a local/private registry to avoid external dependencies.

TLS, reverse proxy, and networking

• Automatic TLS via Traefik is widely appreciated; several note that nginx + certbot automation is fiddly.
• Some users describe alternative patterns:
  • Cloudflare Tunnels or similar to avoid exposing ports and offload HTTPS and some security.
  • Caddy as a simpler auto-HTTPS reverse proxy.
• Concerns raised about Cloudflare lock-in, reliability of tunnels, and extra latency vs. direct nginx/Caddy.

Databases, backups, and reliability

• Roadmap includes database support; commenters push hard for:
  • Built-in streaming backups (Litestream for SQLite, Barman for Postgres) and possibly a dedicated backup VPS.
  • Clear restore workflows and monitoring of replication health.
• There is a broader argument that many self-host tools lack robust, integrated backup/restore, which some see as a serious gap and others dismiss as overkill for hobby projects.
• Suggestions include filesystem-level snapshotting (e.g., ZFS) versus app-specific backup logic; others note most VPS users just rely on provider snapshots or simple dumps.

Swarm, Kubernetes, and orchestration scope

• Question raised: why not Docker Swarm? Some argue Swarm (in single-node mode) already provides zero-downtime, rollbacks, secrets, etc.
• Author clarifies the tool targets a single VPS and does not use Swarm; another commenter notes Swarm’s confusing “classic vs new” history but that current Swarm is maintained.
• Kubernetes is generally seen as overkill here; some report long-term stability issues with managed Kubernetes vs. simple Docker/Compose on a VPS.

Security and VPS lifecycle concerns

• Requests for extras: basic WAF or intrusion blocking (fail2ban/CrowdSec), VPN/zero-trust access, and clearer explanation of sops/age-based secrets.
• Some question the value of encrypting env files on the VPS when the decryption key is also there; others point out it still protects against all users who can SSH but don’t hold the key.
• A few ask for guidance beyond initial deploy: OS patching, Docker upgrades, upgrading stateful services like Postgres, and migrating to a new host. They see this “long-term ops” story as missing in most similar tools.

Platform, multi-app, and OS choices

• Clarifications sought on whether multiple apps per VPS are supported (they are, per responses in thread).
• Some want docker-compose support, deploy hooks (pre/post deploy), Mac mini or non-Ubuntu support, and possibly anycast/multi-region in the future.
• One commenter questions Ubuntu as the base, preferring Debian and disliking snaps; others note recent Ubuntu is “fine by default,” but this remains a taste/ops preference.