Hacker News, Distilled

Value of the write-up / learning resources

• Many find the article unusually clear and code-focused compared to the dense, hyperlink-heavy WebAuthn specs.
• Some report it finally helped them understand evolving standards (U2F → FIDO2 → WebAuthn → passkeys).

Complexity and usability of WebAuthn

• Several commenters view WebAuthn/passkeys as over-complex and “enterprise-shaped,” with ease of implementation seemingly a low priority.
• Complaints include confusing UX around registration, credential discovery, authenticatorAttachment, and inconsistent site flows.
• There’s frustration that WebAuthn is tightly tied to browser JavaScript APIs with no simple non-browser/CLI path.

Passkeys, syncing, and user control

• Big concern: synced, “discoverable” passkeys feel paternalistic and lock users into vendor ecosystems and paid sync services.
• Lack of robust export/import at launch is widely seen as user-hostile; some expect eventual export but fear “approved provider” lock-in.
• Others note local/no-sync implementations exist (e.g., password-manager-based or self-hosted vaults) and argue “you have to trust something,” though some strongly reject needing to trust any online sync.

Hardware tokens vs software and key management

• Debate over resident (discoverable) vs non-resident credentials:
  • Non-resident hardware keys praised for phishing-resistant MFA without capacity worries.
  • Resident keys introduce storage limits and management pain (deleting individual credentials, full slots, needing multiple keys).
• Newer hardware supports more resident keys and credential management, but UX is still considered clunky.

Security comparisons: passwords, OTP, WebAuthn

• Some argue strong, unique passwords plus TOTP is a practical “sweet spot.”
• Others emphasize TOTP/SMS are phishable and replayable; WebAuthn’s URL-bound, non-replayable design is seen as a major security upgrade.
• Push-based MFA and “pick the right number” flows are criticized as vulnerable to MFA fatigue and social engineering; “type this number in” is seen as slightly better but still phishable.

Standards process, power, and attestation

• Strong skepticism that WebAuthn/passkeys are corporate-driven and user-controlling.
• Others counter that work happened in public (W3C lists, GitHub), though dominated by big companies.
• Attestation is controversial:
  • Critics say it lets sites whitelist/blacklist authenticators, undermining user freedom.
  • Others claim major platform passkey implementations have effectively dropped attestation for synchronized credentials, limiting this risk, though references show attestation still exists in some non-passkey or enterprise/MDM contexts.

Implementation pitfalls and tooling

• Noted registration edge case: credential created on client but never recorded server-side (network failure) leading to “split brain” where authenticator thinks it works but server does not. A proposed “Signals API” aims to address this; implementation status is mixed.
• Chrome DevTools’ virtual authenticator is suggested for testing, but there’s no simple curl-style tool for WebAuthn flows.

Adoption trade-offs and user behavior

• Some see passkeys as clear progress and already use them alongside passwords for convenience.
• Others refuse to use services that drop passwords, or view passkeys as a “manufactured solution” that centralizes control and complicates recovery and portability.

Scope and Intended Use

• Lens is described as an industrial/automotive component, not a photographer-oriented product.
• Target use: vehicle situational awareness / ADAS (wide view for nearby pedestrians/cyclists plus detailed view far ahead).
• Some commenters note Nikon’s core strength is optics and see no obvious need for exotic sensors/ISPs beyond the lens design.

Lack of Images and Article Critiques

• Multiple people note there are no sample images anywhere (even in Nikon’s press release).
• This is viewed as suspicious or “clickbait-like,” though others assume images are embargoed until CES.
• Some complain the linked site is ad-heavy, hard to navigate, and thin on technical detail.

Optical Design Speculation

• Ideas floated include:
  • Variable focal length across the image plane (higher magnification at center).
  • Concentric optics: telephoto center + wide “donut” fringe.
  • Beam-splitting prisms or pick-off mirrors feeding multiple sensors.
  • Anamorphic or “reverse-corrected” / foveated projection concentrating resolution in the center.
• Several note significant downstream processing will be needed to make the raw output useful or human-viewable.
• Some emphasize that whatever the scheme, true single-axis alignment (no parallax) is key.

Cropping vs Telephoto and Optical Limits

• Debate on whether telephoto is just a crop of wide-angle:
  • One side: in ideal optics, yes; perspective differences in practice come from camera distance, not focal length.
  • Others argue real lenses, f-numbers, diffraction, and distortion complicate the equivalence.
• Related discussion on depth of field, aperture equivalence, angular resolution, and why high-megapixel sensors alone don’t replace optical magnification.

Potential Impact and Extensions

• Some think 200+ MP sensors plus this lens could be powerful; others question processing and optical sharpness in a moving car.
• A few see possible future smartphone applications: foveated capture, simultaneous wide/tele capture, and after-the-fact zoom.
• Others note user downsides: larger files, storage pressure, and complexity of managing multiple versions per shot.

Overall Sentiment

• Interest and curiosity from optics/vision-minded commenters.
• Skepticism due to missing technical details and images; many defer judgment until CES reveals more.

Critiques of the Article’s Premise

• Many say the article misunderstands introversion/extroversion, treating them as choices or “mindsets” rather than relatively stable traits about how people recharge.
• Strong pushback against the claim “everyone is an introvert and everyone is an extrovert” and that you should “be extrovert at work.”
• Several see it as ableist: it assumes neurotypicality, trivializes genuine limits, and frames social difficulty as laziness or “excuses.”

Introversion, Shyness, and Social Anxiety

• Multiple commenters distinguish:
  • Introversion: social interaction is energetically costly, even if enjoyable.
  • Shyness/social anxiety: fear of judgment or panic in social situations.
  • These can overlap but are not the same.
• Some note they are highly social, speak publicly, or lead teams, yet are still introverts because they need extensive solitude to recover.

Neurodivergence and Masking

• ADHD, autism, and related conditions are repeatedly mentioned as missing from the article.
• “Masking” is described as performing socially “acceptable” behavior that doesn’t come naturally and is exhausting even if the skill level is high.
• Several neurodivergent posters say “just practice” rhetoric feels like being told a depressed person to “just go outside,” and can worsen burnout.

Labels: Helpful vs Limiting

• One strong thread: labels (introvert, autistic, queer, leftist, etc.) can:
  • Help people find community, tools, and explanations.
  • Also become shackles or excuses that restrict experimentation and growth.
• People disagree on whether avoiding labels or embracing them is healthier; both benefits and risks are reported.

Social Skills, Work, and Fairness

• Broad agreement that communication and visibility matter for careers, but disagreement on:
  • Whether everyone “must” push toward extroverted behavior.
  • How much office politics and likability overshadow raw contribution.
• Some recommend “social gym” approaches (gradual practice); others say they tried this for years and only got more exhausted.

Context, Compatibility, and Hosts

• Many argue energy cost depends heavily on context and who you’re with; “tribe” and fit matter more than raw introvert/extrovert labels.
• Criticism of the article’s party anecdote: good hosts should mediate introductions or offer quiet space, not pressure or pathologize withdrawal.

Value of Living Near Friends

• Many describe strong benefits when friends live within walking distance: shared childcare, easier socializing, emotional support, and richer daily life.
• Several examples: friends co-buying townhomes, moving into the same apartment complex, forming “tiny neighborhoods” or informal co‑housing.
• Some see this as especially powerful for families with young kids: “it takes a village” becomes practical reality.

Making New Friends vs Moving to Old Ones

• One camp says: don’t uproot for old friends; build a local network wherever you are. Friendships are dynamic, and people change.
• Others argue long‑term friendships offer unique depth later in life and are worth centering major decisions around.
• There’s debate on whether it’s realistic or wise to “pick a friend group and stick with it” versus continually “planting seeds” for new friendships.

Urban vs Suburban vs Rural

• Big cities: praised for density, randomness, niche intellectual communities, but criticized for transience, homogeneity by class/profession, cost, and long commutes that undermine seeing friends.
• Suburbs: often blamed for isolation and car‑dependence, yet some report highly social, kid‑friendly suburban neighborhoods with parks and transit.
• Rural/small towns: some say they foster deeper, more diverse relationships because you must interact with whoever is around; others highlight limited opportunities or cultural mismatch.

Housing, Jobs, and Practical Constraints

• Cost is a recurring blocker: many can’t afford to live where their friends are (Bay Area, Santa Cruz, etc.), see co‑buying as unrealistic, or must move for jobs.
• US zoning, anti‑density politics, and weak renter protections are blamed for limiting flexible, stable housing near community.
• Remote work is seen by some as the key enabler; others note it only applies to a minority of jobs and risks creating privileged “remote elites.”

Family vs Friends, Culture, and Life Stage

• Some prioritize living near extended family over friends; others from toxic or mismatched families lean on “found family.”
• Several contrast US individualism and mobility with Latin American or other cultures where staying near family and hometown is more normal and less stigmatized.
• Many note that in midlife, kids, work, and aging parents limit how often even nearby friends can see each other, so expectations must be realistic.

Attribution and Motive Debates

• Many commenters see intentional sabotage as likely, not an accident, citing:
  • Prior confirmed cases of undersea cable damage tied to specific ships and anchor movements.
  • The owning company reportedly saying this did not look accidental.
• Russia is frequently mentioned as the most likely culprit in context of the Ukraine war and Baltic tensions.
• A specific suspect ship is flagged (Cook Islands, owner in UAE), escorted by Finnish authorities; it was allegedly dragging anchor and later found missing one.
• Some point to nearby Chinese-flagged vessels; one note says its track crossed earlier than the damage time.
• A minority blames Western actors (e.g., CIA) or points to Nord Stream as precedent that “undersea infrastructure is now fair game.”

Technical and Operational Details

• This is a high‑power HVDC cable (~650 MW at 450 kV, ~1450 A), implying thick conductors and insulation.
• Commenters debate whether an anchor could physically cut such a cable without heavily damaging the ship or noticeably slowing it.
• Some discuss the difference between power and fiber cables; earlier incidents mostly involved communications fibers.
• Speculation appears about possible covert devices inserted during “repairs,” but this thread’s incident is clearly a power cable, not fiber.

Wider Geopolitical Context

• Extensive argument about Russia as a “terrorist/fascist” state vs. critiques of Western policy, propaganda, and past wars.
• Some emphasize Russian aggression (Georgia, Crimea, full‑scale Ukraine invasion) and Eastern European warnings that were ignored.
• Others highlight Western interventions and sanctions, comparing sabotage to economic warfare and questioning double standards.
• Debate over whether the West is “starving” Russia effectively; some say current sanctions are weak.

NATO/EU Response and Strategy

• Suggestions include: larger Baltic naval presence, tighter monitoring, possible Baltic blockade, and using Kattegat as a controllable choke point.
• Boarding and holding the suspect ship is cited as a concrete response and potential model for future incidents.
• Strong disagreement over “conflict management” vs. “appeasement”:
  • One side warns that restrained responses invite escalation.
  • The other argues that avoiding direct NATO–Russia war (and nuclear risk) is paramount.

Regional Energy and Infrastructure Context

• Noted that Baltic states plan to decouple their power grid from Russia soon, giving this incident extra significance.
• Discussion of dense undersea cable/pipeline networks in the Baltic and the difficulty of protecting them despite existing radar and underwater surveillance.
• Linked mention of NATO work on orbital backup for critical communications if undersea cables are disrupted.

Overall reaction to the COBOL Minecraft server

• Many commenters find the project impressive, surprising, and “awesome,” especially given it was written by someone new to COBOL.
• Several note the code is quite readable and organized, especially compared to some modern-language projects.
• Some see it as a fun, whimsical demonstration rather than a production-ready server.

COBOL as a language: stigma, readability, and features

• Commenters discuss COBOL’s reputation: old, verbose, “punched card” heritage, but also very readable and business-oriented.
• A few argue COBOL is effectively a high-level assembler, good at low-level byte manipulation, contradicting the repo’s framing that it isn’t suited for that.
• The object-oriented features from COBOL 2002 onward are mentioned; standards exist but are only partially implemented by vendors due to weak demand and lack of modern test suites.
• Comparisons are drawn to FORTRAN, PL/I, Ada, VHDL, SQL, and Algol-family languages, often around readability and English-like syntax.

Platforms, mainframes, and Docker

• There is curiosity about whether the server could run on z/OS, with mentions of testing via Hercules or asking a mainframe sysprog.
• Running it on zLinux is considered technically easier but less interesting.
• A side thread debates Docker’s portability, with complaints about missing support on platforms like FreeBSD, Solaris, and Android, and workarounds like Podman.

Functionality and technical scope of the server

• Readers look for redstone support and conclude it’s effectively unsupported; blocks with complex state or behavior are explicitly out of scope.
• Lighting and full block behavior are recognized as major omitted features; implementing a complete Minecraft server is viewed as a multi‑year effort.
• The presence of unit tests is appreciated.

COBOL jobs and legacy systems

• The thread challenges the idea that COBOL programmers alone command high salaries.
• Commenters argue the real scarcity is knowledge of legacy business logic and mainframe ecosystems; COBOL skills mainly provide an entry point to those domains.

Language design, simplicity, and project success

• Some observe that many polished side projects are written in simple languages (C, COBOL), whereas modern languages (especially Rust) often appear in large but incomplete projects.
• Theories offered:
  • Simple languages reduce cognitive load and “choice overload,” making it easier to ship messy but working prototypes.
  • Modern languages and frameworks encourage heavy abstractions, code generation, and “code that will last,” which can impede finishing hobby projects.
  • Hype attracts beginners to Rust and similar languages, leading to many ambitious but abandoned efforts.
• Extended debate centers on Rust vs C++/C#/others in game development:
  • One side argues Rust’s focus on memory safety and strictness slows iteration and clashes with the rapid experimentation needed for games.
  • Others counter that C++’s ecosystem is also painful, and Rust’s smaller community and immature game tooling are bigger issues than the language itself.

Nostalgia and personal COBOL experiences

• Several share memories of learning or working in COBOL decades ago, often in batch financial systems, emphasizing how readability helped with maintenance and production support.
• Some express humorous reluctance to revisit COBOL, while still acknowledging the achievement of this project.

Minecraft hosting and cross‑play tangent

• A sizable subthread discusses how to host Minecraft servers for kids across PC, Switch, Xbox, and mobile.
• Key points:
  • Java and Bedrock editions are distinct and normally can’t cross‑play.
  • Official Bedrock server binaries exist for Windows and Linux.
  • Tools like Geyser/Floodgate can bridge Java and Bedrock with some feature limitations.
  • Switch/console clients are more locked down, often requiring Realms or workarounds; paid console online services are typically needed.
• Alternatives like Minetest/Luanti are briefly mentioned as open‑source, Minecraft‑like options.

Overall themes

• Thread centers less on Blackcandy itself and more on the broader landscape of self‑hosted music servers, how people assemble full stacks (server + clients + metadata tools), and why they self‑host instead of using commercial streaming services.

---

Why self-host music?

• Desire to own collections rather than “rent” via Spotify/Apple Music.
• Avoid disappearing tracks, regional restrictions, algorithmic recommendation bias, and corporate behavior seen as unethical.
• Need support for rare material (demos, bootlegs, out‑of‑print albums) and exact releases/masters.
• Many enjoy curating a library, doing metadata work, and treating music as a hobby.
• Some still subscribe to streaming but use self‑hosting for gaps and long‑term control.

---

Blackcandy vs existing servers

• People compare Blackcandy mostly to Navidrome, Jellyfin, Subsonic/Airsonic, Gonic, Funkwhale, Lyrion (Logitech Media Server), and Plex.
• Interest in Blackcandy’s polished UI and custom mobile player; questions about offline downloads and CarPlay remain unclear.
• Lack of mention of OpenSubsonic/Subsonic API support is a concern for those who rely on that ecosystem of clients.
• Some dislike its tech stack (Ruby + Node + Docker) and prefer simpler/bare‑metal solutions.

---

Stacks, clients, and protocols

• Common stacks:
  • Navidrome + Subsonic/OpenSubsonic clients (play:Sub, Symfonium, Substreamer, Amperfy, Supersonic).
  • Jellyfin + Finamp or Symfonium, sometimes plus Audiobookshelf and video via Jellyfin/Plex.
  • Gonic for directory‑based browsing and gapless playback cases.
  • Lyrion/Logitech Media Server and Squeezelite‑style players for multi‑room.
  • Icecast/mpd/Snapcast/OwnTone for radio‑like or multi‑room setups.
• Protocols/“standards” discussed: OpenSubsonic/Subsonic, UPnP/DLNA, DAAP, AirPlay, Chromecast.
• Many report that the weakest link tends to be clients (CarPlay, Alexa/Sonos, watch apps, gapless playback, codec support).

---

Metadata, organization, and discovery

• Most servers rely heavily on file tags; users emphasize tagging with MusicBrainz tools or beets.
• Debate over folder‑based browsing vs purely tag‑based UIs; some choose Gonic/Jellyfin specifically for directory browsing.
• Several want better discovery on self‑hosted setups; ideas include using Discogs/MusicBrainz datasets, last.fm/ListenBrainz, or even local LLMs to build playlists.

---

Infrastructure and alternatives

• Typical deployments: low‑power NAS or mini‑PCs (TrueNAS, Debian, Synology, TerraMaster), Raspberry Pis, plus Docker/Proxmox.
• Access via Tailscale, WireGuard, Cloudflare Tunnel, or traditional reverse proxies (nginx, Traefik, Caddy) with per‑service subdomains.
• Some argue streaming servers are overkill: they just sync the whole library to phone via Syncthing or SD cards, or use simple web playlists or network shares + VPN.

Comparisons to Obsidian, Notion, and others

• Many see SiYuan as very similar to Obsidian; some call it an Obsidian/Notion/RemNote hybrid.
• Key perceived advantages over Obsidian: open source (AGPL), fully WYSIWYG editor, first‑class web interface, self‑hostable sync, built‑in databases and spaced repetition.
• Obsidian is praised for:
  • “File over app” philosophy with plain Markdown vaults.
  • Strong plugin ecosystem (Dataview, spaced repetition, Excalidraw, etc.), graph view, search/navigation.
  • Flexible sync via Git, Syncthing, cloud storage; paid but optional official sync.
• Several argue Obsidian still feels more powerful/flexible, especially via plugins, and better as a no‑code platform.

Data Format, Openness, and Lock‑in

• SiYuan stores notes in its own JSON format (often encrypted).
• Concerns:
  • Not plain Markdown; feels like vendor/project lock‑in vs Obsidian’s directory of Markdown files.
• Counterpoints:
  • It’s open source; internal parsers exist and full Markdown export is supported.
  • Existing installs or Docker images can keep reading data even if development stops.

Licensing and Business Model

• Entire codebase, including license checks for “Pro” features (e.g., some exports, self‑hosted sync), is AGPL.
• Commenters note this makes patching out license checks legally possible, though seen by some as unethical.
• Project maintainers confirm the intention is to sell convenience (prebuilt binaries, cloud services), not restrict freedoms.
• Similar models are discussed (e.g., paid builds or plugins on top of GPL/LGPL projects); some doubt long‑term sustainability, others like the “pay once, lifetime” approach.

Self‑hosting, Sync, and Collaboration

• Multiple users report stable self‑hosting via Docker and syncing across devices (including via self‑hosted S3).
• One tradeoff vs some desktop apps: depending on setup, offline access can be weaker.
• Multi‑user real‑time collaboration is not yet available; it appears only on the public roadmap.

UX, Features, and Scope

• Praised as “expressive” and feature‑rich: databases/tables, flashcards, AI, advanced layout, many export formats (including Org‑mode).
• Some find it overwhelming/noisy compared to more focused tools.
• Others explicitly wanted a browser‑accessible, self‑hosted Notion‑like tool and say SiYuan fits that niche well.

Trust, Origin, and Transparency

• Some express discomfort with a China‑based project or with limited information about the company.
• Others counter that:
  • Maintainers and corporate details are easily discoverable in Chinese‑language sources (though some corporate info sites are geoblocked outside China).
  • Open source code is a stronger basis for trust than geography.

Broader Note‑Taking Philosophies and Alternatives

• Several participants use the thread to argue for “files over apps”:
  • Plain text/Markdown or Org‑mode in directories, managed with Unix tools (git, grep, fzf, etc.).
  • Backlinks can be implemented via small helper scripts.
• Others highlight alternative tools (Obsidian, Logseq, Trilium/TriliumNext, org‑roam, Zim, Flatnotes) and emphasize that personal workflow and comfort often matter more than any single app’s feature list.

Use cases and strengths

• Used for a wide range of tools: data viewers, scientific sims, CAD-like tools, photo/glitch art editors, plasmid editors, embedded-device configuration UIs, and game overlays.
• Integrates with game engines (e.g., via Bevy bindings) and is seen as especially suitable for in-game/2D overlays on 3D rendering.
• Popular for “scrappy prototypes” and small cross‑platform utilities, including browser builds via WebAssembly.
• Many commenters report using it daily and consider it their default choice for quick, functional desktop GUIs.

Immediate‑mode model, layout, and redraw behavior

• Core model: UI code runs each frame; widgets are rebuilt from state instead of being retained.
• Debate over whether it “redraws everything all the time”: some say that in native setups you can tie redraws to events; others point to cases where network or other external events require manually triggering redraws.
• Single‑pass layout works well for straightforward top‑to‑bottom, left‑to‑right layouts; more complex dependent layouts can cause mispositioning or jitter across frames.
• Two‑phase layout is approximated by discarding a frame and recomputing, which can work but leads to edge cases like briefly displaying out‑of‑bounds values.
• Several reports of window resizing quirks and difficulty expressing proportional layouts (e.g., 60/25/15% width splits).

Performance and platform behavior

• Some find demos extremely snappy on mobile; others see high CPU usage even when idle, slow text input on phones, and various mobile browser errors (missing WASM, runtime panics, blank page on iOS Safari).
• Concerns about power usage if redrawing at high FPS for non‑game apps; others argue you can and should gate redraws.

Text, internationalization, and accessibility

• Current internationalization is limited: Arabic text becomes tofu; text shaping work is in progress via Rust bindings to HarfBuzz‑style libraries.
• Font rendering can look blurry on low‑DPI displays; canvas/WebGL UIs lack subpixel rendering that DOM text enjoys.
• Inability to select/copy text on mobile (and in many canvas/native UIs generally) is a major complaint, especially versus HTML’s text‑first model.
• This also raises accessibility and automation concerns; workarounds rely on OS‑level OCR features.

Developer experience and tooling

• Rust compile/link times can make rapid UI iteration feel slow; suggestions include faster linkers and hot‑reloading, though the latter is described as immature.
• Version lockstep between egui, winit, wgpu, etc., causes friction when APIs break.
• Requests for higher‑level tooling: dialog/WYSIWYG builders, global font‑size and high‑contrast options, and easier “serious”/pixel‑perfect design support.
• Some view egui as excellent for functional UIs and prototypes but not ideal for complex, highly polished visual design.

What POSIX / Unix Time Actually Represents

• Many assumed “Unix time = seconds since 1970-01-01 00:00:00 UTC.”
• Commenters clarify POSIX more precisely as:
  • 86400 * (number of UTC midnights since epoch) + (seconds since last UTC midnight),
  • which ignores leap seconds by treating every UTC day as 86400 seconds.
• Result: Unix time is effectively “seconds since epoch, minus leap seconds” and is off by ~27–29 seconds compared with true elapsed SI seconds, depending on how you count.

Leap Seconds: Behavior and Confusion

• On positive leap seconds, many systems repeat a timestamp: e.g. ...799 → 800 → 800 → 801.
• This means:
  • Some real instants have no POSIX timestamp (during smeared or skipped behavior).
  • Some timestamps correspond to two distinct real instants.
• There is confusion in the thread about whether leap seconds are “real seconds,” whether they’re inserted or smeared, and how many there have been since 1970.
• Negative leap seconds (removing a second) are theoretically possible and largely unhandled.

Monotonicity, Synchronization, and Precision

• Unix time is not strictly increasing in UTC terms (due to repeated seconds); some argue this breaks the idea of a monotonic counter.
• High-precision synchronization examples are discussed:
  • GNSS/GPS, GPSDOs, PTP, and WhiteRabbit (sub-nanosecond sync) vs. typical NTP (millisecond-level).
• Others note real-world constraints: clock drift, network latency, spoofing/jamming, and the difficulty of relying on wall-clock time for distributed ordering.

Storing and Representing Time

• Common practice: store timestamps as Unix epoch seconds (often UTC) and keep timezone separately.
• Some argue systems should instead store TAI-like monotonic time and convert to UTC/time zones only at the edges.
• Others warn that deviating from widely used Unix/UTC conventions is costly and most apps don’t care about ±1 second over decades.
• Databases differ: many “timestamp with time zone” types actually store instants in UTC and discard original zone; true zone round-tripping is rare and debated.

Human vs Machine Time & Future Changes

• Thread distinguishes:
  • Machine time: monotonic counters for intervals and ordering.
  • Human time: calendars, time zones, DST, solar alignment.
• Future calendar arithmetic is inherently uncertain (DST and legal changes). Storing user intent (local date+time+zone) is often recommended.
• There is an ongoing plan to abolish new leap seconds by ~2035; some see this as pragmatic, others dislike drifting away from mean solar time and argue we should then just adopt TAI explicitly.

Use cases and libraries

• Used for streaming hypermedia UIs, chatbots/LLMs, log tailing, hot reloading, and CLI “auto-restart on config change”.
• Several dedicated systems built around SSE: frontend frameworks, pub/sub hubs, and realtime servers that support multiple transports (SSE, HTTP streaming, WebSockets, gRPC).
• SSE often chosen when only server→client updates are needed, especially in stacks where WebSockets are heavier to integrate.

Perceived advantages

• Very simple to set up on the server; often “a few lines” in common web frameworks.
• Browser EventSource API provides automatic reconnection and ID-based resumption.
• Plays well with HTTP/2 and HTTP/3, giving efficient multiplexing and avoiding connection limits.
• Often works better than WebSockets through corporate proxies/firewalls and some network middleboxes.
• More bandwidth- and battery-efficient than polling, since it avoids repeated HTTP headers and connections.

Major limitations and ecosystem issues

• On HTTP/1.1, browsers cap open SSE connections per origin (~6), causing failures with many tabs; no clean client-side way to detect hitting the limit.
• Some corporate networks downgrade or MITM TLS and only support HTTP/1.1, breaking the “just use HTTP/2” fix.
• Some load balancers, proxies, tunnels, and FaaS platforms buffer or time out long-lived HTTP responses, making SSE unreliable unless tuned (pings, timeouts, flush behavior).
• No binary framing; everything is text. Newline-based framing and the data: prefix can conflict with raw text payloads, requiring encoding and robust parsers.
• Native browser EventSource lacks Authorization header support, pushing people to polyfills or custom streaming clients.
• Mobile/background behavior and battery cost of frequent pings are problematic and not fully resolved.

Patterns and workarounds

• Use a single SSE connection per origin and multiplex logical channels over it.
• Coordinate multiple tabs via BroadcastChannel or Web Locks; possibly centralize the SSE connection in a worker.
• Some prefer generic HTTP streaming with ReadableStream and custom length-prefixed or ndjson framing over SSE’s fixed format.

SSE vs WebSockets

• Supporters argue SSE is simpler, more compatible with existing HTTP infra, and good enough for unidirectional updates.
• Skeptics argue WebSockets are ubiquitous, easy to constrain to one direction, and that SSE’s edge cases (infra quirks, framing, limits) reduce its appeal.

Evidence of External Explosion and Shrapnel

• Multiple linked cabin videos reportedly show small holes and punctures in seats, clothing, passengers, and life vests consistent with shrapnel before the crash.
• Photos and videos of the tail section show numerous perforations; commenters say metal is bent inward, implying an explosion outside the fuselage.
• Several participants assert that shrapnel damage is “pretty much established” from visual evidence and survivor accounts of a loud external bang.

Competing Theories on Cause

• One line of argument: a surface-to-air missile (SAM) with a blast-fragmentation or continuous-rod warhead, likened to systems such as Buk, S‑300, S‑400, or Pantsir, based on damage patterns similar to MH17 and other known SAM strikes.
• Counterpoint: some initially suggest an uncontained engine (turbine blade) failure could create bomb-like shrapnel, but others note certification standards and the location of damage (tail) make this unlikely.
• Russian-linked media narratives about an internal oxygen tank explosion are mentioned and widely viewed as disinformation or at least inconsistent with visible external blast signatures.
• Consensus in the thread: external weapon strike is more plausible, but exact weapon type remains unclear.

Flight Path, Diversions, and ATC Behavior

• Plane was diverted from Grozny due to fog, later suffering an explosion near Grozny during multiple landing attempts.
• Reports in the thread claim the aircraft was denied emergency landings at Grozny, Makhachkala, and Mineralnye Vody, then diverted toward Aktau (Kazakhstan), potentially while being steered largely by thrust due to hydraulic loss.
• Dual GPS failure and regional GPS jamming are mentioned; some suggest this, plus control damage and desire to avoid mountains or further attacks, may explain the route over the Caspian. Exact decision logic is unclear.

Responsibility, Drones, and Air Defense Context

• Many commenters think Russian air defenses likely mistook the Embraer 190 for a Ukrainian drone or small manned aircraft converted to a kamikaze drone, amid active drone attacks on Grozny and other targets.
• Others note that Kazakhstan also has air defenses, but given the reported hit over Russia and diversion sequence, the working assumption in the thread is a Russian SAM engagement; this is acknowledged as still unproven.
• Discussion covers transponders, ADS‑B, and military IFF, with some arguing an airliner should have been clearly identifiable, while others point to jamming, operator competence, and radar limitations.

Survivability and Crew Performance

• Commenters are struck by the violence of the crash and the number of survivors, crediting both modern airframe design and apparent skill of the flight crew using differential thrust with degraded controls.
• The event is compared to past partial-control disasters (e.g., UA232) where pilots were seen as heroic.

Broader Political and Moral Debate

• Thread references a history of civilian airliner shootdowns worldwide (including by Russia/USSR and the US) and debates whether such events are “accidents” versus negligent or reckless acts.
• Some argue Russia is repeatedly irresponsible and deceptive regarding civilian casualties; others broaden criticism to other states’ military errors.
• There is disagreement over how the international community “should” respond; options discussed range from doing little beyond rhetoric to substantially increasing military aid to Ukraine, with strong views but no consensus.

How Portspoof Works

• Listens on a single TCP port and uses iptables NAT redirection so all unbound ports (1–65535) are forwarded to it.
• Uses getsockopt to recover the originally requested destination port and returns protocol-appropriate fake banners/responses.
• Intention: make every port appear to run a plausible service, slowing or confusing service/version detection.

---

Comparison to Tarpits and Honeypots

• Tarpit: keeps connections half-open or very slow, tying up attackers’ resources but risking local conntrack exhaustion if misconfigured.
• Portspoof: responds quickly and closes connections, using fewer resources than a tarpit but more than simply ignoring traffic.
• Several commenters frame it as honeypot infrastructure: fake services, logging, and possible integration with exploit frameworks to attack scanners.
• Others warn that too many open ports can itself signal “honeypot” to more sophisticated attackers.

---

Security Value and Threat Models

• Supporters: raises attacker cost and time, especially for broad “spray-and-pray” scans; good as an extra “security-through-obscurity” layer.
• Critics: if a real vulnerable service is exposed, Portspoof does not prevent exploitation; many attackers only scan specific known ports.
• Debate on “security through obscurity”: some say it’s acceptable as one layer (like port knocking, ASLR, or delay after bad passwords); others think it mainly attracts more traffic and scrutiny.
• Concern that it may generate bandwidth overhead (e.g., 200MB for full nmap -sV scan) and increase bug-bounty noise and false positives.

---

Implementation, Risks, and Variants

• Uses iptables REDIRECT for all TCP ports to a single listening port; seen as a neat, simple design.
• Risk: Portspoof itself becomes a large attack surface if it parses complex inputs; suggested to run it sandboxed, in DMZ/VM, or as part of honeypot research.
• Some suggest combining with port knocking or only emulating a subset of ports/IPs to appear more realistic.
• Ideas to integrate with SIEM for alerts when non-existent services are probed.

---

Licensing and Ecosystem Discussion

• Project is GPLv2 but also asks commercial users to “contact the author,” leading to discussion of dual licensing and GPL commercialization.
• Commenters note GPL already permits commercial use; author likely aims to sell proprietary licenses/exceptions.
• Related mentions: older honeypot products, tarpits like Endlessh, and analogous “noise” ideas (e.g., infinite fake email lists, HTTP endpoints that always return 200).

Debate over Discovery’s Canon Status

• Many commenters call the article “clickbait” and say Discovery has not been erased from canon: it’s still streamable, has Blu-rays and merchandise, and is treated as part of the franchise.
• Others want it gone and speak as if it has been “flushed” or “deleted,” but this is presented more as wishful thinking or headcanon.
• Wikipedia and general practice are cited: all live‑action Trek plus Lower Decks/Prodigy are considered canon unless explicitly contradicted.

Canon, Continuity, and Corporate Control

• Several argue “canon” in fiction is overblown, a holdover from religious concepts and now mainly a tool of copyright holders to define which stories are “valid.”
• Counterpoint: canon is a practical tool for internal consistency, worldbuilding, and shared storytelling across decades and teams.
• Some stress that canon decisions come from corporations, not original creators, using Star Wars’ “Legends” reclassification as an example.

Lower Decks, Multiverse, and Logic

• Lower Decks shows Discovery-style Klingons in an alternate universe.
• One side claims this supports a “Discovery is alternate timeline” theory; others argue it only proves those Klingons exist somewhere, not that Discovery is excluded from the prime universe.
• Some highlight that Strange New Worlds spins out of Discovery and has a crossover with Lower Decks, complicating any clean “non-canon” or “other universe” claim.
• Overall consensus: LD episode is playful fan service, not decisive canon surgery; whether timelines differ remains unclear.

Quality of Discovery and Other Trek

• Discovery is widely criticized as poorly written, with unlikable characters and “cringe” moments, though a few seasons or arcs (e.g., S3, Jason Isaacs’ captain, some secondary characters) get praise.
• Some argue that because Discovery made money and had fans, no rational executive would erase it purely for canon purity.
• Other series: Lower Decks and Strange New Worlds are often praised as understanding “true Trek”; Picard is mixed (S3 liked, S2 widely panned); Voyager and Enterprise receive retrospective reevaluations, often improved by comparison to newer shows.

Fandom, Attachment, and “Woke” Debates

• Several comments critique how deeply fans tie identity to franchises and canon, seeing them as “captured” by corporate IP.
• Others defend caring about continuity as caring about good storytelling.
• “Woke” discourse around Trek is mocked as inconsistent and subjective.

Perceived Uses and Misuses

• Suggested “non‑creepy” uses: OSINT / cybercrime research, awareness training about how linkable traces are, self‑auditing your own footprint, cleaning up accounts before running for office, finding a consistent username to register, importing content across sites.
• Several commenters argue there is effectively no non‑creepy use; the tool is inherently suited for stalking, harassment, brigading across platforms, and cancel campaigns.
• Some see it as an educational shock: a concrete demo that online anonymity is fragile.

Privacy, Anonymity, and Online Footprints

• Many note how easy it is to correlate identities by username, email, phone, profile photo, time zones, and especially writing style (stylometry).
• Some now assume all activity will be deanonymized and self‑censor accordingly, fearing future lawsuits or professional repercussions for old posts.
• Others advocate embracing a public identity and simply not posting anything you’d regret, or using multiple personas/accounts depending on context.

Usernames, Identity, and Impersonation

• Split advice:
  • Use unique usernames everywhere to make tracking harder.
  • Use the same username everywhere to build a clear, controlled public identity.
  • Claim your “main” handle widely to prevent impersonation, then use separate ones for sensitive topics.
• Concerns that usernames alone are weak evidence; attackers can pre‑emptively register your handle on new platforms and damage your reputation.
• LLMs and bots can now impersonate style, further muddying authenticity.

Technical Characteristics and Limitations of Sherlock

• Tool essentially loops over ~400 sites, fetches profile URLs, and regex‑matches “user not found.”
• It runs client‑side, querying sites directly rather than a central database.
• Users report false positives (including for nonsense usernames) and links leading to 404s; some find it less useful than Google.
• Critiques: overengineered for what is conceptually a simple script; CLI‑only and not very user‑friendly; UI on the website is confusing.

Legal and Ethical Context

• Some jurisdictions reportedly restrict employers from searching candidates without consent, but commenters argue such rules are often unenforceable and widely ignored.
• Debate over whether digging up old posts (10+ years) should be disqualifying, with tension between accountability and recognizing people can change.

Solar desalination and energy costs

• Several comments argue that very cheap solar power will make desalination an affordable large‑scale solution for crops and drinking water, with low sensitivity to power intermittency if paired with reservoirs and/or batteries.
• Others highlight practical constraints: distance between coasts and inland reservoirs, need for new storage, labor and permitting costs, and slow real‑world scaling of large infrastructure projects.
• There is skepticism that mega‑projects will be built without strong state direction, given regulatory and environmental hurdles.

Climate impacts on water, land, and ecosystems

• Drought is framed as more than “less rain”: aquifer drawdown causes irreversible land subsidence and loss of storage capacity; pollutants migrate slowly into groundwater.
• Melting ice affects salinity and large‑scale circulation, with knock‑on effects on climate and water distribution.
• Some stress that urban encroachment on farmland exists but is small compared to climate‑driven land degradation.

Public will, agency, and narratives

• One thread debates whether “people don’t care” about climate:
  • One side sees apathy, short‑termism, and low polling priority, arguing change will come only after severe impacts.
  • Another side calls this a harmful narrative of powerlessness, insisting that belief, hope, and collective action are crucial.

Growth, geoengineering, and lifestyle change

• “Powerdown, permaculture, population control” is proposed as necessary; others argue this window has largely passed and massive geo/bioengineering is inevitable.
• Some say conservation and lower living standards are politically impossible; they favor innovation and geoengineering over deprivation.
• Counterarguments stress that relying on future tech is quasi‑religious and ignores finite physical limits.

Food systems, meat, and agricultural risk

• Multiple comments emphasize livestock’s heavy land use and suggest reduced meat consumption (especially beef) as a high‑impact personal and systemic lever.
• There is a sharp dispute over climate‑driven food risk:
  • Some foresee dramatic yield declines, uninhabitable equatorial regions at ~4°C warming, billions of climate refugees, and heightened war and famine risk.
  • Others argue human adaptability, yield improvements, dietary shifts, and slowing emissions will prevent mass starvation on that scale.

Population, urban form, and energy use

• Population growth is noted as already slowing in many regions; humane “control” is associated with education, income growth, and access to contraception/abortion.
• “Powerdown” is interpreted as using less energy per person via dense, walkable cities and efficient housing, rather than simply having fewer people.

Economics, money, and adaptation

• One side insists “you can’t eat money,” criticizing profit‑driven destruction.
• Another responds that higher productivity and economic resources have sharply reduced deaths from extreme weather and increase resilience.
• Critics reply that economic metrics ignore depletion and damage to underlying material and ecological systems.

Rainfall, aridity, and greening

• A sub‑thread notes that total land precipitation is rising, but higher temperatures drive more evaporation and more intense, less frequent storms, leading many regions to net drying.
• One commenter points out documented global “greening” from CO₂ fertilization, arguing this side of the picture is often omitted; others imply this doesn’t negate growing drought and heat stress.

Product marketing, sales & entrepreneurship

• Many want to improve marketing/sales to get actual paying customers for SaaS, indie apps, or physical products.
• Common realization: “build it and they will come” fails; traffic and repetition matter more than clever one-offs.
• Suggestions include: structuring landing pages better, mastering Google/Facebook ads and analytics, pricing psychology, strong brand/logos, and clear free-vs-paid value.
• Some warn entrepreneurship can be an even harder “rat race,” and urge freelancing or keeping expectations realistic.

Technical skills & CS depth

• Popular targets: Rust, Nix, ML/AI (often via Andrew Ng or fast.ai), Git (esp. rebase), Kubernetes/CKA, Elixir/functional programming, Ada, AWK, CS fundamentals (“Nand2Tetris”, TeachYourselfCS), desktop apps, embedded/FPGA, container runtimes, CI/CD, DevOps, and self‑hosting.
• Several want to move beyond web/frontend into systems, databases, networking, or bare‑metal work.
• Some plan certifications (AWS, Kubernetes, RHCSA) to formalize knowledge.

Writing, blogging & communication

• Many aim to write more: essays, technical blogs, fiction, emails, documentation, or even poetry.
• Struggles include perfectionism, imposter syndrome, and context‑dependent writing ability.
• Advice: publish imperfect posts, write for oneself, state uncertainty clearly, and use search data (e.g., Search Console) to guide topics.

Math, formal study & learning tools

• Numerous people want to “do more math,” prep for physics/AI degrees, or rebuild rusty foundations.
• Math Academy is repeatedly praised for diagnostics, spaced repetition, and clear knowledge graphs; some share detailed progress and renewed confidence.
• Others recommend Anki, “Learning How to Learn,” statistics/probability texts, and structured ML/math courses.

Languages, arts & physical skills

• Language goals: German, Spanish, Japanese, Latin, Mandarin, English fluency. Methods include immersion, tutors, SRS (Anki), specialized courses, and content platforms.
• Creative/craft aims: game art, Blender, pottery, sewing/tailoring, film photography, music, piano, dance, magic, woodworking, drawing, animation, Rubik’s cubing, and clothing fabrication.
• Fitness goals: running (5K to marathon), strength training, swimming, yoga, climbing, better sleep, and general health.

Parenting, relationships & mental health

• New and experienced parents want to “learn how to parent,” read key baby/parenting books, and accept it as an ongoing journey.
• Others focus on social skills, deeper connection, relationship skills, and learning to forgive.
• Many want better habits, discipline, time management, and reduced phone/social media usage.
• ADHD is a major theme: dopamine‑driven habits, hobby‑jumping, and procrastination. Opinions split on habit books and ADHD coaching; some recommend occupational therapists instead.

Life philosophy & “non-goals”

• Several emphasize mental fortitude, stoicism/Buddhist practices, living in the present, separating work from life, and allowing themselves not to constantly upskill.
• A recurring subtheme: choosing fewer, more meaningful goals over endless technical stacking.

MicroStrategy’s Bitcoin Strategy & Leverage

• Seen as a heavily leveraged bet on Bitcoin: upside roughly parallels BTC, but downside amplified because of debt.
• Some argue loans are effectively at 0% and so risk is overstated; others stress that if BTC drops 50%+, debt service against underwater collateral can be catastrophic.
• The firm is now in major indexes (e.g., QQQ), forcing some equity-only funds to hold it.

NAV Premium, ETFs, and Investor Motives

• Many view MSTR as an equity wrapper for investors who can’t hold BTC or BTC ETFs directly (mandates, familiarity, “boomers” uncomfortable with wallets).
• Stock trades at a large premium to its underlying BTC; some see this as pricing in future “business” (ongoing inflows and structuring), not just NAV.
• Others call this simple greater‑fool dynamics: overpaying for BTC exposure when direct BTC or ETFs are cheaper.

Options, Volatility, and “Infinite Money Machine” Narrative

• Some holders like MSTR not for pure BTC exposure, but for its volatility and options market (covered calls, compounding shares).
• One commenter describes a positive feedback loop: rising stock → more capital → more BTC bought → BTC up → stock up, likening it to an “infinite money machine.”
• Skeptics see this as ponzi‑like: value depends on continuous new buyers of stock/bonds at higher prices.

Bitcoin: Useless Bubble vs Emerging Store of Value

• Harsh critics label BTC “useless,” mainly a vehicle for gambling, illicit transfers, and sanctions evasion, with large environmental and social costs.
• Supporters counter that the same dismissive tropes were used when BTC was <$500 and that major institutions now treat it as a store‑of‑value hedge against an over‑levered fiat system.
• Debate over whether markets are “irrational” or simply reflecting information that skeptics don’t see.

Bitcoin, Currency Design, and Fiat Money

• Several argue BTC functions more like a commodity (like gold) than a currency: deflationary, hoarded, volatile, hard to use for everyday payments.
• Others say this is exactly the point: a non‑state, scarce asset that sits outside politicized money printing and surveillance.
• Long sub‑thread on whether money creation (“printing”) is necessary for growth or a distortionary tool for central planners; both sides cite historical episodes (Great Depression, gold standard, QE) in support of their view.

Overview

• Thread is a big book-sharing list: mostly enthusiastic recommendations across fiction, non-fiction, technical books, and manga.
• Many comments emphasize books that changed perspectives, clarified difficult topics, or simply reignited the joy of reading.

Non‑fiction, Ideas, and Society

• Several readers highlight works on systemic violence, extractive institutions, and why nations succeed or fail, appreciating multi-factor explanations (institutions, history, culture).
• Environmental reports on wildlife decline and biomass distribution leave some feeling we’re in an ongoing ecological crisis that isn’t treated with appropriate urgency.
• Other praised topics: ethics under rapid technological change, the history of American research universities, global material and energy systems, happiness and psychology, and personal transformation memoirs (education, crime-to-profession arcs, mental health).
• Some mention books that eased existential dread about current politics and culture.

Technical, Physics, and ML

• The Feynman Lectures are lauded for making concepts click once calculus/linear algebra are understood; related math/physics books are recommended.
• A long subthread debates a critical video about the Feynman persona.
  • One side claims the video misrepresents authorship and unfairly portrays his stories as fabricated for attention.
  • The other side says the video acknowledges his role in the lectures, suggests only embellishment rather than total fabrication, and criticizes the mischaracterization of the video.
• Other valued resources: Next.js docs, interpreters and language design tutorials, systems programming texts, ML overviews, and applied ML system design. One commenter laments that fewer people seem to read technical books.

Fiction, Sci‑Fi, Manga, and “Light” Reads

• Strong enthusiasm for: post-apocalyptic trilogies, hard sci-fi epics, space operas, alternate histories, and intricate fantasy series with coherent magic systems and mental-health themes.
• Many appreciate “brain candy” series (action thrillers, procedurals) as relief from coding, though one reader is put off by a hero’s repetitive romantic patterns.
• Classics (e.g., long 19th‑century novels, Russian literature) are described as emotionally devastating, perspective-changing, and worth overcoming initial resistance; some readers only appreciated them later in life.
• Manga and graphic stories (post-apocalyptic, intricate magic systems, large-scale mysteries) receive praise for long-term plotting, moral complexity, and distinctive art, though one commenter finds a particular mystery series’ resolutions weaker than its setup.

Laptop-style vs traditional mechanical keyboards

• Many participants prefer low-travel laptop-style boards (especially Apple Magic Keyboard / MacBook keyboards) and find full-travel mechanical switches tiring or “antique typewriter–like.”
• Others recommend low-profile mechanical options (Keychron low-profile series, NuPhy Air75, Redragon Horus, etc.) as a compromise between laptop feel and mechanical benefits.
• Layout consistency matters a lot: changes to Enter, arrow clusters, Fn position, or Home/End/PgUp/PgDn placement are deal-breakers for some who navigate by touch.

Hall-effect / analog switches

• Several feel it was a big omission that Hall-effect/“analog” boards weren’t meaningfully covered.
• Main touted benefit: “rapid trigger” (actuation on direction change rather than fixed point), improving responsiveness for certain games.
• Multi-level actuation (half vs full press) is seen as promising in theory but hard to use consistently in practice.
• Some dream uses: MIDI/velocity-sensitive QWERTY, pressure-based capitalization, very short programmable travel.
• Keychron K2 HE and NuPhy Air75 HE are cited positively, but options combining hall-effect with split, low profile, wireless, and QMK/VIA are said not to exist yet.

Split / ergonomic and programmability

• Many argue the main value of high-end boards is ergonomics + programmability, not just switch feel.
• Split, tented, or column-staggered designs (Moonlander, ErgoDox, UHK, Kinesis, various Keeb.io boards, Svalboard, etc.) are praised for reducing strain, especially when paired with layers and “home-row modifiers.”
• Some find ortholinear/column-stagger layouts easy to adapt to; others struggle to switch back and forth with standard keyboards and retreat to more conventional split layouts.
• QMK/ZMK firmware, Via/Vial configuration, and per-OS remapping are highlighted as crucial features.

Accessibility, health, and input customization

• Users with tremor or RSI describe needing smaller or more concave key targets, lighter switches, higher activation points, or alternative layouts. Suggestions include spherical keycaps, custom caps, firmware filters that reject near-simultaneous neighboring keys, and magnetic switches with tunable actuation distance.
• Vertical mice and overall workstation setup are repeatedly framed as at least as important as the specific keyboard.

Hobby, nostalgia, and skepticism

• Some treat mechanical keyboards as a deep hobby (collecting dozens of boards, designing keycaps, chasing sound/feel).
• Others are satisfied with a single “endgame” board (e.g., Topre Realforce, Das Keyboard) or even cheap membranes, and view the scene as gear-centric consumerism.
• Vintage and classic-style boards (Model M/F, Unicomp, Apple Extended, ThinkPad-like designs) attract both strong praise and strong criticism.