It's both, actually! https://huggingface.co/docs/transformers/en/model_doc/bart
HN user
Pneumaticat
home: https://kliu.io twitter: @kliu128
Thanks everyone for the feedback on Yubikeys being stolen! I've tried to summarize it all in a footnote, and downgraded the severity of my original starting paragraph. Thanks for reading!
Yeah - here, I'll add a slight edit to the post to explain it in more detail and clear up any confusion.
Author of the post here - you have a good point with regard to SSH/GPG. (I do have a PIN on my keys.) I was targeting more the U2F standpoint - as in if you're using it for 2FA, it's obviously no better than a password if someone else can just press the little yellow button :)
Thanks for reading, though, and for commenting!
F-Droid [1] has addressed this pretty well for Android devices.
Hey guys, thanks for all the comments! I realized that it was not an ethical idea to post, so I decided to take it down. I did not get a cease and desist, but I would appreciate if you could refrain from reposting it.
If you are interested in seeing some of my other (more ethical) work, check out Delphus [1], an open research study management platform which I am working on at my new startup ;)
[1] https://delph.us
But iodine [1] is very slow ;) (Also with the satellite roundtrip, it probably would've worked, but super slowly.)
A good point. To be fair, though, even Lifehacker has posted a similar writeup [1] (linked in the article) and I don't think they've been threatened.
Getting caught in the air - now, that's a different story ;)
[1] https://lifehacker.com/get-free-unlimited-wi-fi-on-flights-a...
Thanks! Let me see if I can add an mspaint diagram.
edit: added! try refreshing if you don't see it.
Thank you! I suspect the answer is "most", especially if they allow HTTPS in any way. The way to solve this issue is to either whitelist IPs/host the site internally on the local network (e.g. most captive portals).
We're actually trying to do something very similar at https://delph.us.
We also have operational encryption, multi-researcher studies, and soon an end-to-end encrypted chat system between researchers and participants using Matrix.
FYI, AppImages do not run anywhere. There are a lot of issues with them in NixOS, since NixOS is all about having explicitly-linked dependencies, and AppImages still often have implicit dependencies that aren't in the image itself, since they are assumed to exist on the host system.
See https://github.com/NixOS/nixpkgs/pull/51060 for an example.
At least from my perspective (I've never implemented the spec), I wouldn't call it just documentation [1]. Sure, there are likely some holes, but overall it seems like they've put a pretty good-faith effort into making it detailed enough for someone to implement.
I feel like the difficulty comes mainly from the breadth/size of the spec. Which is a major issue (the Matrix.org team's own alternative server, Dendrite, has been slow to progress as well), but ultimately I'm not sure what they can really do about that considering one of their key tenets is to contain all the functionality out-of-the-box, so to speak (no extensions like XMPP).
Matrix isn't really hostile to competing server implementations. If it were, then they wouldn't have spent a long time and a lot of effort to finalize the Server-to-Server spec r0.1, which anyone can implement [1].
And just to add my personal anecdote, Matthew (CEO of New Vector, co-founder of Matrix.org) is present quite often in the Matrix HQ chat room, and willing to field questions from anyone. Perhaps with slightly less willingness when people start such accusations.
Also, to address some of the technical issues, I think what they're talking about as "The blocks have hashes but their implementation does not check the hash" in the DAG is being fixed with the next (v3) room version [2]. Again, this development is all being done in public: see e.g. https://github.com/matrix-org/matrix-doc/pull/1659 for the v3 room proposal.
[1] https://matrix.org/blog/2019/02/04/matrix-at-fosdem-2019/ [2]: https://matrix.org/docs/spec/rooms/v3.html
According to the LizardFS whitepaper [1], the chunks can be up to 64 MB. So I believe if the file is smaller, the chunk is just as large as necessary.
Looking at some chunk files on my system backs this up:
root@rem> ls -l | head
total 11702880
-rw-r----- 1 mfs mfs 33558528 Dec 12 18:17 chunk_ec_1_of_2_1_000000000000010C_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:12 chunk_ec_1_of_2_1_0000000000000179_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:11 chunk_ec_1_of_2_1_0000000000000187_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:26 chunk_ec_1_of_2_1_0000000000000194_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:06 chunk_ec_1_of_2_1_0000000000000197_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:36 chunk_ec_1_of_2_1_00000000000001A1_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:03 chunk_ec_1_of_2_1_00000000000001CE_00000001.mfs
-rw-r----- 1 mfs mfs 69632 Dec 12 18:13 chunk_ec_1_of_2_1_00000000000001D4_00000001.mfs
-rw-r----- 1 mfs mfs 135168 Dec 12 18:05 chunk_ec_1_of_2_1_0000000000000217_00000001.mfs
As for illumos/SmartOS -- maybe? The LizardFS cookbook [2] has a section for illumos, but there's nothing in it. It should probably work (it's C++), but there is probably going to have to be manual effort involved.Our motivation came primarily from the firsthand experience of the sister of one of our cofounders; as a researcher conducting trials herself, she saw the inefficiency and bureaucracy involved in managing them.
We are also concerned about scientific reproducibility as a whole, as well as data alteration. For example, even large companies like GlaxoSmithKline [0] have been caught tampering with clinical data, and the effects for those taking the drugs can be deadly.
We believe Delphus can solve these issues, giving patients more transparency and trust in the research they participate in.
[0] https://www.nytimes.com/2012/07/03/business/glaxosmithkline-...
Hey, I would love to write a tool to manage this! Do you have any documentation on how to access the TI chip?
Sounds like Linux-class bugs (e.g. KDE copy/paste not working correctly sometimes[0]).
I guess Windows has lost its advantage of perceived quality.
[0] https://www.reddit.com/r/linux/comments/9a7k2i/psa_on_kde_ne...
How did I not find this one month ago, as I set up a two node hobby cluster?!