HN user
What you're describing is very similar to Rubber duck debugging. The idea here is that forcing you to explain what you're trying to do makes it easier for you to catch your mistakes.
Nobody is demanding you do. But if you go around claimng people "got phished", then you should be sure.
I've also entered fake credentials into a clearly faked login form to see what'd happen. Would it redirect me to the right site? Just claim the information was wrong? Send me to a mock up of the intranet I was trying to access? You can call it bad policy if you want (although you don't know about my precautions), but it doesn't mean I was phished.
I think you jumbled up the two paragraphs. Nowhere did I suggest that poor audio quality was because Android has to support more hardware.
With fear of starting a fire here, are you using an Android phone?
I'm asking, because whenever I hear people complain about phone software that just breaks, it's almost always Android, and with good reason: They have to support a lot more phones than iOS, and Android is a lot more open.
So I just wanted to air the idea that you could try with an iPhone. iOS may lack some of the feature Android users are used to, but in my experience, it's just more stable, and I don't at all share the sentiment that "phones are unusable" or that the audio quality is bad or anything of the kind. If there's one device I can always count on working, it's my phone.
That's an interesting project and good writeup!
Peer-to-peer OT has indeed been proven wrong many times (I've debunked a few papers myself as well), but client-server-based OT is very solid.
For the last 3 years, I've been the primary developer on Webstrates[1], an open source[2] research project that "makes the DOM collaborative", that is to say, as Google Docs (and your project) makes text editing collaborative (a subset of the DOM), Webstrate aims to make the entire DOM collaborative, allowing developers to easily built collaborative tools (such as text editors).
In fact, I just made a basic editor here (https://demo.webstrates.net/dom-editor/) in about 5 seconds. I just created a new webstrate (a "page" on the server) and added the `contenteditable` attribute to the body element. Of course, it dosen't have any of the rich text editing capabilities of your editor, but that's just a matter of adding more stuff directly in the DOM, e.g. https://demo.webstrates.net/shaggy-elephant-60/?copy.
Through those 3 years, there haven't been any DOM consistency errors caused by issues with the OT algorithm used.
Absolutely nothing wrong with CRDT – it's even on our own agenda to eventually develop a peer-to-peer-basd Webstrates using CRDT. I just wanted to point out that OT is a very viable alternative for client-server applications.
[1] https://webstrates.net/, [2] https://github.com/Webstrates/Webstrates
You may find ShareDB[1] interesting – it's a library that does exactly that.
ShareDB is a realtime database backend based on Operational Transformation (OT) of JSON documents. It is the realtime backend for the DerbyJS web application framework.
And now a selfplug:
We're using ShareDB to create collaborative DOM in Webstrates[2]. The tl;dr is that every DOM change you make gets synchronized to all other connected clients and the document (including full version history of every single DOM change) gets saved.
Creating a collaborative editor in Webstrates is a simple as creating a new webstrate[3], opening Devtools and adding `contenteditable` to the body element.
[1] https://github.com/share/sharedb, [2] https://github.com/Webstrates/Webstrates, [3] https://demo.webstrates.net/frontpage/
Any fake-Facebook website can copy Facebook's favicon, so that wouldn't add any security at all.
An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.
You're absolutely right, but I'd also never suggest a collaborative system for anything critical. As I've said earlier in this thread: If you're in a Google Docs document with a buddy and you write "A" and he writes "B" at the same time, you also don't know whether that'll show up as "AB" or "BA". In practice, this isn't an issue.
I'm not one to dictate how technologies like these are to be used, but all I can say is that in the almost two years I've been working on Webstrates – a collaborative system using a very similar technology – this has not been an issue.
But surely, if you allow malicious actors to modify your document, then that's your problem right there.
We've been wanting to try a CRDT-based implementation with Webstrates for some time, but haven't found a suitable implementation, so this looks very promising!
Any particular reason why you choose CRDT over OT?
Why is that a restriction? You can make any changes to the JSON you wish, you just have to use their API.
There is a change history. No changes are lost.
This isn't for a banking system, this is for building collaborative apps. If you press "A" and your friend press "B" into a Google Docs document at the same time, you also don't know if the document is going to read "AB" or "BA". In practice, this is not an issue.
My experience is with OT, so I can't speak for CRDT, but I can imagine it's similar.
With OT, you send a na[1] (number add) operation, so this would work fine. Indeed, if you treat the number as a string, then you have a problem.
Then there'd be a negative amount of apples. It's not impossible if you disregard context.
There is nothing new about doing things like this, OT and CRDT have existed for ages. Check out ShareDB (https://github.com/share/sharedb) or Webstrates (https://webstrates.net/) (based on ShareDB). In Webstrates, we don't have merge conflicts that need to be resolved and there are never any practical synchronization issues. The server orders the operation and if you try to delete something that's already been deleted, then we just ignore your operation.
Also quite courageous to say something is impossible when you have the code that does it right in front of you. ;-)
Blockbuster shares
I think most places, debts can be inherited voluntarily, but you can't cherry pick.
If your dead aunt had a Mercedes 190SL, but also owes $200,000, you can either take both or nothing.
But yeah – they won't end up in debt themselves, unless they choose to.
William Miller predicted Jesus' return in the year 1843. When that didn't happen, he adjusted his calculations to mean March 21, 1844. When that failed, it became October 22, 1844. He kept modifying his prediction whenever it failed. You'd think being constantly proven wrong would make people stop believing him.
That's how the Seventh-day Adventist Church was started. A church that today has more than 18 million members.
You can't reason people out of something they didn't reason themselves into.
So you do everything you can to hide the IP address, but reveal that the domain is-savvy.nl resolves to it.
Either you're not actually that good at IT security or you're just making a huge brain fart.
$ dig +short is-savvy.nl
37.59.238.165
I was curious, so I wrote a small program to check it:
The normal distribution is
1: 24.9940%
3: 25.0128%
7: 25.0100%
9: 24.9832%
1: 17.0448%
3: 31.0789%
7: 32.1018%
9: 19.7745%
It's a joke. The last digit of a binary number is parity (odd or even). Since all primes (except for the number 2 [or 10 in binary]) are odd, the last digit will of always be 1.
I did not mean to say that HTTPS was a substitute for FTP. You said that FTP was the fastest protocol, and the only reasonable explanation for why FTP could be faster than anything else would be due to the lack of encryption.
Therefore, I asked if you also avoided HTTPS (and only used HTTP), since HTTP clearly is faster than HTTPS.
But if you didn't mean to say that FTP is the fastest due to the lack of encryption, then why do you think FTP is the fastest?
Everything unencrypted will always be faster than the encrypted counterpart. Do you also deliberately avoid HTTPS? And is that minuscule performance gain really worth the risk with FTP?
Why would you assume they wanted FTPS? SFTP is both more common and very superior. Also, what MITM attacks are you afraid of with SFTP?
I absolutely agree. Already after the first sentence, I was questioning whether I was suffering from aphasia or having a stroke. It surprises me that someone would publish an article like that without having proofread it at all.
I still feel like a MacBook Pro would be a good choice for the author. He starts out by talking about being able to replace parts, but later doesn't make that as a requirement when he asks for:
- Decent build quality
- Decent performance and battery life
- A decent website
- A clean OS without crapware or malware factory installed
If you want a laptop that's somewhat thin, light and with decent battery life, you often do have to sacrifice being able to replace anything. By soldering on the RAM and storage, you get more room for batteries. This also especially becomes evident by his System76 Galago that can last 3 hours.
So in conclusion: Just get a MacBook, it has decent build quality, performance, battery life and website. A good OS? I'm not going to be the judge of that, but installing Ubuntu or Windows on a Mac is luckily very easy.
No they can't. That goes against the US antitrust law. Likewise, Coca Cola can't tell a shop that they won't sell them their products if the shop also sells Pepsi.
Good write-up, but damn it that guy has got to learn the difference between "its" and "it's". It's killing me!
i7 3770K, 16GB RAM, 120GB SSD, few TB of storage Hackintosh. OS X Mavericks. 30" Apple (2560x1600) + 2x24" (1920x1200). Java, Python, PHP, JavaScript. Git. IntelliJ, Sublime Text. Debian server. Also a 15" MacBook Pro.
Med student rescues body part? More like German pilot.