Hacker News Reader

Comment by variaga | Hacker News Reader

I worked on the design of wireless USB chips around 2008 - 2010. They worked - you really could get USB 2.0 full rate connections wirelessly and we had some neat demos.

I would say the major problem it had with adoption was that wired USB also provided power. (A lot more people use usb to charge their phone than to sync their phone.)

So great - wireless connectivity... but you still have to plug the device into a cable at some point (or have replaceable batteries), which makes the value proposition a lot less clear.

Beyond that it suffered from the usual adoption chicken-and-egg problem. Laptop manufacturers didn't want to add it because it was an expense that didn't drive sales since there weren't any must-have peripherals that used it, and peripheral manufacturers didn't want to make wireless usb devices since they couldn't be used with a standard laptop (at least not without a WUSB dongle - which raised the cost).

Still, very fun stuff to work on.

View on HN

I don't see why Bluetooth took off and wusb didn't. It must have something to do with marketing.

yes-and-no.

In my opinion, this was the timing and usefulness of Bluetooth in an era when only Nokia ruled the world. Moreover, there are many other reasons too.

Largest phone manufacturers of the time (Ericsson and Nokia) supporting and developing it surely helped.

Bluetooth took off before wireless usb did and was allready useful to people when wusb came a long. It was also lower power so you could do peripherals that was smaller and longer lived.

Bluetooth had some early success in cellphones, mostly to support Bluetooth headsets and car radio integration, starting from about 1999. It could do other things, but the wireless headset was the killer app in its early days.

Bluetooth didn’t really hit mainstream until the arrival of chipsets that multiplexed Bluetooth and WiFi on the same radio+antenna. My memory is that happened sometime around 2007-2010.

At that point, the BOM cost to add Bluetooth to a laptop or smart device became essentially zero, why not include it? Modern smartphones with both Bluetooth and Wifi arrived at around the same time (I suspect these combo chipsets were originally developed for handheld devices, and laptops benefited)

And once Bluetooth was mainstream, we saw a steady rise in devices using Bluetooth.

WUSB operates on a completely different set of frequencies and technology and couldn’t share hardware with WiFi. Maybe it could have taken off if there was a killer app, but there never was.

At this point, the decision to add Bluetooth or not is literally just a product decision. If you don't want Bluetooth in your product, you actively have to disable the Bluetooth part of your WiFi chip, because you can't really get a WiFi chip without Bluetooth.

All of the BT+wifi chips I’ve worked with require active initialization of each feature; you have to signal the chip (over i2c or SPI or whatever) with what kind of BT operations you want.

No BT stack in your product, no BT radio initialization, no BT/wifi multiplexing. At least in the (admittedly limited) chips I’ve worked with.

> the wireless headset was the killer app in its early days

Don't forget music piracy.

At least over here, a lot of kids had phones that did Bluetooth, and the primary use case for it was sharing songs they liked with each other. You could use infrared (IRDA) for that, and some people did before Bluetooth was common, but it was much slower.

This was mostly on low-end Nokias, maybe with a bit of Sony Ericsson thrown into the mix. They definitely did not have WiFi, in fact, Nokia even tried to limit internet over Bluetooth for usual carrier monopoly reasons as far as I'm aware, but Bluetooth was definitely there.

For many here, the iPhone not doing file and ringtone sharing over Bluetooth was one of its main limitations, at least early on. It was a social network in its own way, and having a device that couldn't participate in it was no fun.

> Don't forget music piracy.

What you describe is file sharing, not necessarily piracy :-). Just nitpicking, I understand what you mean of course!

Wow this unlocked a bunch of memories from middle school where we would send each other the latest songs and games via bluetooth. I remember pirating games for my sony ericsson and sharing them with my friends and we would play these games in class. You could just share and install the .jar files. Good times

By "early days", I was more thinking about the 1999-2005 era, before low-end Nokias even got Bluetooth and the ability to play MP3s.

The wireless headset was the killer app that drove bluetooth adoption within cellphones, driving down costs until eventually the lower-end models receiving it too. While sharing files was possible in the 1999-2005 era (especially with PDAs), most phones were lacking enough flash storage to store anything worthwhile.

While I don't want to say file sharing wasn't a killer app, it does seem to have been limited to just schools during a certain time period.

A time period that I missed out on by a few years. At high school, we did all our file sharing by swapping burned CDs. Then we switched to dragging around laptops and USB hard drives at university (and using the private emule network on the university wired ethernet).

It may be worth articulating the Bluetooth headset specifically as the one-ear little clip headset executives and IT staff seemed to use to answer calls.

Remember companies like jawbone?

I vaguely remember a cultural stereotype of bmw drivers driving aggressively and wearing Bluetooth headsets. [edit: this is the clip https://youtu.be/UqfAMvXpSw4?t=25 from top gear of jeremy clarkson wearing a bluetooth headset in sunglasses in a bmw, supposedly from topgear season 10, episode 10]

Yes... there is a very interesting generational thing going on here.

Bluetooth headsets were very popular among a certain market segment (business people who made a lot of phone calls), but saw very little adoption outside of that. At that time, you often had to buy an expensive business grade phone to get bluetooth functionality.

Then once Bluetooth was common in cheaper phones, we see a completely different market segment (students at schools) rapidly adopting bluetooth for a completely different usecase (file sharing). It's hard to find two market segments that are more isolated from each other.

I don't think file sharing could have ever driven bluetooth to mass adoption on its own, partly because companies always overlook what school students are doing with technology. But mostly because the file sharing usecase required mass deployment of the technology before it could take off.

When I was in high school, I had a palm PDA with IrDA that could do file sharing. But did I ever use it for file sharing? No, because nobody else had devices with IrDA. IrDA never hit the market saturation it needed to be actually useful, so there never was much demand for it (despite the hardware being really cheap, especially compared to a dedicated bluetooth radio)

Bluetooth headsets worked as a killer app in those early days, because a single BMW driver could buy both a high-end phone with bluetooth and a headset from the cellphone store and get the complete experience. It worked without market saturation.

Jabra! In all seriousness the blackberry Bluetooth earpiece was the killer app (hardware / device).

BlackBerry HS-655 Bluetooth Headset

Worked perfectly paired with a bb.

> the wireless headset was the killer app [for Bluetooth] in its early days

But the wireless headset is now a horrifying millstone making Bluetooth look like the world's stupidest trash fire. If you enable your microphone, you lose all audio from anything that doesn't want to use the microphone as the headset switches into "headset" mode and drops anything that wants to use "headphones" mode. There is no reason for there to even be two different modes.

Why is this still happening?

Except for the "headphone" versus "headset" mode dichotomy that is inherent to Bluetooth, all those other issues are due to stupid product decisions that most OSes do to themselves independently on the same way.

If you use Linux + KDE, you can still use any microphone or headphone, many at the same time, or in whatever mode you want.

Linux + KDE user here.

It used to work on kde/plasma 5 at some point. And after a minor version update it stopped working.

Now the mic of my headset doesn't work because KDE insists that only the high quality sound output without mic is available. The mic + low quality output is gone from the settings.

Lucky for me this update also brought proper handling of the stereo positioned noise cancelling microphones on my thinkpad. So now I can actually enjoy the luxury of built-in microphones that work. Until the day it wont I guess.

if you use pipewire it works fine both in plasma 5 and 6.

but the audio quality in the sound + mic profile is very poor, the codec is only meant for speech

I am using pipe wire. The option to select the handset mode is gone! I can only select the various output codecs with my increasing quality. But not the mic & output mode. It's gone from the list...

Wow brings back memories when this used to be a problem on gnome like five years ago.

> If you use Linux + KDE, you can still use any microphone or headphone, many at the same time, or in whatever mode you want.

This doesn't really seem to respond to the problem. The problem is that I'd like to use a single bluetooth device that includes earpieces and a microphone. That doesn't work, because of the headphone-headset mode dichotomy. As I replied to another comment, using multiple devices would be a solution to the problem. It wouldn't be an example of the problem that I want solved.

Bluetooth is apparently incapable of simply delivering an audio stream to the earpieces while accepting one from the microphone. This is a baffling design. The assumption appears to be that there will never be more than one source of audio for output. But that's crazy.

The absolute madness that is Bluetooth pairing between cars and cellphones is wild. If I get into my car and it decides to randomly pair with my wife's phone (who is inside the house) and I drive off, the whole infotainment system is locks up and dies until I get to my destination and turn off the car.

What car do you drive? Then I make sure to not buy it

Mine connects and starts playing silently, and you need to press play and pause on the headunit to make it make sound. Every two months or so it fails to connect to the phone and needs a complete forget and repair to happen. Toyota unit and iphone.

It is happening because it works the way that is most useful to most people. The number of people who want to use bluetooth earbuds with a different microphone is line noise in the consumer market.

Implementing special requirements is always inconvenient for users because no B2C wants to risk bad the-microphone-didn’t-work reviews, customer returns, and support tickets.

Nevermind coordinating with arbitrary USB microphone latency…I’ve got one with 250ms of it.

> It is happening because it works the way that is most useful to most people. The number of people who want to use bluetooth earbuds with a different microphone is line noise in the consumer market.

I don't think you have any idea what you're saying. The scenario I'm describing is when you want to use a bluetooth headset that includes a microphone. Using a different microphone is how you solve the problem.

I have never had a microphone problem with a bluetooth headset. They all always just work until something mechanical breaks through use.

If I had an issue, wired headphones seem a simpler solution than changing the bluetooth standard and more likely to work than wishing manufacturers changed their devices.

So, the standard defines behavior that is obviously pathological, actively working against the needs of all users. But because it's already codified, it's a bad idea to change it?

Works for my needs.

If it didn't, I'd use wires.

Or something else.

it happens because bluetooth profile for audio+microphone uses different codecs and has less bandwidth, due to being used for realtime communication.

the bluetooth audio streaming profile enables more codecs, but only playback, and allows significantly higher latency that you wouldnt accept on a call

> and allows significantly higher latency that you wouldnt accept on a call

That latency is also a millstone. We can do much better, but the standard lags and implementations lag even more.

My personal bluetooth ear clips do something much worse than adding latency - if they're not currently playing something, and a sound is supposed to come through, they omit the beginning of the sound while they get ready to become active or whatever it is they're doing.

Just delaying the sound and playing all of it would be a big improvement.

(Though that would fail badly for watching videos. That's something that uses 'headphones' mode anyway - why is latency OK there? It isn't.

My ear clips do add some latency, a noticeable amount, when I'm watching a video with mpv, and I adjust that by altering the A/V sync setting. They don't do the same thing when I'm watching something on youtube. I'd like to know what's going on there.)

well you wont get any argument from me that things could be significantly better.

> why is latency OK there? It isn't.

well.. if you listen to music, you probably dont care too much, but if you're talking to someone, you do.

whats much worse is also that latency is not constant.

obligatory xkcd: https://xkcd.com/2055/

Except this isn't a problem of trying to manage multiple connections. Bluetooth can't even handle maintaining a single connection between two devices.

My partner's hearing aid connects (via some radio protocol) to a device that then connects via bluetooth. Unfortunately, it presents itself as a headset, which causes... problems. For Android, they have to use an app from the play store that presents itself as an audio device and then sends that to the 'headset'.

The ironic thing is the Bluetooth ignored it's audio use as much as possible for as long as possible. They wanted it to be used for tracking shoppers in stores...

Bluetooth was the main way to transfer music from dumbphone to a dumbphone

how to use a phone in car without headset / bluetooth to talk legally?

Back when Bluetooth was new, the alternative for wirelessly sharing data between mobile devices like phones was infrared.

IR was exceptionally slow, required line-of-sight and even at the time, felt like a shitty solution. So even though the early implementations of Bluetooth also left a lot to be desired (battery hungry, insecure, and also slow), it was still a massive improvement on what came before.

Wireless USB wasn’t a significant enough improvement to Bluetooth given that BT was already ubiquitous by that point, but also cheap and (by that point) battery efficient now too.

IR with palm devices was super nice - just point to the other device and send, then confirm on the other. No persistent pairing bullshit & you could also use it to control TVs.

That’s how BT originally worked too but it got abused (I touched on this in my original comment when I said BT was insecure). The paring is a security measure to protect people from abuse.

Back when BT was new, I used to get all sorts of random shit pushed onto my phone every Friday night on the drunk train home from London.

I guess that was a lot less of a problem with IRDA as it required line-of-sight, which limited the abuse potential significantly.

Some devices would even establish an IRDA connection automatically as soon as they found anything. I have friends whose laptop names have suddenly appeared on lecture room projectors, as their laptop's IRDA receiver was in direct line of sight of that of the teacher's.

Not that you couldn't do that with Bluetooth, some early BT chipsets gave you a "<device name> wants to connect to you" dialog box any time somebody tried sending something to your device. This could be abused, to great student amusement, to display funny messages on that same projector if the lecturer's laptop had such a chipset.

I wonder why IR is slow. Shouldn’t there be plenty of bandwidth available at those frequencies?

Not through a tiny photodiode + amp on a spare UART RX, if not repurposed TV remote phototransistor. They can be slow.

These days, professional optical equipment, aka expensive lasers+supporting hardware, can do 10-Gbit over multiple kilometers through the air, so you're right that optical transmission through the air should be able to support higher data rates.

The problem with Irda is that it's old. Technology has significantly advanced since the 90's, when Irda was popular on cellphones, so a modern implementation could do better data rates even accounting for the significant interference from the environment. We barely had wifi back then, and now it'll do a few hundred megabytes per second without breaking a sweat (your ISP might though). All the technology required to do that didn't exist in the 90's. We have Bluetooth now though, so there's that same bootstrapping problem, where you'd just use Bluetooth, and not spend a bunch of money building a system very few people are asking for, so then there's little demand for a modern high performance Irda system in any devices.

Mostly just SNR issues.

I'm frankly baffled at all these reports of IR being unreliable and slow. It... wasn't. Not for the file sizes of the day. I exchanged plenty of files back in the day, even at 115200bps a picture would be 2-3 seconds tops (pictures were small!). And when devices started supporting 4Mbps, even a large-ish MP3 would go in 5-6 seconds. All without setup or pairing, beautiful. Huge files (like full resolution pictures from an SLR camera) would take a while - but frankly they took almost the same time with a cable! You'd just have to plug their memory card directly into your computer if you were in a hurry.

The only really clunky use case for me was internet access - keeping phone and laptop positioned and aligned for 30 minutes was limiting.

And yes there IS plenty of bandwidth at those frequencies. In fact latest IR standards reach 1Gbps, but it's pretty much extinct. There was an attempt called Li-Fi to use it for as a wireless networking but I don't think it went far.

What I really miss is OBEX (Object Exchange), which worked also over Bluetooth, and which Apple sadly chose not to implement: simplest protocol to just ship a file or a contact vCard over, no setup, just worked - and it's been a standard for 20+ years. Early Android had it too, it was since dropped I think. Sigh.

It would take me like 30 minutes to transfer 1MB.

You were pretty unlucky. The basic bitrate was 9.6kbps but much higher speeds were common.

At 9600bps. Almost every device supported 115200 - that would cut it down to to 72 seconds. And as I mentioned - pictures were often small (20-30kbytes) back in the day - that's barely 1-2 seconds at 115200. And the later 4Mbps speeds would move that megabyte in 2 seconds flat.

You’re either misremembering things or talking about an era after Bluetooth had already taken off.

In the days before Bluetooth, transferring MP3s over IR took multiple minutes, even on high end (for the time) handsets.

And the fact that you needed to keep line of sight during the whole process meant your phone couldn’t be used that whole time. Which was a real pain in the arse if you got a text message or phone call while trying to transfer a file.

IR was really more designed for swapping contacts. In fact that’s exactly how BlackBerry (or was it Palm?) marketed IR on their device: a convenient way to swap contact details. But you’re talking about a few KB vs several MBs for an MP3.

The tech has definitely moved on since. But then so has Bluetooth, WiFi and GSM et al too.

It was harder to extract a clean signal due to ambient environmental conditions.

You could probably solve those issues with modern tech though. Things have advanced significantly since IR was popular. For example, back then Bluetooth was slow too.

Introducing a new wireless protocol is incredibly difficult. You basically have to have all the countries in the world to give you a chunk of their spectrum.

You have 2 mainstream protocols now, one for low energy, slow data transfers (Bluetooth) and one for fast, but more power hungry devices.

I don't see the usecase for UWB.

And as far as I know, Wi-Fi and Bluetooth didn't have frequency given to them. They instead used frequencies that were already available for unlicensed use.

In my opinion, for computers, wireless mouse (and eventually keyboards) was one of the killer app that showed pushed for Bluetooth to be common in computers and laptops. "Not needing a dongle" was a huge added value compared to the private radio protocol of manufacturers

My guess is just that Bluetooth and Wi-Fi came first, and when wireless USB entered the party, there wasn't a real need for it, as most of its use cases were already covered by Bluetooth and Wi-Fi.

It maybe could have worked with better marketing, but convincing potential customers to change something that works (somewhat, BT wasn't without issues) is hard. That's why we are keeping abominations like cigarette lighter sockets in cars even though they often can't even light cigarettes anymore. It is already well established and it works well enough as a power outlet.

Bluetooth took off because it was easiest path to do wireless headsets when handsfree driving laws passed.

Maybe the low-power feature of Bluetooth helped it, such as with the Bluetooth LE (Low Energy) spec that with the way "services" and "characteristics" are defined that it allows for extremely low power consumption when no read-operation is done and thus the Bluetooth radio power can be minimized. Also, the 2.4 GHz band of Bluetooth is inherently less power consuming than the higher frequency band of Wireless USB.

But I guess the other problems may have been due to as the OP article brings up about it being in a different frequency communication band. Bluetooth on the other hand shares the same frequency band as Wi-Fi (2.4 GHz (which is also the OG Wi-Fi frequency band)). Thus for PC and mobile device OEMs, it is one less antenna to integrate. Furthermore, the higher frequency of the band would have made through-walls and further-distance communication less reliable. In this context, one of the few cool applications of wireless USB would've been a wireless keyboard or mouse (but this is coming from someone who is working on an OEM computer keyboard and mouse).

> which makes the value proposition a lot less clear.

Wirelessly transferring files between a phone and a computer seems like a big use case. Still no easy standard way of doing it.

Imo cloud storage like Dropbox has 95% solved this use case for years, which is why alternative solutions haven't popped up.

Needing to upload files to third party servers just to get them onto your personal computer doesn't solve the case. It just injects a middleman.

And only works when you’re connected to the internet.

How does it not solve the problem? The data shows up on the other end. The fact that you don't agree with the implementation is a different thing, but it does solve the case.

> How does it not solve the problem?

It "solves" it but in a way that's ten times slower and fundamentally unreliable.

For small files maybe. As shocking as it may seem, most Dropbox users just have the free version, with very limited space. Same for Google Drive or One Drive.

Dropbox is unavailable to huge populations. also sharing private bits with a cloud service should not be necessary to transfer files locally between devices. at least user level file encryption should become straightforward on a mobile device which it is not today.

But that doesn't need new peripherals, I could do that in my home WLAN network if they'd just install standard software for it on the phone (which you can fix by installing it from F-Droid etc.)

scp works well for me.

That requires having an account on the other machine. What's missing is anonymous scp, where the other side just opens up a directory, and you can copy into it. One can build something like this with rsyncd, but it's not a pretty shell one-liner to get it going and it still requires both devices to be on the same network.

What I responded to was "wirelessly transferring files between a phone and a computer", assuming that I am the user at both ends of the transfer.

If I want to share something with someone else, there's a "File Sharing" section in phone's settings that enables anonymous WebDAV sharing, and it works fine too. There's Bluetooth OBEX too, but that one's fiddly.

There are websites using WebRTC for p2p transfer.

I assume this is the same "problem". Most people (not the HN cohort) don't want to transfer "files", the abstraction of the file is either outdated for them or maybe even unnatural / unknown (younger generation).

They might want to transfer (a better word: share) photos/videos, documents, etc. And for those they use specific apps and "the cloud". No "files" (for the sake of files), and barely any hierarchy of (folders etc).

As long as the entity they want to share magically shows up on the another device or at the other person they want to share with, they are happy. They just skip two levels of abstraction ("this photo is a FILE and I will use USB to transfer it"). Maybe a far fetched analogy but this is why most of the drivers of an automatic don't really think about clutches and how the torque of the engine's output is converted.

At least this is my perception (outside the IT bubble)

I want to add something to this: abandoning the fire layer allows for richer custom flows (which to many are arguably worse)

For example the file API does not allow a clean, uniform, and reliable way to associate a resource with some metadata

The file API might not, but all major filesystems implemented some kind off Metadata attributes, IIRC Microsoft was wanting to heavily rely on that for "user space" stuff (e.g. Users leveraging it for semantic information about their files)

I don't get that. How do you expect to abandon the file layer on your OS? Do you plan on rewriting Windows, macOS, Linux, Android and iOS with a fundamentally new philosophy?

If not, then you're not abandoning the file layer at all. You're just preventing people from benefitting from it.

If we don't have files, then what?

Seems to me we very rapidly arrive at records or entities.

We see both these days in databases.

Entities show up in CAD and simulation. Records show up in business tools of various kinds.

All require a schema and serious dependencies flow from there.

In CAD, for example, the database schema can change quite dramatically from version to version of the same software tool. And all this makes writing plug in tools or anything really painful.

And forget exchanging native data between systems. STEP exists for that, and O God help you on a bigger project involving any old data

The thing about files is they are basically EASY.

And easy, when looking at where we are going, matters. A lot.

Files can exist on pretty much anything. Paper tape, mag tape, all sorts of media, up to advanced storage tech.

Databases are a different story.

I am not convinced we are anywhere rear being ready for that huge leap.

And I would normally say "forward" but on this?

Nope!

It would be a huge mess requiring we toss just about everything we have in use today

> and barely any hierarchy of (folders etc).

One of my great hate pet peeves with all smartphone and cloud apps is the "abstraction" and reliance on search. For me folders is quicker and less error prone, and as a bonus it saves on unneeded bandwidth (to load previews) and computing costs.

Also stop telling me I must use your one off "feature set" of sorting and ordering which either nobody uses or copies differently. The amount of square wheels (for me I must add, ymmv) reinvented is astonishing.

Folders as an abstraction don't really make sense beyond documents, though.

If your music is stored in a folder hierarchy, and can, in principle, be located anywhere, how do you index it to provide a library view? How do you distinguish it from random audio files that just happen to be ID3 tagged, but which you don't want as part of your permanent music collection? How do you efficiently react to deletion events? What happens if you delete an entire artist's worth of music from your music app? Should it delete the files, or only the library entries? If it deletes files, what if (some of) that music was in a folder that didn't contain any other files? Should that folder be gone too, or should you be left with an empty folder or hierarchy? What if the folder also contained a .nfo, is it good UX if it deletes the music and just leaves the .nfo?

If the only tool you have is a computer, everything is a file. If you're a music lover and not a computer enthusiast, you tend to think about albums, artists and playlists, and that's how you want to view your music collection.

You index it with btrees just like everything else. You distinguish it by configuring which folders to watch. You react to events with inotify. You don't give your music app write permission to your library. It only needs to write its indexes and playlists. All of your other questions become irrelevant; you delete the files you mean to delete with your file manager. In practice, music is small and storage is cheap, so deleting seems like a weird use-case for an application dedicated to music. I still have files that have been migrating across computers for 25 years.

What if I want to look at a list of composers, but the folder structure is by artist?

What about playlists?

The limitation of the folder is that there’s only one.

Your player scans your library and indexes/sorts it however you'd like. I think this is how basically every player with a library function works? Like jellyfin loads my library in the same structure I've had it for 20 years, and it gives me various ways to view by name, artist, release date, rating, etc. and builds search indexes. I just point it to the roots of my libraries.

I said it needs a place to write playlists (or write access to your playlist folder(s)).

I wouldn't do it this way, but there can be more than one folder containing the same file (hardlinks).

> Your player scans your library and indexes/sorts it however you'd like.

Which means the concepts of files and folders becomes immaterial. If a music player is only interfacing with a database of music metadata it doesn't matter how the bytes on disk are organized.

There's a reason there's been 30+ years of file systems trying to tack on database functionality (BeFS, WinFS, etc) or over the top metadata indexing (Spotlight, Lucene, etc) to file systems. The files and folders abstraction is not sufficient for non-technical users in many cases.

The music player isn't the only thing interfacing with those files. Backups do. Network file shares do. Pendrives, dedicated music players, and children's toys that can load music do. The player changes over the years (winamp, VLC, amarok, clementine, jellyfin, etc.). Sometimes "apps" go wonky and the only way to fix them is to "clear user data", which is opaque, and you'd rather control that/be more selective.

I don't really care how the player stores its metadata (the secondary indexes it makes after the scan), but I don't want it mucking with the original data, which I've had and will continue to have far longer than the player. Files in a known format (e.g. .flac) offer a standard, common interface for storing that data that's easy to organize and exchange across computers.

Google drive also shows what a world where people don't use folders looks like: I can never find documents at work without a link even when I have an idea of what I'm trying to search for. Folders at least push the user to do some organization. GDrive happily encourages you to do none.

The worst is photos, because the search abstraction really breaks there. On modern iPhones, it's still a pain in the ass to organize photos in such a way where you can come back later and find them. I'm still in the "scroll through the timeline until you spot it" phase.

Machine Learning is making this better, but ideally albums or folders wouldn't be such a pain in the ass to actually use in day-to-day life.

I believe in the opposite.

Because we can't transfer easily transfer files between devices remotely, we had to get used to do it via apps. And so we didn't developed good, local files browsers (esp. for media) and companies invested in the cloud UI mostly because they could sell the storage and sharing capabilities. That was all unnecessary but we're used to that now to a point where sharing files is weird.

As a power user happily syncthinging all my files between all my devices, I'm sad because files is the easiest thing to share, organize, transfer, etc. I wish iOS supported this kind apps (full storage access!) as we could avoid the many, crazy, Alps specific workarounds just to share some stupid files.

And don't confuse the file itself (say, a pirated movie), the metadata (IMDb IDs) and the apps UI (Kodi!). Files is what we have, we should share files and let anyone pick the browser/apl they like for viewing, organizing…)

Don't get me wrong, I'm totally happy woth files. In fact, I'm sometimes a bit annoyed when certain apps' entities don't map to files either accidentally or to maintain the walled garden on purpose (I'm looking at you Google Photos, and the very cumbersome rclone connector to it).

On the other hand, I don't mind that full storage access is a "pain"; I don't even remember which apps I gave the permission to, and I would certainly be angry if my syncthinged files would be stolen by other app that went vicious.

All that said, as people don't think about their documents/photos/any other stuff in their homes as "filed items in folders", non-tech people also don't think about their digital items as such. And maybe this is alright, if the "file-ification" would have been so successful, better products would have emerged.

Also, they want to use the same "abstraction" for "sharing photos with their friend when they're on holiday in another country" versus "sharing photos with that same friend when they just got back and are literally sitting next to each other."

People don't really internalize that those are two different use cases.

Yes there's Airdrop, but I think most people view it as more of a "discoverability" solution than a file sharing solution. If you met somebody you don't have a number for, "okay just Airdrop this to me" is much easier than doing the whole song and dance of adding them to contacts and sending them an iMessage or finding them on Whats App. Whether the actual file transfer part of Airdrop goes over the internet or over Bluetooth isn't something most people care about, as long as it can discover nearby devices and initiate a transfer to them, it's good enough.

I disagree. I find it condescending when techies say "the average user doesn't make the difference between sharing a file to a device next to them and sharing a file over the Internet".

Everybody, and I mean everybody is capable to understand that to connect their Bluetooth headset to their phone, they do it over Bluetooth. And that to connect to the Internet, they can either go over WiFi (which is "free") or cellular (which is less "free").

> People don't really internalize that those are two different use cases.

We actively keep them ignorant, and then we use their ignorance as a justification. I find it sad.

What if we said "People don't want to drive their car somewhere, they want to go from A to B. We should prevent them from learning how to drive so that they would have to pay for our taxis".

I think I disagree with that. This "people don't want files, they want to share photos", to me, is what product people want to believe. The whole thing has been enforced on users and is self-reinforcing: of course if you don't show files to users, they will not know what a file is.

Sure, I may be in a photo gallery and I may want to share a few photos with a friend who may want those photos to be treated as photos (instead of going into a big "Downloads/" folder). But it doesn't mean, at all, that the concept of file has to disappear to the user. In fact the files still very much do exist on the system. Product people just assume users are stupid, IMHO.

And the thing is: this abstraction (not knowing what a file is) doesn't make it faster or more efficient. It just makes the user more dependent on their platform and apps. Look at backups: product people at Google/Apple will tell you "people don't want to backup their files, they want to pay us to make sure that they never lose an image". Conveniently, it means that people are 1) forced to pay them and 2) don't have control over their own files.

Maybe GenZ/alpha now are stuck with these abstractions because they never learned what a file was (for no reason other than being abused by product decisions), but older generations grew up with physical media. "I have a piece of paper, I have a book, I have a CD-ROM, and those are all different kinds of files that can go into different "boxes" that are called folders".

Files and folders are very natural. The reason people don't know about them is because we hide them and force them to pay for literally subpar experience.

> is what product people want to believe

It's quite clear what you never had to explain why 'only looking at a pictures/photos on the Internet' wasted the mobile traffic.

Were you born with the knowledge that a video takes more space than a photo that takes more space than a text?

Or is it rather that you consider yourself one of the few people smart enough to memorise it? I find that very condescending.

I don't believe that one needs 3 postdocs to understand it. In fact, I do happen to have explained it quite a few times, and I don't remember anyone not understanding it.

Folder / Directory

I most frequently use the latter, directory when I am talking files and filesystems.

Most people return that with "folder", and I am sure that has to with my learning about these things happening where "directory" was the norm.

I have been educating people about files when I bump into ones that do not know much. The abuses are real and growing. Nice comment.

There's no formal standard, but I keep seeing this complaint from people who just haven't installed syncthing. At this point it's not inexistence but mere ignorance

It's not only about your personal devices. Sometimes you want to exchange files between a friend phone's and your computer.

Which is also way way easier to do than all the existing solutions: create a folder on the computer, add the computer to the phone, share the folder with the phone. Anything you want to share goes in the folder.

Bluetooth FTP was widely supported until ~2009. All Nokia phones and many flip phones had it. iPhone did not, AOSP technically did, but carrier phones often had it disabled, and it slowly disappeared.

Windows 11 still supports it, I think macOS too. Pairing is technically optional.

It does and I managed it recently. It was painful.

I had to pair, or at least I think I did. Was fetching a file. off a flip phone. Doing these things without "file" gets weird quick.

I also seem to recall an awesome Bluetooth control panel applet I used a few times in Windows XP.

At the time I had a pretty spiffy Moto flip phone. It could be the computer keyboard, handle audio play and record and more.

Pretty sure that all came from the phone driver. I do recall also using the computer in reverse the same way when the display was badly damaged. I could make phone calls, dialing with the computer and in general use the phone taped to the back of my laptop screen.

Today, it is simpler, and far less robust.

aw. it hurts my brain to think about those days somehow. An awesome panel must be BlueSoleil. There were Microsoft XP SP2 stack that were stable but featureless, Toshiba stack with (IIRC)SCMS-T DRM support, WIDCOMM stack that show up on search now but I had no experience with - apparently tied to specific dongles, and the IVT BlueSoleil stack with the orange sun floating against dark blue background.

BlueSoleil was by far the most feature complete, and, as far as my interests back then were concerned, required for Wiimote on Windows. It was (not really)available as trialware but interoperability wasn't guaranteed so you would have had to pull dongle lottery until you hit a product with reasonably stable build of BlueSoleil if you had in mind a specific task to do in Bluetooth.

Fun times... things do feel less robust these days. Software was much better tested back then.

Yeah that seems familiar. One night on business travel, I decided to just play with the setup and really thought highly of it all.

Then some years passed, I got a Blackberry Curve, then a Note 4 and by the time I looked back at Bluetooth. I HATED IT. Still do, though I am grudgingly working through basics, phone call, play audio, etc and the whole time looking at my still wire capable hardware thinking "not yet"

This is an UX problem, not a technical problem. You could easily use Wifi to transfer files between devices quite fast, there's just no agreed upon open protocol for it. Afaik that's how AirDrop works.

Airdrop works. Ok, it's platform bound, but I'm sure it could be ported.

It's not such a big thing, though. I hardly use it, and young people don't seem to use it either. The stuff on their phone and laptop seem separate worlds, just like mine are. Might be because they don't know about it, though.

Because we keep them ignorant. We make sure they depend on our apps that they have to pay for. You wouldn't want them to know how to download music/movies without going through our paid streaming platforms, would you?

Hell, copy and paste works between iphone and MacOS if you've got the same icloud logged into both. Airplay is too cumbersome has been supplanted by long hold -> copy; ctrl-v, and the reverse. Works for images as well.

Transferring files between a phone and a computer was a real use case, but since wireless usb was "exactly like regular usb but no wires" it wasn't any easier to set up file transfer than regular usb (harder, actually, since you had to do the wireless bonding), and wired usb would charge your phone battery while the files transferred whereas wireless usb would drain it.

> They worked - you really could get USB 2.0 full rate connections wirelessly and we had some neat demos.

TFA mentions that contemporary users of these things didn't get anywhere near Hi-Speed USB speeds. The author's present-day testing agrees with these reports, finding that at least one device's maximum performance was just barely better than USB FullSpeed.

If you were seeing 480Mbit performance with the hardware you were doing demos with, what went wrong between the demo table and the finished product?

The product in the article I think it said came from 2006? Not based on the chips I worked on, anyway.

Just like early wifi, there were several companies working on wireless usb chips at the time, and performance could vary a lot depending on who's product you bought, and when.

Here's an article about us I found from 2008.

https://www.eetimes.com/staccato-communications-ultra-wideba...

The "ripcord 2" chips (mentioned) definitely could do 480Mbps at short range. I worked on the design of the next generation after that (equal performance, but lower-cost/lower-power-consumption), which never made it to the commercial market.

"What happened" was the combination of the product/ market mismatch I mentioned above (like, the wireless laptop dock was cool for a demo, but it didn't charge your laptop battery like a regular wired dock would, so it wasn't actually practical for daily use) so we didn't have enough revenue to self- sustain, and the "great recession" meant investment dried up and we eventually just ran out of money.

Staccato merged with a different wireless usb startup to try to delay the inevitable, and then tried to "pivot" to something profoundly stupid and I bailed at that point. (They did an internal demo of the new "product". It was maybe the worst tech demo I've ever seen. I was out 2 weeks later. I think the company dragged on for maybe another year.)

Ah. Nothing went wrong between the demo table and the finished product; the author is working with Mk. 1 products.

Thanks much for the additional detailed background information. Sorry to hear about the slow demise of your former employer.

> but you still have to plug the device into a cable at some point

That may explain why I can't find a 5 Gbps wireless USB extender for my work web cam.

https://hardwarerecs.stackexchange.com/questions/18983/wirel...

But today we can have wireless charge too, would that change things?

USB over QI wireless would be great.

I think it could. If wireless charging docks has been common at the time, the upgrade to "now your wireless charger can do data sync too" is a straightforward improvement.

Unfortunately, at the time there was only one phone that had wireless charging built in (Palm Pre). I know our sales and marketing did try to engage with them on getting wireless usb into "the next version" of the Pre, but nothing came of it. I don't know the details.

At this point wifi is ubiquitous enough that a new version of wireless usb would have a hard time competing with it though.

Reply on news.ycombinator.com