DEV Community: BytePreview EN

Bluetooth LE Audio is not “any low-energy Bluetooth that plays sound”

BytePreview EN — Thu, 05 Nov 2026 06:49:57 +0000

Bluetooth LE Audio is a concrete stack: LE radio + isochronous transport + an interoperable codec (LC3), with its own profiles (BAP, and TMAP in telephony/multimedia cases). It is not a synonym for “any Bluetooth Low Energy link that happens to carry audio,” and it is not Classic Audio (A2DP / HFP) under a new badge.

Useful separations before reading a product sheet:

Three layers. The LE radio moves bits; isochronous channels (CIS for unicast, BIS for broadcast) keep streams timed; LC3 compresses. No single layer defines the listening experience.
LC3 is common, not magic. It is the codec the LE Audio standard expects. It does not automatically make every headset “better than Classic.”
“Bluetooth 5.x” is not enough. Transmitter and receiver both need matching hardware, profiles, and software. Without that, there is no usable LE Audio path.
Auracast is broadcast. One source announces a BIS; compatible sinks can tune in. It is not classic 1:1 pairing, and a compatible headset alone cannot invent a source in the room.

BytePreview unpacks isochronous channels, LC3, the Classic comparison, and what to verify before you buy:

https://www.bytepreview.com/en/articulos/what-is-bluetooth-le-audio-how-it-works-and-what-you-need-to-use-it?utm_source=dev&utm_medium=social&utm_campaign=bytepreview

CPU, GPU and NPU: which one actually runs your workload?

BytePreview EN — Sat, 31 Oct 2026 11:59:11 +0000

"Has an NPU" is showing up on more and more laptop spec sheets, but CPU, GPU and NPU aren't three rungs on one ladder of speed. They're different designs for different kinds of work:

CPU: the generalist. It runs the operating system and apps and handles varied, branchy work that doesn't split neatly into parallel pieces.
GPU: built for many operations at once. Graphics, but also any workload that can be divided across lots of units. Integrated or discrete, its real capability depends on the specific design and its power limits.
NPU: dedicated to operations that are common in certain AI models, aiming to run them efficiently.

The catch for developers: the hardware only helps if the software uses it. Drivers, the programming model and supported libraries decide which unit a task lands on, and one app may use more than one at the same time.

So before choosing a machine for local AI or GPU-heavy work, check what your actual tools support, not just what the chip lists.

The full guide on BytePreview goes through each processor and what to check before buying: CPU, GPU and NPU: what each processor does and when it matters

Router advisories from NETGEAR, InHand and ASUS: how to check if your device is affected

BytePreview EN — Thu, 29 Oct 2026 09:55:34 +0000

Router security notices tend to arrive in bursts, and the latest batch is a good example: NETGEAR and InHand have published advisories with affected models and fixes, and an ASUS advisory dated October 23, 2026 was reported separately for routers running 3.0.0.6_102-series firmware.

The practical takeaway is that none of these apply to "a brand" as a whole. Each advisory lists specific models and specific fixed firmware versions, so the only reliable check is:

Identify the exact router model (label on the device or the admin panel).
Read the installed firmware version from the admin interface.
Compare both against the manufacturer's own advisory entry for that model, not a version number listed for a different product.
If your version is at or below the affected one, update to the fixed release or the latest firmware the vendor points to.

The InHand notice, for instance, lists IR912 and IR915 units on V1.0.0.r20042 or earlier, while NETGEAR names different fixed builds per product. Mixing those up is how people end up thinking they're patched when they aren't.

BytePreview put together a walkthrough of what each advisory covers and how to verify your own device: Router vulnerabilities: ASUS, NETGEAR and InHand advisories

Auracast compatibility: what to actually check before you buy

BytePreview EN — Mon, 26 Oct 2026 04:33:58 +0000

Auracast is the broadcast feature of Bluetooth LE Audio: one source sends a stream and any number of compatible receivers can join it, instead of the source pairing with each listener one by one. Useful for sharing audio from a phone, or for venues like conference rooms or waiting areas.

The tricky part is knowing whether your gear supports it. A few points worth keeping in mind:

"Bluetooth 5.2" on a spec sheet doesn't mean Auracast. The feature has to be explicitly stated for that exact model.
Both ends need it, checked separately. Auracast-capable headphones don't turn your phone or TV into a transmitter, and an Auracast transmitter can't help headphones that can't join a broadcast.
Look for the right words. Search official specs and support pages for "Auracast" or "Broadcast Audio", and check whether the feature is already active or depends on a firmware update for your model.
Public use depends on the venue. A compatible receiver gives you nothing in an airport or theater unless the place has installed and enabled a transmitter.

The full guide covers which products confirm support, how it works for hearing-aid users, and a step-by-step pre-purchase checklist:

Auracast in 2026: how to check if your headphones are compatible (BytePreview)

GDPR data portability for developers: what an Article 20 export must cover (and what it doesn't)

BytePreview EN — Sat, 24 Oct 2026 00:34:27 +0000

If your product stores personal data of people in the EU, Article 20 of the GDPR will sooner or later show up in the backlog as an "export my data" feature. A few points worth getting right:

Scope: personal data the user provided, processed by automated means on the basis of consent or a contract. "Provided" can include observed data such as activity logs or usage history; data your system infers (scores, predictions) is out.
Format: structured, commonly used and machine-readable. JSON, CSV and XML are typical, but the regulation doesn't mandate one, and a static image of a profile page won't do.
No universal compatibility duty: Recital 68 encourages interoperable formats, but you aren't obliged to make your export importable everywhere.
Third parties: if an export contains other people's data (a shared conversation, for instance), their rights have to be protected too.
Timing: one month to respond, extendable by up to two more months for complex cases, as long as the user is told why.

BytePreview's explainer goes through scope, formats and limits in more detail:
https://www.bytepreview.com/en/articulos/data-portability-under-gdpr-scope-formats-and-limits?utm_source=dev&utm_medium=social&utm_campaign=bytepreview

"Local AI" isn't a spec: how to tell where an AI feature actually runs

BytePreview EN — Fri, 23 Oct 2026 05:22:10 +0000

"Local AI" gets used as if it were a product category. In practice it only answers one question: where does the main computation for a given feature happen, on your device or infrastructure you control, or on a provider's servers?

That framing helps avoid a few common mix-ups:

Local is not the same as offline. An app can run inference on-device and still sync, log or fetch data over the network.
One app, several paths. A single product can process one operation locally and send another to the cloud.
"On-device", "self-hosted" and "local" overlap but aren't synonyms. A phone and a company server can both count as local while having very different resources and admin models.
Privacy depends on the whole data flow, not just where the model weights live.

Hardware still sets the ceiling: model size, memory and connectivity decide what can realistically run on a given machine.

The BytePreview glossary entry goes through how local AI works, its real limits and how to check where a specific function is processed:
https://www.bytepreview.com/en/articulos/local-ai-what-it-is-how-it-works-and-its-real-limits?utm_source=dev&utm_medium=social&utm_campaign=bytepreview

"Has AES-256" is not an answer: three questions to ask before trusting SSD hardware encryption

BytePreview EN — Thu, 22 Oct 2026 09:21:40 +0000

A spec sheet that says "AES-256" tells you which cipher a drive can use. It doesn't tell you who holds the keys, whether locking is actually switched on, or whether your OS can drive it.

Before relying on self-encrypting SSDs in a fleet, split the claim into three checks:

Does the controller encrypt data at all? Look for documentation of the exact model, not the product family page.
What controls access? A TCG Opal reference suggests standard security management, but it is not a certification and doesn't prove encryption is active.
Can your stack activate it? Firmware, OS and tooling have to line up; BitLocker with hardware encryption, for example, depends on Opal plus eDrive (IEEE-1667) support.

Also worth remembering: software encryption (BitLocker, FileVault) versus drive-side encryption describes where the work happens, not which one is automatically safer or faster.

The full BytePreview guide walks through what to check in the specs and how to verify it on a real machine:
https://www.bytepreview.com/en/articulos/technical-guide-verifying-aes-256-hardware-encryption-in-ssds-for-2026?utm_source=dev&utm_medium=social&utm_campaign=bytepreview

Automating credential management: a staged rollout checklist for IT teams

BytePreview EN — Wed, 21 Oct 2026 11:30:05 +0000

Moving passwords out of spreadsheets and chat threads into an enterprise vault mostly buys you control and traceability. It doesn't make incidents go away, and a vault on its own won't fix excessive permissions or forgotten accounts.

A new BytePreview guide lays out a sensible order of operations:

Inventory first. Separate human logins, admin accounts, service accounts and shared access. A team password manager and privileged access management (PAM) rotation are different capabilities, so check each flow against your actual plan and environment.
Protect the vault itself. Make MFA mandatory where it matters, start with admins and accounts that reach critical systems, and define a recovery procedure before you need it.
Directory integration is not password sync. Connecting LDAP/LDAPS or Active Directory can be about discovering accounts and running rotation on compatible resources. Test discovery and read operations before anything that changes a password.
Rotation should follow risk, not a calendar. Service accounts are the tricky part: change one without updating the services that depend on it and you get an outage.
A new password doesn't kill existing sessions. If a credential may be exposed, review related sessions and activity too.

For every credential set, write down the owner, dependent systems, change mechanism, what triggers rotation and how success is confirmed. Then roll out in stages: access control and logs first, limited automated changes next, wider coverage only once logs and recovery tests prove it works.

Full guide on BytePreview: https://www.bytepreview.com/en/articulos/automating-password-and-session-management-a-technical-guide-for-it-teams?utm_source=dev&utm_medium=social&utm_campaign=bytepreview

Before you adopt an AI tool, check how you would leave it

BytePreview EN — Tue, 20 Oct 2026 10:34:25 +0000

Most AI features get evaluated on what they do on day one. The harder question is what you can take with you if you ever need to switch.

A recent BytePreview guide on data portability draws a useful line between three things: the data you put in, the outputs the tool generates, and whatever belongs to the provider or depends on its infrastructure. An "Export" button doesn't tell you which of those you get back, or whether the result is usable anywhere else.

Points worth turning into a checklist:

Read the exclusions, not just the promise. Microsoft's documentation, for example, lists exportable customer data (text, audio, image and video files, database content) but leaves out resource configuration details and protected proprietary data.
Retention depends on the data type. In Amazon Location Service, device positions are kept for 30 days and then deleted automatically, while geofence geometries you upload must be deleted explicitly.
An API is not an exit plan. Check which operations and data it really exposes. Being able to call a feature doesn't give you its underlying model.
Format, content and procedure are separate checks. Does the export keep the fields and relationships you need, and can you repeat it at volume?

The guide suggests a simple matrix (export, format, retention, deletion, interfaces), writing down open questions instead of filling gaps with assumptions, and saving the version and date of every document you review. Anything critical that isn't documented belongs in the contract.

Full guide on BytePreview: https://www.bytepreview.com/en/articulos/data-portability-in-ai-software-a-guide-to-assessing-lock-in-risk?utm_source=dev&utm_medium=social&utm_campaign=bytepreview

How to verify that a security update actually fixed what it claimed

BytePreview EN — Mon, 19 Oct 2026 15:58:37 +0000

Security updates are easy to install and hard to trust blindly. A changelog line that says "fixed CVE-…" does not prove the patch landed on your systems, or that the vulnerable code path is gone.

A practical checklist

Identify the claim — which CVE, package, or component is supposed to change.
Confirm the binary/package version after the update (not just that the updater ran).
Reproduce or probe the old failure mode in a safe environment when possible (version banner, feature flag, test that previously failed).
Watch for regressions in the same release notes — security fixes sometimes tighten defaults.

We wrote a fuller walkthrough with concrete verification steps here:

https://www.bytepreview.com/en/articulos/security-updates-what-they-fix-and-how-to-verify-them?utm_source=devto&utm_medium=social&utm_campaign=bytepreview