skysight-inc/HackerNews huggingface dataset:
Arxiv accidentally created a crackpot filter from apparently a simple semantic classifier along with a count of stop words used in the article, which acts as a very coarse "style" metric.[1] Reasonable-looking crackpot work is usually classified as "general physics" instead of being rejected entirely. Unfortunately it also lumps some legitimate but unconventional research in with the crackpots and makes Arxiv itself somewhat of a gatekeeper.

What I'm imagining is a sort of layered approach with raw "article" (or some other unit) data at the bottom and indexing, tagging, clustering, filtering, reviewing, commenting, linking, etc. layered on top with possibly many implementations to choose from.

The analysis/filtering would also apply to people augmenting the data, so if some users are really good at tagging certain types of junk as junk, you could easily filter out that junk. If there emerges a cluster of users who keep tagging certain interesting material as "woo" then you could filter them out or even use them to discover interesting material.

I doubt there's a silver bullet (at least today) that could reliably distinguish between unconventional-bad and unconventional-good work, but keeping the baby and the bathwater together opens the door to such an algorithm in the future.

[1] https://arxiv.org/abs/1603.03824
Might be unpopular, but I'm super okay with maintainers just disappearing and ignoring their projects. Stop putting so much weight on the original package namespace. I know it's a lot of work, but in my experience, when maintainers disappear, the community creates a fork that's better maintained and people migrate to that version.

I think if you want to stop working on a project, and it's on github, just leave a note in the README, archive it and move on with your life. Don't give the keys to someone on the internet.
This is a classic example of incorrectly blaming Trump for everything bad. The breathless media made it seem like Trump had halted ongoing testing despite that it had never actually started in the first place.
CU Marketing Corner – CU at the Event
>There's no Next Big Thing in the near future

How can you know this? Is there a precedent of knowing beforehand right before the "next big thing" is about to happen?
Most romaine is grown in the Salinas Valley in California, during a long growing season where product is ready from April to November [1]. In the winter months [2], coastal areas get too wet and the Sonora Desert becomes ideal. Production shifts to areas like Yuma, El Centro and the Imperial Valley, the Coachella Valley, and Blythe.

[1] https://apps1.cdfa.ca.gov/FertilizerResearch/docs/Lettuce_Pr... [2] https://anrcatalog.ucanr.edu/pdf/7216.pdf
Fantastic post! But can we please, please stop calling power point presentations "decks".
I think the more they build, the more they'll screw up. I've yet to see anything good coming out of Apple in the last few years.

- force-touch touchpads are so useless than not even them use the technology to any meaningful extent

- the Touchbar is completely useless, and anecdotally people stop using it after a few days

- their new butterfly keyboards are a nightmare to type on (albeit that's definitely subjective), and stop functioning with dust particles, and they haven't even acknowledged the problem before being hit with 2 class actions

- they've removed all useful ports from their laptops, and headphone jacks from their phones.

What a shit show.
It's S3, so you can use Lambda, it says so in the article.

> You can write AWS Lambda functions to to build an “intelligent” FTP site that processes incoming files as soon as they are uploaded, query the files in situ using Amazon Athena, and easily connect to your existing data ingestion process.
I think we're in agreement, sorry if that wasn't clear.
This is why AWS is so far ahead: survey the landscape, find the things they don't already cover, and come up with a managed service for it. It's usually not perfect, but it almost always just works.
> MRV is "first-class" for the purposes of this discussion.

MRV is not first-class for any purpose.

> Your proposal still depends on treating `error` as a special type, so my criticisms still apply--the juice just isn't worth the squeeze. That said, if another mechanism is introduced

There is no need for "an other mechanism" since as you yourself note the only need is for the compiler to understand the existence of error, which would require no change to userland code or break any existing.

Hell, technically and if you want a lowest denominator that isn't even necessary, you can hang it off of the MRV itself (which is very much a built-in special-purpose not-first-class construct) and have syntactic sugar for special-handling of the last return value, irrespective of its actual type.

> for example, a trait-like system for hanging sugar off of a la Rust's

try! and ? don't "hang off of" a trait, they work specifically on `Result`[0]. They only use traits for the sub-feature of automatic conversion of the error value, which IME is only a small and non-necessary part of the feature: usually you either return the error as-is or need to add context beyond what can be extracted from the original.

[0] the Try trait aims to eventually allow its use beyond these, but is currently nightly-only
why state 'I don't know anything about fusion power' but expect that fusion is simple.

nothing is simple, nothing is elegant. Everything is hideously complex, we are just standing on the shoulders of giants.
e.g. Try making common things that we take for granted, like building a plane or glider or even writing a text editor from scratch (including the font rasterization code and display driver).
dependABot does it on github, theres lots of issues in other repositories referencing this issue (visible at the bottom of the thread)
> The randomness and lack of symmetry suggest that we are lacking insight into the problem

No, it doesn't.

> Conceptually fusion seems pretty simple: why in principle does harnessing it require super-human complexity?

Because having 2e30 kg ball of hydrogen within a powerplant is extremely unwieldy here on Earth.

> In software, if you are replacing divisions with bit shifts, maybe you really need a different algorithm.

Huh? If your algorithm says "divide by 4", why would you need a different algorithm.
I agree with you, but it's important to acknowledge the strength of the argument against exceptions. I think Raymond Chen put forth some of the best arguments, claiming they were human error prone:

https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=...

https://blogs.msdn.microsoft.com/oldnewthing/20040422-00/?p=...

While forceful, I don't accept the conclusion of Raymond's argument. I feel it may be true for programmers primarily trained and experienced in C, but is not true in general. As such, the argument reduces to "programmers who are not familiar with exceptions sometimes make mistakes when using them." One could say the same thing about pointers, dynamic typing, lambdas, macros, comprehensions, pass-by-reference, etc. Today, most programmers are familiar and comfortable with exceptions, having almost certainly been taught to use them in college and almost certainly using them on a daily basis for their entire professional career. They'll also have been taught to use a language-specific toolbox such as RAII or try/catch/finally to deal with any potential problems.

Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?" and to take appropriate precautions. In fact, I'd wager that for anyone who's spent years working in any language with exceptions this quickly becomes second nature. It's also an easy way to add value during peer code review. In my experience, writing correct code with exceptions is not "really hard," as Raymond argues, but rather no harder and a lot quicker that using explicit error handling. The reason it's a lot quicker is because "exit the function with an error status and do local cleanup of variables initialized so far" is by far the most common correct action. And for cases when its not, the try/catch/finally or other exception handling whatever is straight forward to write and no uglier than explicit error handling would have been. Of course, it's possible I think this because I've worked in languages with exceptions for most of my career. But I certainly don't observe that even the most junior programmers on my team create a ton of bugs that could be attributed to mishandled exceptions. In fact, I can only remember a handful of such bugs, mostly involving open database transactions or unhelpful error messages masking more detailed error messages.

A more solid objection to language support for exceptions can be made by pointing out all invisible code generated by the compiler to correctly handle exceptions. This can lead to significant code bloat and in some cases can negatively impact performance. Or by pointing out how unwise it is to be allocating additional Exception objects while dealing with out of memory errors. These are some of the reasons why C++ isn't appropriate for an OS kernel, for example.
Just add the --dry-run argument.

npm i --dry-run event-stream
The Monopolization of America
This is classic Go design, for better or worse. "Just use this ad-hoc, unprincipled tool to counter a shortcoming of the core language."
Bias in student evaluations of teaching
As a self-taught software engineer, I'm trying to improve my CS knowledge and wrote this article as a way for me to improve. Any feedback would be really helpful.
You can set a lambda to be triggered on a file upload, at work we do this for creating reports.

Lambda dumps mongo data to an s3 bucket which triggers another lambda to create a csv.
> the package is trusted via his credentials.

Somebody really needs to explain to me how this works. The dude's bio on github is "antipodean wandering albatross". Nothing against it btw.
Callbacks/webhooks are handled by Lambda, according to the article.
Since when do discount frenzies = popularity?

There are currently discount frenzies on the essential phone...
I think the underlying issue here is ownership of a package, that is the sensitive thing that was given away. This is why I prefer to publish scoped packages, e.g. `@dominictarr/event-stream` not `event-stream` onto npm, so that ownership doesn't need to be given away. If someone wants to give continuity to the project, it can be done under a different fork. Also, it's important to pin versions for immutability. Naive OSS software, with changing owners and evolving versions, is essentially "mutable", and a weak spot for attacks.
Huawei nova 4  दिसम्बर में होगा लॉन्च । बाकी सारे स्मार्ट फ़ोन की कर देगा छुट्टी
> I'd much rather have my dependencies die than start silently pulling in a fork.

Maybe, but Node had that issue too, no? Remember leftpad?

So, lots of people in the Node ecosystem don't agree with you.
only financially, which isn't one of the reasons you should work for a startup!
> SFTP (Secure File Transfer Protocol)

It's SSH File Transfer Protocol. When you say Secure File Transfer Protocol many people think about FTP over SSL if you don't emphasize it's about SSH.
Hi all,

Here's a quick summary of the situation.

WHAT HAPPENED?

==============

A widely-used dependency was handed over to a different maintainer, who proceeded to add a malicious sub-dependency to it. The sub-dependency only contained the malicious code in a single release, and only in the minified version, likely to avoid detection.

WHAT DID THE MALICIOUS CODE DO?

===============================

The malicious code used the 'package description' to decrypt its payload; this was done to ensure that the malicious code would only run when the dependency was used in a specific application.

That specific application was the Copay Bitcoin wallet, from BitPay. The malicious code injects itself into the application, steals the user's Bitcoin wallet, and sends it off to a remote server. It's currently unknown who operates this server.

There may be other forks or projects with the same package description, "A secure Bitcoin wallet", that are also affected.

HOW DO I KNOW WHETHER I WAS AFFECTED?

=====================================

As a developer: Look in your `package-lock.json` or `yarn.lock` for an entry of the `flatmap-stream` dependency, specifically version 0.1.1. Unless you were developing on Copay, the code probably wouldn't have run, but you should still remove the dependency.

As a Copay user: No release of Copay included this malicious dependency. It's unclear whether copay-dash, a fork of Copay, did. Contact your wallet developer for more information.

HOW CAN THIS BE PREVENTED IN THE FUTURE?

========================================

This is probably the most crucial question here. There's already a "lol JS" bandwagon gaining steam in many places, but that's not really the issue here; nor are small modules the issue.

Dominic Tarr is an established contributor to the ecosystem and part of the community, not some random unknown party, so this issue would have existed regardless of the size of the dependency.

I would argue that the real problem here is of a social and partly-economic nature: There's no clear way for maintainers to find a good new maintainer for their projects.

This is not a problem that is unique to JS, either; such support structures are missing in most ecosystems.

As a developer community, we should probably have a serious discussion about the security risks introduced by lack of funding, and by the lack of a support structure for no-longer-maintained packages.

The latter can be solved on a grassroots level, without any payment being involved. The former is going to involve funding models of some sort, and I hope that this discussion can be had in a neutral manner, not as a marketing pitch for a specific startup.

Another important problem is that there's essentially no code review tooling. While in this specific case even a review would have been unlikely to catch the issue, it's pretty much impossible right now to review all of your dependencies in a project (in any language) without going crazy.

Possible solutions to that would include a review tracking system, that integrates with your package management and flags any new dependency in the tree as 'needs review' before accepting it.
What's your point? Are smoking/tobacco regulation and E Coli testing somehow mutually exclusive?
Sure, I personally like to be able open the device without having to look at it. It’s a security access feature I’ve come to be spoiled by. That’s all just my two cents. And I should have said any new iOS devices for me.
Aren't there several options for what to optimize for? Such as views, clicks, conversions, etc?

Additionally, aren't there filters companies can choose, such as targeting users who have searched for certain keywords?
In a similar vein, Mallory's justification for attempting Mount Everest is often repeated. He died in the attempt.

We hear about heroic failures too.
The problem might be that patents are only valid for about 20 years. That might be the time required to perfect the technology and reach the break-even point.
How to Onboard Software Engineers?
Wikibon’s 2018 Cloud Markets and Trends Report: The cloud moves to the data
Share prices expand when revenues look to be expanding. What the price action in MSFT and AAPL tells me is that the market sees MSFT as growing over the next few years (at least) and AAPL not growing much from where it is now.

This story starts to make sense as you look at Apple's product portfolio. AAPL's cash cow is the iPhone. Yes they make tons of money on other products like laptops, tablets, and watches, but the lion's share of the revenue comes from iPhones. This has been the case for a long time, so why now has the stock pulled back? It's because now the ASP on the iPhone is likely topped out for a while, especially as the economy starts to slow down. So ASP is topped out, what about unit growth? If prices remain constant but units sold continues to go up, wouldn't that mean increased revenue? Yes, but that too seems to be stagnating according to the most recent earnings reports. And that's the story, IMO. Revenues on the most important products have seemingly topped out and probably won't increase significantly from here. That could of course change if for example lots of Android users unexpectedly flock to iPhones. There's no reason to believe this will happen, though.

What about other lines of revenue? Services, for instance? Apple Music and video content are commodity businesses so likely won't see much revenue expansion from here. Wearables are probably the main bright spot.

Let's not forget that the entire market for tech stocks is in the midst of a huge sell-off which is probably most to blame for Apple's decline. There is probably two-way influence here.

Apple was basically rerated over the past year or two from a stable dividend generator to a growthier stock and is now being rerated back to stable dividend generator. I don't think Apple has any near-term competitive threats to its business so should bottom out sometime soon, but if the stock is to resume its uptrend it has to show significant growth in new areas.
I find this perspective curious. Maybe it's the non-web field that I work in, but I've never written a program where I could unintentionally ignore errors and have things go as expected after.

What are some cases where errors can be ignored? And if they can be, are these neccesarily some sort of "status" rather than "error"?
Unfortunately this isn't really doable in today's world of JavaScript development. If you want to use any of the popular frameworks you are installing a metric ton of dependency code. So not only do you have to somehow review that initial set of code, but you need to know how to spot these types of things. Then, once you complete that task, you now have to look at the diffs for each update. And there will be a lot of updates.

What you're suggesting is a great idea from a security perspective. But for typical workflows for JS development it just isn't practical.

Now, maybe this means we need different workflows and less dependencies. But it's so ingrain I don't know that it's easy to fix / change.
Deobfuscated libMobileGestalt keys (iOS 12)
Bookmarklet for fixed multiplier:

javascript:void%20function(){document.querySelector(%22video%22).playbackRate=1.7}();

Bookmarklet for variable multiplier:

javascript:void%20function(){document.querySelector(%22video%22).playbackRate=parseFloat(prompt(%22Set%20the%20playback%20rate%22))}();
Any pointers where to start, if I haven't read/seen anything (nor even heard about) Tien, but I find it interesting to see what he has to say?
It's interesting to see that, although what we call now a "microprocessor" had already been invented, in that paper they use the same word to describe a CPU implemented using microcode (and not a very small processor that fits in a single chip).

Here is a picture of the author of that paper working on the CADR machine (the successor to the CONS machine): http://www.computerhistory.org/chess/stl-431614f64ea3e/
The testing would have started well before this outbreak if the administration hadn't postponed the rule change:

> After several high-profile disease outbreaks linked to food, Congress in 2011 ordered a fix, and produce growers this year would have begun testing their water under rules crafted by the Obama administration’s Food and Drug Administration.

> But six months before people were sickened by the contaminated romaine, President Donald Trump’s FDA – responding to pressure from the farm industry and Trump’s order to eliminate regulations – shelved the water-testing rules for at least four years.

I don't understand how "it had never actually started in the first place" is relevant at all. There were plans to help address this problem, but those plans were delayed by the Trump administration.
Now, cloud companies want to run the rest of your business
Exclusive interview: How CEO Andy Jassy aims to keep AWS atop the cloud
Sure, but we can't call them PowerPoint presentations either.
It isn't all some perfect word of pure water. Arsenic is often a problem when drilling for potable water, even in rain-drenched places like Vancouver Island.

Karst water is the deeper stuff. Municipal water supplies come from wells drilled deep through karst. A great many people get their water from their own, much shallower, wells.
You might find this interesting: https://wende.github.io/elchemy/

IMO OCaml is not any harder than Elm.
> and six months (and $8 million) later a fantastic solution was delivered — on time, on budget, high quality and everyone in the project had a great time.

I don't believe this story
Well of course there are outlier product categories which are not repeat purchases, like engagement rings, funeral caskets, refridgerators, etc. That goes without saying, and if someone is paying to retarget those they're probably wasting their budget.
Funny, but obviously not real. If the guys were tired of "tired of walking over every time the bell rang", the number of defects detected wouldn't be 0.
Plasma dynamics isn't simple. You're trying to confine fast-moving charged particles with a magnetic field. Those charged particles generate their own magnetic field when they move, and that field creates forces on all the other moving charges. Most configurations are unstable, because tiny asymmetries in the shape get amplified.
They should have a pretty good idea which items get reordered a lot and which don't. They've got plenty of data.
Do I like going to work every day? Do I like my coworkers and the kind of work I'm doing?

These questions have always guided me well.
For some time now, I’ve been thinking that it’d be funny to add a Lisp-style condition system to Go by abusing panic, defer & recover. I think that it’d be possible (since Lisp’s conditions are really just built atop THROW & CATCH).

I don’t really think it’s a good idea: Go’s lack of macros imply rather a lot of anonymous functions to get it to work, which would imply loads of parentheses & curly brackets. Not to mention that the lack of first-class type literals would make actually using it close to insane. But it’d certainly be interesting. It’d definitely not be idiomatic Go. Still … interesting.
Interesting, thanks for the explanation. I was not familiar with the npm ecosystem. If the ecosystem has a cultural norm of "blindly" updating dependencies regularly, that could be the root problem. If you're going to live on the bleeding edge, rolling the dice over and over, you're going to have a bad roll once in a while.

Your world seems more sane, and I (also not in node, JavaScript, npm etc.) generally follow that too. Updating third party dependencies should be a rare thing, something you do only when you critically need to. If I were working on any sort of serious or commercial project, I'd expect to do my due diligence when considering updating a dependency, including examining the dependency's downstream dependencies. Do I really require the additional functionality or fixes from the new version? How mature/tested is the new version? Have there been any changes in the API? What do the release notes say? Are the trade-offs of updating worth it?

Just saying "YOLO, update my dependencies and go!" would give me severe anxiety.
> these are purposeful trade-offs that the Go team makes.

Trade-offs for whom or with what in mind? the compiler or the programmer?

That's the "philosophical" difference between the Rust team and the Go team.
Agree, except that windows is a clearly de-emphasized product. License revenues are contracting faster than the PC market - almost 1.5x as fast. They're not releasing new paid versions anymore, and exploring things like paid support options a la redhat. It doesn't even have a dedicated department anymore.

Xbox and surface have been surging though, which is the real strength in that profit center.
Yes, they do. Customer patterns on that product
You don't need to login to view the list. That would be silly.
Is there a SuperMemo-like tool for Linux?