penguinduck

Your point? The multiple declaration syntax which is being discussed here uses comma separators, not operators.

Maybe you don't understand it that well because the described usage of a comma is not a comma operator (or any kind of operator).

You wrote a program that rigs the input data in favor of one class in such a way that the classifier results are more or less uncorrelated with membership in that class. Am I understanding the code correctly?

I don't see how you eliminated "human biases present in the data annotations" here. It seems like your program merely rigs the input in order to get the kind of output you like to see.

Obviously you can tamper with the data to get any kind of result you want. You can force equal outcomes for "Never-worked" and "Private" but that doesn't mean you're removing some inherent bias in the original data.

Also, this sentence:

> All of this excludes the fact that companies will probably maximise to profit, and will use "algorithm" as an excuse to turn down people disregarding ethics.

is kind of weird in the context of your comment and program. If you are correct in your fears of biased data, then accounting for the bias in the data maximizes profit for the companies. Ethics shouldn't be necessary if it's just about bias in the input data.

Some systems will scan the email content and try to guess the password; if they can't, they'll block the attachment.

But for such a user the choice is not third-party AV or nothing - Windows comes with AV software - so the true benefit of an AV product is only in how much better it is than the integrated one. That difference needs to be more significant than the product's drawbacks AND price.

The more a person wants to do a job, the less compensation they will demand because the emotional satisfaction they get substitutes for a part (or sometimes all) of the compensation. When there are a lot of people who have a strong preference for doing a job in a particular industry, they collectively drive down the price of their own labor into the ground.

Companies will only pay what they have to.

Some examples of industries where tons of people work for shit money (less than a person of their abilities could earn in other industries) or even sometimes for free because of an emotional attachment to that industry are showbusiness, art and academia.

Then you have the opposite examples, like working on an oil platform - most of those people would earn less money if they had picked a different industry, because they have to be paid more to agree to live on an oil platform and do a shitty and dangerous job.

It is a strawman. Your quotes don't say what the author wrote: "the less someone knows about a subject, the more they think they know". And again later: "In two of the four cases, there’s an obvious positive correlation between perceived skill and actual skill, which is the opposite of the pop-sci conception of Dunning-Kruger." He is specifically talking about an expectation of an inverted relationship - a negative correlation - and his whole argument is based on that.

By his definition, the "meme" would mean people believe that those who are among the worst in the world at something would estimate their ability the highest, and those who are among the best would estimate their ability the lowest (on average).

Do you really think people believe this? That olympic gold medalist swimmers would put themselves in the first percentile of fastest swimmers, while people who've never entered water would put themselves in the 99th (well, not necessarily 1st and 99th - maybe it's 3rd and 97th, but the medalists would choose the lowest number, and the non-swimmers the highest)? I don't think I know a single person who believes this.

I have huge respect for Dan Luu but he screwed up here and created a classic strawman.

Terrible speaker basically spouting nonsense.

It's not a bug by definition of what contracts are. A contract can't have a bug because the implementation IS the specification. That is the whole point of the system. Even the DAO website says so itself. The code itself has the ultimate say:

> Any and all explanatory terms or descriptions are merely offered for educational purposes and do not supercede or modify the express terms of The DAO’s code set forth on the blockchain; to the extent you believe there to be any conflict or discrepancy between the descriptions offered here and the functionality of The DAO’s code at 0xbb9bc244d798123fde783fcc1c72d3bb8c189413, The DAO’s code controls and sets forth all terms of The DAO Creation.

Nobody should have entered this contract if they disagree with the above. Yet now, suddenly most people who are a part of it seem to disagree with it!

Are you sure the compression rate will be higher than what humans have experienced previously? We've had steam power, electricity, computers (and I probably forgot something). Those were all pretty big. The current big thing is AI. What reason is there to believe that AI will have a stronger effect than those have had? So far, it hasn't had a particularly strong effect. Automating jobs in various fields is not going to be a 2-year process. It will take decades. So the rate might not actually be that high.

And about your Foxconn example: if you look here [1] you will see why they were able to do that. Notice the vast disparity in employee numbers between them and, for example, Samsung. It is likely that Foxconn is far behind the industry when it comes to automation (probably due to access to cheap Chinese labor), and when you're behind, it's easy to make such big leaps.

[1]https://en.wikipedia.org/wiki/List_of_the_largest_informatio...

There is nothing magical about a "connection". It is not some kind of secure tunnel. There are only packets. The attacker can take part in the accepted connection that the legitimate host initiated and the server accepted, and pretend to be the server to the client and pretend to be the client to the server, as long as he has the sequence numbers, which he gets from passive sniffing.

There is no need for a subsequent connection.

It is irrelevant whether the legitimate client connects or the attacker does if the attacker is sniffing traffic. This is just how IP and TCP work.

If I am sniffing traffic, I can fool the server into thinking I am the client and do what I want, while fooling the client into thinking I am the server and make him happily drop the connection after he sent the initial packet I needed to find out the port.

Basically, in IP protocol you can say you are any IP address you want in your packet. There is no way for the receiver to tell whether you're lying[1]. Then TCP introduces sequence numbers -> if I say I am 1.1.1.1, but I am actually 2.2.2.2, the server will send a sequence number to 1.1.1.1, and expect that number + 1 in response, but as I am not 1.1.1.1 I will not receive his sequence number and be unable to reply with number + 1 - I don't know the number. However, if I am sniffing traffic, I will see the sequence number he sent to 1.1.1.1 anyway, and I will correctly reply with number + 1 while continuing to lie I am 1.1.1.1. So it makes no difference to the attacker whether the server is talking to 1.1.1.1 or 2.2.2.2 (attacker's IP) as long as he can sniff traffic. It also makes no difference whether the legitimate client initiated the connection or the attacker did. It is just packets, it doesn't matter who sent them.

I am not sure if I am understanding what you're asking correctly. Basically, you don't need MITM capability to pretend you're a different IP than you are. Lying about your IP is a basic feature of the IP protocol. And if you are sniffing traffic, it is also not in any way prevented by TCP.

[1] except in special cases when the sender claims something clearly impossible, like claiming to be an IP from a different interface (claiming to be 127.0.0.1 for example) than the one the packet was received on

You don't need to be able to do a full MITM attack. You just need to be able to read the traffic, not modify it.

And if you believe this is an unreasonable assumption, why did you link me a program which says in its description "The problem with the original concept was that if your port sequence was observed by passive eavesdropping, it was easily replayable." ? It tries to solve this exact problem - a sniffing attacker.

I am just explaining why this program fails to solve the problem you claimed it solved in your original reply. Surely you can understand that.

I don't understand what you mean. How would you prevent the attacker from knowing the port, except by only sending the port knock, and then never actually connecting?

Let's say the attacker has no idea you're using port knocking and even somehow missed your port knock packet completely, but after that captures subsequent traffic. He will still see the sequence numbers in the SYN/ACK from the server which is all he needs. Once he has that, he is an equal party to you (the legitimate client) in that connection.

Entirely possible, as I said this is the first time I read about this, so the port knocking I refer to is the kind described, which is using a sequence of ports as a key.

I don't know python but this implementation seems broken in the same way (or more precisely, under the same circumstances). I just realized, you don't even need to copy the knock. If you have access to the network traffic (which you would need to copy the knock in the first place), you also have access to the TCP sequence numbers. You can just connect from the user's IP after he performs the knock, or even let him connect and inject packets at some later point. This program seems to rely on the TCP authentication of IP address which is completely negated if the attacker can monitor traffic.

Am I misunderstanding how this program works?

Now you are being intentionally obtuse. Bye.

I can copy your knock and get access, I can deny you service by messing up your knocks by sending packets with a fake IP, it is also insanely inefficient in the amount of data and time spent vs the amount of information exchanged

Could you explain why single-packet authorization is cosmetic? This is the first time I've read about these, and while port knocking is clearly broken in multiple ways, I don't immediately see the flaw in SPA, except for the fact that storing hashes of previous packets and comparing against them is inelegant.

Regarding the first, I think they basically do this to test how "programming smart" someone is. Like my boss tells me when I interview, "determine potential". However, I agree that this shouldn't disqualify someone for a more technical kind of job. For me it is more of a "if he is really smart we should hire him despite the fact he is perhaps unqualified, he will easily learn" thing. The disqualifying questions are easier than this one.

Regarding the second, I agree completely. This problem is good because it doesn't give an advantage to rote memorization of basic CS from college (unlike asking about red-black trees etc), but when stolen from the internet and reused becomes bad because it gives an advantage to something worse - googling questions and memorizing answers.

I assume (or hope) Google switches up the problems they use all the time and hopefully doesn't use automated testing (because I care how someone thinks, not just whether they produce the solution in X minutes), but since you interviewed at a different company perhaps it is a cargo cult effect: Google has some of the smartest programmers and they asked this, so obviously we should also ask the same thing! Cargo culting is extremely common in IT in less-established companies, my workplace is not immune to it either. Pick things a super-successful company does that require almost zero investment, effort or true change, and copy those. It is ridiculous.

Of course, the things these companies really do right, they are too much effort, let's just copy them in superficial ways and hope for the best!

Newspapers can be extremely unreadable though for this exact reason. They often use 30 character columns, then have an article consisting of 5 or more such columns of text. I often "get lost in the sentence" when reading this format and have to backtrack. It would be interesting to know why they do this. It is definitely not readability.

I think on a mental level, the problem is that when the lines are this short, the grammar is extremely broken up, so you need to "cache" 4-5 lines of context to understand anything. When it's 80 per line, lines are parsed in a more independent fashion.

I think 70-100 is perfect, depending on other factors.

Screenshot of what I mean: http://www.trbimg.com/img-5667d3f6/turbine/la-la-na-menace02...

You dismiss this as "esoteric", but that's the whole point, the purpose of a puzzle like this is for you to be unable to map it to something you've done previously or to something you learned in school, and instead to force you to invent an algorithm on your own.

It is the opposite of what the author of the article complains about - "academic", "targeted at cs grads" - it goes against that. It is an attempt to test problem-solving ability by removing knowledge from the equation. Knowledge can then be tested separately. Fresh CS grads are not going to do better on this problem than a guy who graduated 10 years ago.

In fact, this is the kind of problem given to children (who can't be expected to have CS knowledge, and you don't want to give a big advantage to those who happen to have some) in programming competitions. I would put the difficulty at either easy problem for high schoolers or difficult problem for elementary schoolers (this doesn't mean it's super-easy, these problems have to be relatively hard or the smartest kids would all solve everything).

I am not sure why so many developers dismiss the value of this and are in fact often actively hostile to any suggestion that it might be ONE of the indicators of programming ability.

I do agree that the time constraint was probably too strict and favors people who've solved stuff like this before, mainly due to them knowing they should try to solve this with a pen and paper or in their head, then just code the solution once they've found it. Trial and error through code is a huge waste of time and this was probably your problem.