I used to do Bluetooth snooping as part of my job (debugging Bluetooth firmware on an embedded device). All communications are encrypted (or should be, even if unencrypted comms are possible); the only time the connection is vulnerable is during pairing. You don't do that very often normally, but the "sniffer" that I used had to observe the pairing process in order to get the keys. It also needed the Bluetooth PIN (at that time, almost every device required one during pairing, but almost every device used something trivial). So if you can use a custom PIN, don't have your devices "discoverable" except when you need to do pairing, and do your pairing away from untrusted people and devices, I thought it's pretty secure, unless there are new exploits since then that I haven't kept up with.

I assume this passkey thing should be a public/private key scheme: the private key should be generated on the device and never disclosed, the communications are just transactions involving the key, and thus it would be hard to crack even if they were in the clear. Hopefully?

To get multi-device support, maybe that's kindof like gpg encryption with multiple public keys, so that the message can be decrypted by multiple receivers, each with their own undisclosed private keys. Or maybe not even that... if a user simply has a separate key pair for each device in use, and all the public keys are public, then any of the user's devices could do signing transactions that could be verified with the appropriate public key. Not sure if that's enough, and I haven't dug very deep into how the existing FIDO standards work.

AFAIK FIDO has been doing OK. But I do think it would be best if the "something you have" factor was a hardware key, not the same device that you are using to open a web site. I've gotten used to my yubikey, it works fine for several purposes, but there are just not enough web sites that support it yet. So my main use case is to decrypt passwords stored with the pass utility, so that I can have unique random user/password combinations for each web site that needs one. (And those I sync with syncthing. Except on the iphone... the lack of file sharing between apps really bites there. On Android it worked fine.) I also use the yubikey a lot for ssh and git push. Very rarely, I can use it to log into a web site. In theory, the NFC feature should make it possible on my phone, too. So I carry it on my keyring so that it's always available, and it has survived several years in my pockets that way, so far. This feels safer than relying on some inscrutable "pay no attention to what's behind the curtain" cloud service that automatically synchronizes passkeys, with the user expectation being that when (s)he uses a new device the keys will already be there... as the whitepaper says. That's the part I'd worry about, more than bluetooth.

If he wants to write about things he can see on the ground in Belarus, it's better to be there than to emigrate to some echo chamber in some other country. But it's too bad that it results in this kind of persecution for such a thing as mere writing on Wikipedia. Let's hope that Lukashenko and Putin will not be in power for much longer, and the backlash after they're gone will loosen up the communications again.

As far as I can tell, he was arrested for violating that new Russian law making criticism of the invasion illegal, that just now came into effect. So either that law is also being applied in Belarus or they have their own version of the law going into effect at the same time. Also, he's being accused of writing from an Israeli viewpoint, it seems.

Yes that's another good point: Venti https://en.wikipedia.org/wiki/... is just a key-value store, in which the key is a hash (fortunately 160-bit SHA-1 though, not MD5). And the Fossil filesystem is built on top. (This is mainly from reading wikipedia; I don't use it yet, because 9front doesn't set that up by default, so I haven't gotten around to figuring out how, yet.)

So I think this layering is a very good idea. People keep finding uses for key-value stores (for example to build more complex databases on top); and so far they mostly have to store those on regular filesystems somehow. If we make the layering explicit, then a filesystem is just one kind of thing you can store on the KV layer, but you can also build some kind of database alongside it, on the same substrate, and bypass the FS layer itself.

No that's terribly silly to keep reinventing metadata for each new file format. The point is filesystems and tools have got to stop losing the extended attributes. Extended attributes need to be standardized across all OSes, have the limits loosened up a bit (so a thumbnail image will fit, at least), _all_ the tools should support them (e.g. tar needs to save and restore them... like some versions of tar today already do), the filesystem should provide the indexing, and plain ls should have options to see them and sort on them. In a way, we are already headed that direction: you can use attributes today, and you can find the tools that do support them; it's just not very efficient to work with them so far. A few more tweaks and we could start to blur the line between extended attributes and an actual resource fork. I experimented with this a little in an image viewer: https://github.com/ec1oud/phot... (although admittedly I still didn't get into the habit of actually using that one).

I've been looking into plan9. I wondered if it supports anything like forks or xattrs, and it apparently doesn't (although with the Linux extensions, 9p protocol does support xattrs, but that adds other cruft too, so the plan9 folks think it's a bastard). But then I realized one solution is to be able to open a file as a directory: in that case you could see the extended attributes (resource fork) as sub-files. And you should be able to open a directory as a file too: that gives you some directory metadata (at least a file listing in some standard form, maybe something else; maybe we should stndardize on yaml or whatever to organize that). If you make that work on the filesystem, then you don't need to widen the API at all, even the xattr-related tools/syscalls/9p extensions could be obsolete, and "everything is a file" continues to hold: attributes are no longer special, they are just special files that are nevertheless easy to access. ls mydir lists the files; ls mydir/myfile.txt lists one file; ls mydir/myfile.txt/ lists its attributes; cat mydir/myfile.txt/author would access the author tag from resources, if it was written. Not that I've yet found a context in which I can actually implement this idea... but I'd like to.

I don't use reiserfs, because after getting used to zfs, I don't really want to go back to fragile single-disk filesystems (well maybe on a work machine, but not for my home directory at home). So I think zfs needs just a little improvement in this area.

A file should be identified by a hash. Probably it should be done the same way IPFS does it: a merkle tree of hashes of the chunks of the file. Then that could save a lot of work for the IPFS daemon: it should be responsible only for the sharing, not the storage and chunking and hashing.

Oh those old-fashioned parking lots and street parking, right. Seems like in Norway almost every apartment building (that is new enough) has a garage underneath. (Norwegians love their dynamite, it's not any trouble to have a basement or a tunnel in solid rock.) So that helps make home-charging more available too, as it turns out.

I guess you weren't around in the 90's when most web sites were free and started as a labor of love?

What we will build now is called web v3: if the hosting is distributed (IPFS) instead of centralized, then we could all share the hosting burden, and thus the cost can be minimized. Of course, to pay people to be full-time web developers and content authors, there has to be money coming from somewhere; but I think we were better off when there were more sources of information that were not from big-money centralized sources.

I've always wondered if mining ASICs are really completely useless for everything else, or the right clever person just hasn't come along and found the thing to do with them yet. And Intel could lead by coming up with something ahead of time. Otherwise yeah, what a waste.

Or, you know, all mainstream news in every western country and language worldwide, like the US seems to have. I live in Norway; it's astounding how the mainstream news is in such lock-step here. Probably they are all just translating "approved" single-source stories rather than investigating anything on their own.

I have to admit though, wikileaks has a lot to wade through (coming in occasional huge chunks), so I mainly saw news stories about what was published there, rather than reading the original material first. Probably most people are like that: propaganda that is in-your-face every day influences you a lot more than some single web site that you have to make the effort to visit and get through one wall of text after another, even if you're skeptical. Wikileaks is not organized as a daily news source either. And I don't know of any daily news source that is trustworthy; do you?

It sounds retarded to me. Cooking and heating water are the best uses for gas, the last thing they should ban. Yes there is the complication of installing pipes and making it safe, but if the market will bear the cost of doing that right, they should be allowed to. The US is lucky to have all that natural gas infrastructure already; some countries don't. Like Norway for example: first they put all their eggs in one basket, then they joined ACER, and now suddely electricity is not so affordable anymore, and there's no alternative.

Files and folders are just part of the office metaphor: the flat surface that you put them on temporarily is the desktop, etc. There used to be UIs with drawers in filing cabinets too. And rolodexes or other ways of managing collections of "cards". The metaphor was invented because it was intuitive for office people in the 70's and 80's to learn how to use computers, not because it was the only way to do it. Also, filesystems exist because we humans like hierarchical tree structures so much. Not free-form graphs, but trees. As if we have a hard-wired instinct that everything has to be organized in hierarchies, including people. Is it just us, or does this concept fall out of physics itself?

So while we ought to have persistent memory (like optane and such) and be able to use it any way we like, instead we just keep putting filesystems on that kind of storage. Then we put arbitrary-structured data into files. Then we load the data and have to turn it into something like a tree again to make it intuitive in the view layer. Trees within trees, all stored differently. DNS is hierarchical. Web sites look like filesystems but also expose ways of querying hidden hierarchical databases.

If we really must continue to like trees so much, there should be one interface for all of them: 9p. But when I was younger I thought the object-oriented model was cooler: instead of files there should be persistent objects, able to link to each other in arbitrary ways, like we often do in memory with linked data structures. I'm still not sure which way is fundamentally better, but it seems like the late-90's OODBs went out of style again.

So it's a bit hard to believe that kids don't understand hierarchical storage; if they haven't seen it before, they'll surely end up reinventing it.

I wouldn't be surprised if they mess up this opportunity, nor if the competition beats them on performance; but it's good to see a major foundry planning to make high-performance risc-v processors. I hope it will result in worthwhile risc-v CPUs and GPUs in the near future.

https://github.com/ec1oud/nett... : markdown, but wysiwyg like a word processor, portable and native (not electron for once!) I added markdown support to QTextDocument so that I could write it. I plan to keep adding features too.

I used to use LyX more: such awesome rendering to paper, but easy like a word processor. But how often do you need it on paper anymore...

It was a common name for home-built Volkswagon conversions already. http://www.evalbum.com/294 http://www.evalbum.com/2563 etc.

I use Signal mainly, and even managed to get a few family members to use it, even though they tend to prefer Viber for some reason that I don't understand. But...

I wish the desktop app was "native" instead of electron or whatever that is. I.e. just use Qt for the sake of portability; then it could be somewhat lighter weight. Telegram at least has native clients.

My phone often falls off the network when I'm out and about, and I miss messages because of that. Both ways: sometimes I don't receive a message someone sent, sometimes what I send doesn't get out. It should retry harder. It could perhaps fall back to using SMS when the network-based communication doesn't work, while still encrypting it? But then of course the SMS would still exist as metadata even if the contents are encrypted, so maybe that's why they don't do that.

It should be possible to use an independent ID instead of only a phone number; like a GPG key or something. Would that be insecure?

It's a hassle to switch phones: if I move my SIM to a different phone, only one phone can have working Signal at the same time, even though the desktop version has no problem with coexistence. And I suppose doing that temporarily causes messages about my keys changing to be sent to other users. So I'm kindof stuck on one phone.

I don't know what I will do when the Librem 5 finally ships, if Signal isn't on it, or if the OS isn't stable enough to use as a daily driver. At some point they were pushing Matrix as the way forward.