True, however they should be very well compressible by 'deflate' too, the main concern is the initial parsing grok by the JIT.
Yet, on runtime the scripts will be good as any.
The different modes (actually 3 in vi, and 6 in vim) recognise that you need different functionality when doing different things. If you are just writing, you don't need to have edit functionality, if you are reading you need advanced movement, and you don't need all of this other stuff when you are entering a complex command.
It is a completely different way of working, but when you realise that you spend most of your time coding not writing, you can see that spending a lot of time in normal mode, with your keys now doing useful stuff, can save a lot of keypresses.
Of course, I'm not saying that vi is perfect, and if emacs works for you, then there's really no reason to switch, unless you want to try it out for funs.
On a macro level, I agree. But switching mode isn't so hard that you have to sit twenty minutes in normal mode, thinking what you would do in the entire document, before you switch to writing it.
Even though I'm a very 'mixed' type of writer/coder, I find normal mode very useful because moving around in the document, for me, is much faster that way.
So even if I only have to move x words to the left, delete until the first occurrence of character y, or change the text inside the very next quotation marks (one of my favorite tricks), the 'hassle' of switching between modes is worth the ease of moving around the document. In the few cases where I need to do something even more trivial, I can still navigate the 'regular' way in insert mode.
Furthermore, I find that I generally work better if I don't just rapidly and constantly switch (mental) modes, even for prose. I'm starting to feel my 'instant' connection to the output makes me sloppier and makes it harder for me to reason about what I'm exactly trying to do. So for me it even has a psychological benefit to use an editor that has modes.
It works out in practice that you have vi-like modes in emacs. When you hold control down you are in one mode and when you hold Meta down you are in another mode. The difference is state. In vi you have to remember which mode you are in. In emacs you know by which modifier you are holding down. The issue of compossabity is orthogonal.
For example in emacs you can move around, cut, paste, do minor manipulations like swapping words or case all while holding control down. When you want to enter text you let up.
For me, I was used to mainstream text editors that use modifier keys. I found vi difficult to get into, but I finally grokked it when I considered 'normal' mode to be affected by an imaginary key called 'ctrl-lock'. Like numlock and capslock, ctrl-lock keeps your modifier key 'held down'. It's not quite accurate, but it was the conceptual shift I needed to 'get it'. Also, you don't have to remember which mode you're in in modern vi clones, as they generally tell you in the status line. Not that you particularly need it, because when you're comfortable with any editor, you have a practiced set of moves that you don't have to think about.
Now I'm not a vim god, but I've used it enough that I have muscle memory that affects my use at the command line - I'll want to change something in a parenthesis and will type "ci(" (change inside parenthesis), only to find the literal characters appear... :)
Exactly. And since I recently mapped 'normal' mode to the Caps Lock key, it's even easier. I did this because I was forced to use a keyboard that had no ESC key, but it's been very useful with vim.
In vim, you can still move the cursor around when in insert mode. It just isn't that functional and after a while you realize it rather is a beginner's mistake. Anyway, those modes aren't totally separated from each other. There also are shortcuts to quickly do something in another mode.
Having used emacs and vim for several years, I now am in favour of vim's editing modes. The only thing I don't like about it is the column numbering at the first or last position of the line (a problem you become only aware of when developing plugins though).
So in some sense there are two major features of vim, one being the composable commands, and the other being the modal editing. They seem to not necessarily be related, for example there's this thing called 'god-mode'[1] for emacs which is kind of like vim's normal mode, and control becomes implicit. I haven't gotten a chance to really adapt to using it but it seems like it could bring a lot of the benefit of vim's shorter syntax to emacs users without requiring us to change our muscle memory with regards to the key sequences.
What I got from it, while not a conclusive answer, was that because of the historical ban for anyone but the royal to eat swan, there is no tradition anywhere in the western world for it. Also people don't like to eat "cute" animals, like seals or squirrels. And lastly, when something is classified as a pest, people don't want to think of it on their dining room table.
While the article doesn't explicitly say the exact reason why, I think these were the main points. So I guess that is badly formatting on the article writers side.
But the premise is already weird. Who is "We" as in "Why don't we eat swans"? And who considers swans 'cute'?
I mean, I consider cats cute, lots of people consider dogs cute - and both animals are eaten in this world. Better example: Horses are cherished as companions and pets for some people and I _regularly_ like to eat them. There's even a dish local to the Rhine area in Germany [1] that (used to, it is replaced by beef quite often by now) is based on horse meat.
People tend to love dolphins. Asian cultures eat them. "They are cute" is not an argument here. That might explain a bias, but not why there's (according to the article) no swan to be found on any menu?
"We" would presumably be the types of people who read the magazine. According to the about, that would be:
"window-herb growers, career farmers, people who have chickens, people who want to have chickens and anyone who wants to know more about how food reaches their plate"
and given the staff members are all US oriented, it's most likely assuming a US readership and US food culture.
Thus we, who are random fly-by strangers to the magazine, shouldn't really criticize harshly when they don't take an unexpected audience into account.
If their goal was to bury it in mediocrity, I think that would be a good strategy. But I think their goal is to bring attention to a movie that distorted history in a meaningful way, then down-voting it is a pretty effective strategy. If you can down-vote it to the level where it has the worst score in the IMBD, or even among the ten lowest, it attracts attention and goads curiosity about what makes the movie so awful, which leads people to Google it and quickly find information about this social movement.
It is wrong because it is the toString of Object, because the + operator wants to do string concatenation. You were misleading the audience, both by using a shell which doesn't show strings with quotes, and saying that the toString of the object is 'just an object'.
And that is not the only thing that is misleading, as you clealy said that {} was an object. Yes, the syntax in js is weird as it looks like an object, but it isn't. Again, a better shell would not let you do this.
As gary explained he wasn't wrong in his response to the question because the audience member was asking whether [object Object] means the object is in an array. It doesn't. The string point is moot.
I do agree the {} + [] example has always felt a bit unfair to me (for the reason that {} is a block), but whatever, it's a light-hearted talk.
From all I read Taxi business in Berlin is already a highly competitive market with low margin and low salaries for the drivers. I think this market does not need a downward spiral. Granted, my sources (taxi driver blogs) may be biased.
So you trust the taxi drivers to tell you if their industry is "competitive enough"? Brb, I have to go ask comcast if the cable industry is competitive enough.
There is no such thing as too much competition. Increased competition always has a net positive effect. Comcast and the taxi industry may suffer, but society will benefit.
This does not go into the Web of Trust and having your key signed, maybe the most complicated part of PGP, and perhaps also its most important feature.
Specifically "check a signature". Even everyone that knows how to sign fail to really check anything. Honestly, if it aint boiled down to a green or red icon then people are going to misuse, assume security when its not, or just click "yes".
If you get a new public key for someone, and it's signed by someone else you don't know (most of the time this is the case) are you going to bother to utilise that signature to increase the trust? No. Are you going to assume increased trust somehow regardless? Yes. FAIL.
Modify it further, if it is signed by someone you do know what are the chances your UI is going to give you any sort of indication that this is more trusted that other message workflows? And if it doesn't give you any indication (most leave it up to you to check) who's gonna bother to look just passed "your friend <yourfiendsname@company>" ASCII and actually check the key? no one. FAIL.
I use PGP extensively. However, I haven't bothered with the web of trust, for the same reason I don't publish my address book for everyone to read, privacy.
I have already run into this at work. I have customers whose keys are publicly available, and others who should not be, and so I cannot effectively use keysigning internally to manage relationships. This is because I don't want to upload every key I know about to a public keyserver.
Maybe I am mistaken or maybe there's a way to do that without having multiple keyrings or something, but that's kind of the problem. It's really hard to tell what I would or would not be sharing because there's no "interface" to speak of and I am hardly an expert.
btw, how is a person signing a key in the usual WoT model supposed to know whether or not the email address specified in the key uid is actually controlled by the person standing in front of them at the key signing party with passport and key fingerprint in hand? Even if you carefully follow the recommended key signing procedure the binding which actually matters for exchanging encrypted email has very poor validation (or none at all).
If you only meant verifying the email as apart of a keysigning party, agreed. Meaning you are looking at their passport and sending an email at the same time. This is better than nothing but wont protect against many directed attacks. For instance, a journalists has to be more careful. Also, in the end if you are sitting in front of each other might as well just verify key fingerprints. Better privacy and security than a simple email verification.
If the author meant actually sending someone a email to see that it is indeed owned by them remotely: NO WAY. Does not work:
me: "hey, just sending you an email to confirm its really you before sending the secret plans?"
them: "yeah, its me. send the plans."
That is exactly what WoT tries to solve but can't due to misuse.
I think you misunderstand. After meeting someone and exchanging public key fingerprints, you verify their identity. This requires checking their government ID and making sure they really are who they say they are. Then, you verify the uid of their key by sending them a message encrypted with the figerprint you received in person. Only the holder of both that key and the email address can respond to your message. Then you can sign their public key and return it to them.
What kind of attacks is this practice vulnerable to?
> What kind of attacks is this practice vulnerable to?
I want to pretend to control target@example.com and the legitimate owner of this address is an OpenPGP user who has published a keyring on the public keyservers.
1) I create a keyring and add a single uid with my real name and target@example.com
2) I download the public keyring for the legitimate user target@example.com and extract the encryption subkey.
3) Even though I don't know the private key I can add this public key as the encryption subkey to the keyring created in step #1.
4) I publish this keyring on the public keyservers so that you will find it by querying the fingerprint I give you when we meet.
5) You send email to the real user target@example.com which they are able to decrypt and respond to. Of course there could be some confusion since the real user is not expecting an email which presumably talks about verifying keys.
6) Since the mail was decrypted and responded to, you sign the key and return it to me.
7) I revoke the certification on the encryption subkey I borrowed from the real user and add a new encryption key which I create.
8) People who trust your signature encrypt mail to target@example.com with the false key I've published.
> What kind of attacks is this practice vulnerable to?
So long as the trust only translates to the very limited use cases then there is no vulnerability. Those limits basically mean that no trust should be assumed by anyone that did not participate in the WoT in question. This particular style of WoT means anyone wanting to retain anonymity needs to skip it, or am i missing something?
Mainly I think all WoT models i've seen thus far are too susceptible to sybil attacks (impersonation) and as a result instill bad habits.
you only need to look at people use of pgp today to see how much WoT's would be a failure if used. pgp.mit.edu still aint got ssl. journalists are linking to nonssl links for their key via twitter t.to urls
