Hacker Newsnew | past | comments | ask | show | jobs | submit | more theon144's commentslogin

Okay, but your one file type is more likely to be included in the 1600 that libmagic supports rather than Magika's 116?

For that matter, the file types I care about are unfortunately misdetected by Magika (which is also an important point - the `file` command at least gives up and says "data" when it doesn't know, whereas the Magika demo gives a confidently wrong answer).

I don't want to criticize the release because it's not meant to be a production-ready piece of software, and I'm sure the current 116 types isn't a hard limit, but I do understand the parent comment's contention.


>It would be a red flag if you were interviewing for react and decided to bring up vue or svelte or angular or whatever else as well.

...why?

Seriously, why on earth? I don't follow this train of thought at all; if they demonstrate proficiency within the scope of the position, why does it matter if they also happen to know other technologies?

"Oh, Alice? Yeah, she was a great candidate, unfortunately she also had experience in Vue, so there's nothing we could do. We decided to hire Bob, who has 3 years less experience with React, but fortunately that's the only stack he's ever heard of."

If anything, it's a sign the person is interested in learning, most great devs I've met were not proficient only with a single technology. This sounds completely alien to me.


Nice strawman bro.

Nobody is saying to not expand your knowledge. You’re assuming it of this because it’s literally your only argument, but it’s an unfortunately shitty one, as most logical fallacies tend to be.

Nobody said “don’t have wide experience” but you. What I did say was “I’d probably avoid being an ardent fanboy toward an irrelevant to the interview tech stack”. And that “it’s most often best to leave irrelevant digressions to the interviewer”

Again, you go ahead and give out all the shit tier interview advice you like. For people that actually want jobs, probably try to stick to what’s relevant.


You said if someone brought up something like Svelte when interviewing for a React job it would be a red flag. That just sounds silly to people that know how naturally someone could connect Svelte to a discussion about React.

Could I imagine a scenario where it's a non-sequitur? Sure. Not really "don't hire this person" worthy, though.


Just higher than 80Hz should be enough via Nyquist's theorem, or no?


I have no clue as to the I/O requirements of the AGC, but I imagine that with ~500x the performance, a simple I/O expander could fill the gap?


Not sure what you mean; Windows doesn't force mouse acceleration.


>one sr front end dev who started doing $10 mn ARR [...] all by his lonesome

https://en.wikipedia.org/wiki/Survivorship_bias


>I am aware that a number of websites featured in this list rely on operating under obscurity, and that this list could potentially contribute to their demise through excess exposure. I'm sorry about that - I just like making lists.

Well, at least the author is responsible and owns up to being one of the cheaf reasons sites like these die :)


Nah, owning up means suffer the consequences of ones actions, in my opinion he owns up to nothing, he barely says he's sorry, but he doesn't care too much about the consequences, that's quite different if not opposite.


I agree, although he might have to 'own up' if someone found his employer and let them know he's working to enable piracy in his free time.


>The Linux kernel has around 27.8 million lines of code. An increase of .35%

This is horribly misleading; most of these lines of code are drivers, which this patchset doesn't even concern.

It's still a massive change that only a handful of developers will ever be able to review in entirety - a fact to which the size of the project is completely irrelevant - if anything, actually, it urges even more caution, given the implied complexity. Which I believe was (at least in part) parent comment's point - given the importance and ubiquity of the Linux kernel, this may be concerning.

That said, I am very confident in the structures put in place by the kernel devs, their competence and the necessity for such a change - but trivializing a 100k LoC patchset because the project it's intended to land in is even more colossally complex isn't how I'd choose my approach.


> This is horribly misleading; most of these lines of code are drivers, which this patchset doesn't even concern.

That's not true at all, a big part of those added lines are added includes in drivers.

E.g. this commit I picked at random adds 1500 lines, of which just a few procent are in the core kernel: https://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.gi...


And the Wii was different to motion controls of the past, but you don't exactly see that flourish these days.

It's not really about the improvements in technology, rather than the inherent limits in its use cases - there's only so many games and media experiences that truly benefit from VR, and as a rule, they're designed for VR from the beginning.

Without a doubt, VR is a huge leap and a drastically different and exciting medium, but that doesn't mean it's ever going to be more than gimmick worth a couple evenings' entertainment to most people.


AIUI the decision was made via standard procedure (a Request for Comments sub-page), and it was the consensus of the editors (that is, the ominous "they" in your comment) that it is unreliable as a source.

Now there is an obvious need for quality control of accepted sources in a project like Wikipedia, the process was transparent, and its conclusion is up for debate (hence being conducted through a Request for Comments). What would you propose instead?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: