They don’t say as much but it appears they’ve been dropped by their payment processor. I have trouble believing they’d invalidate every single card with 5 days notice if they had a choice.
I love these proposals and while it probably makes sense for me to learn more about the languages that already implement it there's no denying that having them in JS is a win. =)
I'm starting to use privacy.com with all my online accounts. If I really have trouble leaving deleting the vendor locked credit card I used to sign up is an easy way to go that gets the job done.
DragonFly belongs to the same class of operating systems
as other BSD-derived systems and Linux. It is based on the
same UNIX ideals and APIs and shares ancestor code with
other BSD operating systems. DragonFly provides an
opportunity for the BSD base to grow in an entirely
different direction from the one taken in the FreeBSD,
NetBSD, and OpenBSD series.
DragonFly includes many useful features that differentiate
it from other operating systems in the same class.
It may be experimental in that it's diverged significantly from FreeBSD, from which it was forked. But experimental does not mean new. Release 1.0 was in July 2004. Apparently the lead developer's experience with the Amiga OS influenced the project to some degree.
Yeah, Dillon (lead developer) forked FreeBSD 4 over (at least) a dispute in how SMP should be implemented. (FreeBSD 5 was the first release to support SMP.) DragonFlyBSD => DFBSD => Dillon's FreeBSD.
I recall back then Dillon had some unconventional ideas how to do SMP compared to the traditional approach of ever more fine-grained locking as done by FreeBSD and Linux. Is DragonFlyBSD still following this design, and if so, how well did it work out, or if not, did they revert to a more traditional approach?
Google tells me that this is a fork of FreeBSD from some years ago, and that there is some desktop support and some degree of support for laptops, especially Thinkpads from a few years ago.
I'v tried it in the past because of Hammer storage (please do not call it fs), hw support at that time was far from good and desktop usability is reasonably low (though not much lower than {Open,Net}BSD) but without counting cluster's hammer by itself it's simply the storage we desperately need.
Think of a zfs log-structured instead of offer only snapshots. This means a complete protection against any accidental delete/overwrite since any write on disk create a new "checkpoint" and with proper file manager integration this means you can "browse history" of your's files and trees like they came from a VCS software.
So I could recover previously saved versions of e.g. a word-processing file? Used to use that back per-millennium on a Novel network with shared drives and it was very useful indeed. I've always wondered why that feature wasn't available in later systems.
Yes and not only, you can see file history, just like commit history in git&c, you can compute diff on-the-fly both for single file and entire trees, you can "undo" last write etc
There is zero filemanager integration, so only manual CLI operation with a UI a bit less comfortable than zfs, encryption have few limitations, physical volume management does not offer "built-in raids implementation" of zfs (but you can create volume on top of any supported raid config), deduplication is a bit resource intensive, replication is not clustered even if you can "mirror" (incremental mirrors included) any volume locally or on a remote machine in a way similar to zfs one...
Essentially is a zfs with a raw and a bit less intuitive UI with logfs and few nice extras.
Yep, I mean compared to zfs live dedup it use less ram but generate an I/O load similar to a full resilvering... In that sense from my point of view it's "intensive", however consider that I only play with it, I do not have a solid idea on how it can be in real world scenarios...
This is all accurate. It's a FreeBSD 4 fork that targets amd64 exclusively. (The latest FreeBSD release is 12.0.)
That's not to say it is stale or anything like that; the BSDs share quite a bit of code heavily thanks to the license. And DFBSD has some novel things that FreeBSD does not have: in particular the SMP model is still distinct; they have the novel HAMMER filesystem, which no other operating system has; and they lead FreeBSD on DRM graphics drivers porting from Linux and non-uniform NUMA support (i.e., Threadripper 2990WX). There are certainly other things I am forgetting or simply don't know about; I develop FreeBSD and don't use Dragonfly myself.
A more interesting definition is that a server is something that is asymmetric from a client. Things that are peer to peer which are symmetric to each other are something special.
While you can frame peer-to-peer interactions as as a series of server-client interactions with servers and clients swapping roles... you shouldn't. It's a different paradigm with different implications.
Individual transactions might be usefully described as server-client, but the overall system is not server based. So...serverless.
In all cases, one node must send the first packet. The node sending the packet is the client, and the destination of the packet is the server.
Also, the internet is a peer-to-peer system. But "peer-to-peer" is an abstract paradigm, because ultimately, (a) two peers need to know about each other, and (b) one peer needs to initiate every transaction.
I realize we're just arguing semantics here, and I'm not sure what point I'm trying to make, but it's an interesting discussion nonetheless...
> In all cases, one node must send the first packet. The node sending the packet is the client, and the destination of the packet is the server.
I'm pretty sure you are just making up new definitions. It's kinda like saying that whoever says the first word in class is the teacher and the rest are student.
The fact is that both peers send packets and the first packet isn't particularly significant, except from a stateful connection or firewall perspective.
> Clients therefore initiate communication sessions with servers which await incoming requests.
Dogs walk on four feet, therefore anything that walks on four feet is a dog?
> Both client-server and master-slave are regarded as sub-categories of distributed peer-to-peer systems.
Dogs are canids, that doesn't mean all canids are dogs.
The client-server model really entails more than having one party that sends a packet before the other. Some illuminating details and a shallow comparison to the peer-to-peer architecture can be found in the article you linked.
Serverless as 3) An application which run on a network and communicate with others on an equal status, you cannot distinguish one node from the others based on the source code or the logic it is running. In a sense even amazon serverless platform is not server less but it is server lite.
.. which have client and server parts of the protocol, that can be separately disabled. The fact that same piece of software can run on in client mode and in server mode is irrelevant.
In bittorrent example, the seeders are pure servers, and those cheating aps which only connect to seeds are pure clients. Yes, many trackers actively try to detect and discourage pure clients, but this is not enforced by the protocol itself.
I was having an argument over 1password's 2fa support not being a second factor. (I don't think it is.) However, it is so much safer than not using 2fa. In similar terms U2F is amazing and keeps you from being phished and has a great challenge/response protocol, if that was implemented in 1password (or browsers themselves thank you!) we'd all be a lot safer than not using it at all.
In 2018 I'm using an app to take screenshots of QR codes to generate one time codes. It's a sad state of the art, we need to do better.
Afaiu 2fa primarily protects from password leaks on the part of the service and coincidentally some other kinds of leaks such as keylogging. Not so much from data theft on the user's side.
A different question, though, is whether a password keeper web service could leak passwords like any other service.
> Afaiu 2fa primarily protects from password leaks on the part of the service and coincidentally some other kinds of leaks such as keylogging. Not so much from data theft on the user's side.
2FA is meant to protect primarily against phishing. It happens to protect against some other attacks as well, but phishing is the primary motivation.
That's why physical U2F devices are considered the gold standard of authentication today - it's possible to phish a TOTP code, but it's very difficult to phish a U2F signature, and impossible to do so through a scalable, automated attack.
This is not true. 1Password could have a breach which exposes your master password. A hacker would then have access to your passwords, but not your 2fa. Even if you do not keep these items physically separated like a hardware token, it makes complete sense to have them be in different applications. For example, passwords in 1Password and tokens stored in Authy.
Faked and discovered to include fake reactions that were then removed, are different situations. Mark has been producing high quality educational and entertaining videos that encourage kids to get into science. I have personally watched kids go nuts over his Fluidized air bed experiments, and convince their parents to try it out. https://www.youtube.com/watch?v=My4RA5I0FKs
It sucks there was fake content in there, but the device was real and the fake actions removed.
I'm a bit more miffed that he didn't make it very clear he didn't create the device. I enjoyed watching the video of the guy who did, but I only got to watch that video because somebody in the last HN thread recommended it.
and have generateStats and mergeGraphStats be async functions and not have to worry about error handling and pushing more than one object at a time in a read stream. We use it to process billions of events and objects a day. It makes nodejs streams fun to use.
Pretty cool. Could the following be used as a baseline to create the same functionality?
async function * nextStreamEntry() {
while(true){
const entry = yield;
const result = await processEntry(entry);
}
}
// Initialize the iterator
const iter = nextStreamEntry();
iter.next();
// For every entry of the stream
for (const monster of results) {
iter.next(monster)
}
I would love to, but not all node versions and not all streams support async iteration yet! Also theres is a lot of utility to some of the stream types in bluestream. Concurrency for one thing. I've been working on an async iterator version of this but haven't yet started using it in production yet.
