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).

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

> Don't forget music piracy.

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

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.

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.

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.

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'.

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.

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

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.

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.

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.

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

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.

Mostly just SNR issues.

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.

> 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.

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.

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.

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.

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 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.

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)

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

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.

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.

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

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.

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.

Fans reduce sensible heat because humans have evaporative cooling.

A backpack is pretty much a closed system and chips use convective cooling.

Adding a fan won’t create a positivee pressure gradient between the backpack and outside world but will add 3 or more watts of heat to the closed system.

> Connecting over radio requires pairing, that is very frustrating when it doesn't work.

Everything's frustrating when it doesn't work.

> Connecting over radio requires pairing

This is a solved problem, plagued by technology fragmentation. You could very well save the necessary information for discovery and pairing onto an NFC tag and use that to access the network (further authentication might happen, if configured).

This is basically never done on WiFi because you cannot assume a client host has a NFC reader (let alone proper code handling the tag and the information).

But it's done in the world of bluetooth: some big-name headsets (Sony IIRC) can do bluetooth connection negotiation via NFC. You activate the feature (dedicated button), tap your phone and off you go. No pin, no pairing annoyances.

> But HID had not been designed for the possibility that packets could get lost

Doesn't the same problem exist for USB dongles with proprietary RF protocols?

Logi Bolt is a good solution. But ime most other USB dongles are terrible. I have had a lot of bad connection issues with such USB dongles, and never with similar bluetooth devices. USB dongles also use the same 2.4GHz band, and even more they are prone to interference from nearby active USB ports [0]. If you have ever had a "jumping" mouse while transfering big amounts of data through a port neighbouring your mouse's USB dongle, this is likely the reason.

[0] https://www.usb.org/sites/default/files/327216.pdf

Bolt can't be better than BLE because it is BLE. Same with Apple gear which pairs so seemlessly.

It's just that they control both sides of the signal so can better optimize the connection.

I mean, you can't type in BitLocker password wirelessly without a dongle. Optical mice sensors aren't so repeatable anyway, so missing a packet or two probably aren't so critical.

I mean, they aren't putting raw HID packets on the air, they're encapsulated within another protocol that does handle reliable retransmission.

It’s fine for any use of a keyboard or mouse besides a niche in gaming. It also uses less energy than most RF dongles, which results in better battery life (something I could check using a couple of mice that could do both).

The fact that Logitech’s current dongles are just BLE with a fancy encryption scheme tends to indicate that they really want their proprietary hardware, and bandwidth is not the reason.

I bought a new mouse recently and intentionally got a dongle one, not that it was hard to find. It's just better.

As opposed to a USB device which requires you to install an opaque driver, which could also phone home? That’s hardly a win as far as security goes.