315 karma · joined September 24, 2011
[ my public key: https://keybase.io/piscisaureus; my proof: https://keybase.io/piscisaureus/sigs/zdHClRr-vymlpfMU1FOU6CzWWvT03cmSF_KVfvZU5RQ ]
I tried two phone numbers: my primary cell phone number gets a great 800+ score but reveals an accurate address history of 9 years.
The second one gets a poor score (415), but none of the data is accurate. Have fun: https://gist.github.com/piscisaureus/03d5ebeeb3e77922a858464....
It may be a matter of knowing when to stop. My personal experience is that most people will try to answer even sensitive questions when you approach them with genuine interest and make some effort to formulate questions in a way that doesn't imply some sort of value judgement. If this is difficult, just be explicit and explicitly say you're not trying to judge or offend them.
Sure enough, you'll hear people make an argument that you find unconvincing, or they may not answer the exact question that you asked, and some people will even admit they don't know why they believe something. When that happens, you'll have to accept that as their answer (and draw your own conclusions in silence).
People do get hostile when you keep "nagging" - asking more and more questions - when it's clear that they aren't interested in the subject or haven't thought about it much. To the other person it feels like you're either trying to make them feel stupid or change their mind. And you're getting none the wiser anyway because those who do not get offended will just make up their "reasons" on the spot.
Obviously avoid the mistake to ask someone for their opinion, and then immediately returning the "favor" by giving your opinion on the matter.
The concept is not so unique as you might think tho; the more commonly used term is "tail call".
We expect to support that in a future release.
But unlike most patches that draw a similar response it's not a narrowly useful patch that mostly serves the submitter. Proper NTFS support benefits a large proportion of Linux users (the jab from the article that there are more advanced file systems out there seems out of place; there are no signs that windows is about to switch its default FS to something else).
Additionally this code has been used in production for years now (e.g. my 2015 router runs the closed source version of this driver in order to support NTFS formatted external drives) so most likely a lot of quality issues have already been found and addressed.
So I feel it's a bit unreasonable to respond with so much negativity to this contribution.
... in the US.
In the EU and UK there is separate copyright-like legislation that covers this, so-called "database rights".
(No affiliation to the author)
But kidding aside, how long are these batteries really supposed to last?
I wonder about ulterior motives too.
But in a world where even local apps increasingly try to make me store files in the cloud, I can only consider this as a move in the right direction.
All web apps can offer today is either (1) re-download the file (as the article mentions) or (2) save to GDrive/iCloud /OneDrive.
Working with local files is a win for user freedom.
(I'm not affiliated with them in any way)
Call this overlapped-poll function on every monitored socket individually so you don't inherit poll()s scalability problems.
See https://github.com/piscisaureus/wepoll/blob/437fb2f24ce197b4...
This is as much of an explanation I can type on my phone - I'll add more detail to the wepoll readme later.
Later I discovered that it is possible to do efficient epoll emulation on windows so then I wrote wepoll. With it you can just stick to the good ol' epoll/kqueue model and still support windows.
My big beef with it is that it tries to force feed me Bing wherever it can (even after switching the default search engine). That's a big no-no.
As far as I remember, we were never so much against the idea of it, but we didn't believe an actually good implementation was possible.
The primary concern was scalability. At the time supporting high concurrency networking (10K+ connected clients) was a top priority for us.
The solutions proposed by Laverdet and Jouhier used libcoro or fibers to achieve the desired "cooperative threading"; this may not involve actual OS threads but it does require the creation of a thread stack for every fiber. To handle 10K connections you would need 10K stacks so you have to allocate 40GB memory right there, too much.
We were aware that there were more effectient ways to do it, but this would have big changes to the V8 javascript engine. We didn't have the resources (nor the skill) to get it done and take on the maintenance burden.
There were also concerns about the surprising language semantics it created; suddenly callbacks might run "inside" a function, e.g. after it's called and before it has returned, not something a javascript user would normally expect to be possible.
Nowadays with async/await the callback-hell problem is actually solvable (to the extent that node-fibers solved it, anyway). It'll take time though before that becomes noticable, because a lot of packages need to change their APIs to take advantage of it.
Which I find to be a very practical solution for connecting to localhost over https, it frees you from having to install a self-signed certificates/CAs on your machine.
What if they'd just ask the user to accept and install a certificate when connecting to a local server for the first time?
- You can't delete the parent directory
- You can't create a new file with the same name
... which makes that flag quite useless.
Yes, it's true that many APIs would theoretically allow kernel-level asynchronous I/O, but in practice the story is not so rosy.
* Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented (https://support.microsoft.com/en-us/kb/156932), but asychronous I/O also actually blocks in cases that are not listed in that article (unless the disk cache is disabled). This is the reason that node.js always uses threads for file i/o.
* For sockets, the downside of the 'completion' model that windows is that the user must pre-allocate a buffer for every socket that it wants to receive data on. Open 10k sockets and allocate a 64k receive buffer for all of them - that adds up quickly. The unix epoll/kqueue/select model is much more memory-efficient.
* Many APIs may support asynchronous operation, but there are blatant omissions too. Try opening a file without blocking, or reading keyboard input.
* Windows has many different notification mechanisms, but none of them are both scalable and work for all types of events. You can use completion ports for files and sockets (the only scalable mechanism), but you need to use events for other stuff (waiting for a process to exit), and a completely different API to retrieve GUI events. That said, unix uses signals in some cases which are also near impossible to get right.
* Windows is overly modal. You can't use asynchronous operations on files that are open in synchronous mode or vice versa. That mode is fixed when the file/pipe/socket is created and can't be changed after the fact. So good luck if a parent process passes you a synchronous pipe for stdout - you must special case for all possible combinations.
* Not to mention that there aren't simple 'read' and 'write' operations that work on different types of I/O streams. Be ready to ReadFileEx(), Recv(), ReadConsoleInput() and whatnot.
IMO the Windows designers got the general idea to support asynchronous I/O right, but they completely messed up all the details.
https://www.google.com.ph/maps/place/23%C2%B047'02.5%22S+35%...
I always assumed that google uses some kind of algorithm to detect land/sea borders, and it messed up.
> But Promises already provide asynchronous try/catch blocks
They do, if all you use is modules that return promises, and the node ecosystem currently has many modules that don't. For example:
zone.create(function MyZone() {
// Within MyZone
setTimeout(function() {
// Within MyZone
throw new Error("Oh noes!");
});
}).catch(function(err) {
// Back in the parent zone.
// Handle the error here.
});
Conversely, with zones, chaining callbacks is hard to define conceptually:
zone.create(function MyZone() {
// In MyZone
}).then(function() {
// Which zone are we in?
}).then(function() {
// Which zone are we in?
});