skysight-inc/HackerNews huggingface dataset:
Nonsense. A lot of people don't understand that for a composer of Beethoven's training and skill, physically hearing the music is essentially irrelevant. The image we have in our heads of a composer sitting at the piano and noodling almost certainly doesn't apply to a Beethoven or a Bach or a Schumann. It would slow them down intolerably. They could read music and hear it as surely as you and I can see word pictures when we read a novel. They would compose and hear the music in their head and simply transcribe.
Looking at such articles makes me feel we are going back in time rather than improving efficiencies for developers to build RESTful server. If you look at Ruby on Rails you can build the server shown here in one min that is scalable and backed with database. I know people will complain about speed of execution of language and framework but do you really care if you are not expecting Google like traffic.
I don't feel that I'm particularly unreasonable. I'm certainly interested in understanding your perspective.

I hope I'm not misinterpreting your statements, but it appears you agree that information is rooted in trust. In fact, you say it's philosophically so, while I make a weaker claim about practicality.

A paradox would arise if I were to say "information is based in trust, trust no one". But I would instead say "information is based in trust, empirically evaluate your basis for trust".

I'm not sure I recognize what's dangerous about the claim, or what your proposed alternative is.
About 1998 when Microsoft tried to invent their own "flavor" of Java, I lost all interest in the company, and that's right when I switched from a C++ developer to Java. C# was just another "copy" of the VM concept Java had, as you well know. Even if C# was superior under the hood (which it isn't) I still claim it just fragmented the industry and was just an example of a company creating their own proprietary stuff for their own self-serving reasons, and before you think you're correcting me, yes I know the CLR is supposed to be machine independent. When VBScript was finally yanked out of browsers the world celebrated.

I will openly admit however when VSCode came along and TypeScript I totally regained a new love for Microsoft, and they have redeemed themselves, also by accepting Linux into their dying OS.
List of studies showing carcinogenic effects of non-ionizing EMF
Not sure why you're smearing Indian English journalists like that. I'm an Indian as well and there are some really slimy journalists / organizations in the media industry (just like there are the obvious ones in the US) - but NDTV or Nidhi is definitely not one of those. She's a pretty well regarded journalist.

Is there anything major you think she's done in her career that makes you say that?
What is your opinion on Net Neutrality? Certain interests always get exemptions.
Thoughtful list. Useless title, FTFY.
The killer feature of a new email protocol will be that it's not SMTP.

It should have sender authentication. E2E encryption that's easy and works by default. Those would be more than enough killer features, SMTP is just too broken and all the workarounds we have in place like DKIM, SPF, Spam ratings etc etc don't make up for it. We still have spam, important mails still end up in our junk boxes, and nobody trusts it enough anymore to put important content in emails. The war has long been lost.
Signal is back. https://nitter.net/signalapp/status/1350595202872823809
This was a painful episode, but on the bright side, the team is sure to have learned a lot. Hopefully they won't have bled too many users. Looking forward to a more stable Signal in the future!
It doesn't do what's needed. It provides a channel for spam, insecure delivery etc. It's too broken. We do really need a new email.
Extensions like this keep my faith in the internet going, and a lot of other stuff in general going as well. Because it proves that for every moron you can find, there will be a decent person to counteract them.

The problem is as always, it is easier to break things than it is to make things.
I'm not sure that's true. Email has a somewhat archaic data model that has suboptimal support for things like threading.
Blacklisting a site incorrectly seems like a perfectly adequate reason for a defamation lawsuit. So, I think the real issue is with the legal system.
In (c) with 1-based ranges the size of the range is present in the range. There is no calculating because the value is there. 1 <= x <= size

One argument for the notation (not 0 vs 1 based ranges) is that notation (a) offers easier detection of adjacent ranges. This is irrelevant to the 0 and 1 based range debate.
I agree that there is a difference between simply taking notes and simplifying the content and writing down your own take.

I'd argue that a good note-taker will be doing the latter automatically.

I also disagree with the claim that note taking doesn't enhance learning. It forces one to pay attention rather than daydream and ignore the content entirely. It would be less tiresome, of course, to just pay attention and not take notes, but it does serve that purpose.

Another purpose for note taking is to pass the notes on to someone not present during the class/lecture/talk. For example: I was paid to take notes for others in college.

Another use for notes is to look back on the notes and verify that you have effectively absorbed the material; studying portions that you don't understand fully.

The article is far too dismissive on the value of plain note taking.
The 1999 EPA range test was even more optimistic than the current test. On the current test, the EV-1 would earn closer to 100 miles.

It’s also a tiny 2-seater compared to the 5-seat Leaf.
> If you haven't tested or don't know how your systems are going to react when operating for a different scale,

In my opinion, this is a pretty unreasonable expectation. Not to mention any load testing is going to be done under a certain set of assumption, a set of assumptions that is almost guaranteed to be violated by actually scaling something.

What's the most naive load test you can think of? I am going to see the maximum amount of requests my dev instance can handle. Oh i can handle 10 requests per second. If I run 24 instances on a machine, and run 100 machines, then I must be able to service 24,000 RPS.

Ok... Now explain concretely, what kind of load testing would/should have been done that would have surfaced the lack of an exponential backoff without a priori knowledge of it?

The category of things you don't know you don't know at 10x scale is large. The justification for spending time "scale testing" is going to be a hard when your manager goes to social media and sees every single person wanting backups for their texts. "Hmm should we apply engineering resources to the feature we know everyone wants, or exploring the potential land of failures that may or may not have payoff, and definitely not immediate payoff." Most of these prioritization situations are directly and solely informed via experiencing outages, just like this one.

> then don't let it grow in the first place.

This is the type of insight you get from experience, it's also the type of call that I personally think would be very hard to make. As an engineer you don't always know if an outage is going to solve itself, take 10 minutes, 30 minutes, or take 10 hours. Then communicating that to someone with the power to create that policy...

How many (social) companies do you know of that haven't had absolutely catastrophic outages/security breeches?

This is the type of outage that justifies reliability work and gets resources applied to it. This is the type of thing that results in an organization creating a somewhat rigorous incident response policy that handles the business side (keeping users informed, giving them the best experience possible). This is a growing pain of rapid maturity.

I think you can talk the way you do because you have not personally faced this type of engineering situation (a guess). Easy to make comments from the peanut gallery, but try putting yourself in the engineer's or the CEO's shoes and walking through what information you have at the time and what options you have available at the time, without the benefit of hindsight. Imagine you have a pipeline of priorities you look at every day. Is spending time wooing a senior engineer to come work for you a lower priority than having a good story for what happens when you 10x your traffic in 2 weeks? Things can only be black and white in hindsight. Their response to this is infinitely more indicative of the type of organization they are than the actual outage.
I agree with your opinion, but even suggesting for folks to learn C or even assembly language today can often have you labeled an old timer/gate keeper.
DI is a decoupling technique. You might only have two interfaces to begin with, but the rough idea is that writing to interfaces and using IoC allows you to make many changes by adding code without having to change old code.
This is true. For those that would like to learn more, I'd highly recommend listening to the Rational Reminder Podcast Episode 101. Ben Felix does a great job dissecting the facts on dollar cost averaging.

https://rationalreminder.ca/podcast/101
You do realize that SELinux is their baby, right?
Go has existed for 11 years. It's probably safe to say that it won't die off soon. As for the control part: What could Google do to Go that would affect you as a user of some software written in it?
They have Cluster Singletons that alleviate this concern now. You don't need to know their physical location in the cluster. All you need to do is ask the cluster for a pointer to the Singleton and you can message it directly.
Show HN: RemoteClub – Best cities to work remotely across the world
I guess it's subjective. For me the clear advantage of building HTTP endpoints using Go (framework-less) over DRF, Swagger and others is: no magic, no annotations, no dependencies; I know exactly what's happening and I can build a tailored system that is adjusted to my needs. This leads to very performant systems that are highly independent of the current trends and, most importantly, to a high degree of ownership of the systems you are building.

The act of writing these kind of systems is IMHO, somehow, liberating.
Congrats to the team. I am sure it must have been a stressful one.

Some remaining issues:

The desktop app on first message in any conversation says: "Partially sent, click for details". When retried, the message goes through, but is not synced with the mobile client (never appears there).

PS: Happy Signal exists. It's easy to let inconvenience make you forget it sometimes.
Probably, but I wonder whether you could ask facebook to take down messages on your facebook page to bake a cake for a gay wedding if a North Dakotan legislator was requesting it...
It would be more accurate to state that *all services are doomed to fail for short periods of forever* which ultimately means nothing. Everything will fail at some point, even your chosen decentralized service.

I do agree that decentralized is the way forward, but there's no way I'd ever ask my grandma to install Matrix.

Matrix is a Discord/IRC replacement - a significantly better alternative! But let's not delude ourselves into thinking it's going to replace text/SMS, which is the primary use case for WhatsApp/Signal.

I can send my grandma a link to Signal, and she would be able to get it working, and I'm already in her contacts! There's no way I'd attempt the same with Matrix/Riot/Element/Fluffy chat.
I don't think it's the worst thing in the world if you test your http.Handler implementation:

w := httptest.NewRecorder()
req := httptest.NewRequest("GET", "/foo", nil)
ServeHTTP(w, req)
if got, want := w.Code, http.StatusOK; got != want {
t.Errorf("get /foo: status:\n got: %v\n want: %v", got, want)
}
if got, want := w.Body.String(), "it worked"; got != want {
t.Errorf("get /foo: body:\n got: %v\n want: %v", got, want)
}

It leaves very little to the imagination as to whether or not ServeHTTP works, which is nice.

Complexity comes from generating requests and parsing the responses, and that is what leads to the desire to factor things out -- test the functions with their native data types instead of http.Request and http.Response. I think most people choose to factor things out to make that possible, but in the simplest of simple cases, many people just use httptest. It gets the job done.
The Early History of Usenet Part IX: Retrospective Thoughts (2020)
I guess the question here is who is more like those doctors in this scenario: you, or the people running the randomized controlled trials?
> I respectfully disagree

Cool :)

> The entire human brain has 0.1 trillion neurons

You want to be thinking about synapses. There's about 7000 synapses per neuron, so that's 7000 * 0.1 = 700 Trillion synapses. So thats *100 times larger than GPT-3. Also consider that a neuron does a fair amount of processing within the neuron, there is some very recent research on this, each neuron is a akin to a mini neural network. So I would not be surprised if the human brain is 10,000 times more powerful than GPT-3.

> It is not hard to find cases where it directly reproduces entire paragraphs from existing text. When given a prompt on a topic for which it finds multiple existing texts with similar degree of matching, such as different articles reporting on the same topic, it is able to blend the content of those articles smoothly.

This may be true, but it does not prove your hypothesis that all GPT-x models are simply "performing interpolation". Also the ability to perform recall better than a human may be to do with the way that we perform global optimisation over the network, rather than the local decentralised way that the brain presumably works. Point is accurate memorisation does not preclude general intelligence. Spend some time with the models, sit down for a few hours and investigate what they know and do not know, really look, see beyond what you expect to see. You may be surprised.
This soulless corporate style of illustration not a single person likes:

https://www.imgur.com/DcL05OA.gif

(This could be a subset of infantilization, since this art style seems to come from books for toddlers.)
Wanna have hot-lovin' conversations? You’re on the right way! - https://adultlove.life
Latest Job-Stealing Robot: Package Retrieving Climber Bot Replaces Forklift Guy
There was a post on HN yesterday about Rust not having a strong web ecosystem yet, especially for writing web API libraries and working directly with microservices.

I wonder if and how Deno solve that?
Okay so, the issue here is that you two are speaking past each other. Enums in Rust are more than enums are in C. So this conversation is something like:

Them: I like sandwiches.

You: I get sandwiches from McDonalds, they're great.

Them: Yes, but those are burgers. (The implication being that there are also other kinds of sandwiches.)

You: Yes, burgers are good.

You're not wrong, but you're kind of missing what they're saying.

Enums in Rust can be like enums in C, but they can also be tagged unions. Furthermore, Rust won't automatically cast an enum to an int, so it is a bit harder to make mistakes, even if you're using the C-like ones. That's the advantages they're speaking about. Enums are good and useful in C, it's true. That's why Rust added stuff to make them even more useful.
This is the first time I hear about https://publicsuffix.org/ Will definitely check it out. Maybe that will help me solve this problem. Thanks a lot!
They lost me at "weird JSON header followed possibly by arbitrary 8 bit data". The rest of the protocol is kind of crazy too.
US military sonar linked to whale beachings in Pacific, say scientists
This would be useful for keeping my unraid data from rotting. I have definitely seen small bits of corruption in my multi-terabyte storage, even with ECC in place.
Well, I instantly knew Dropbox would be a hit. At least for me
That reads like an analysis of some big event in Eve Online.

Fascinating but I obviously have no understanding of either.
I read this book last year. What a fun read! Well thought out, clever solutions, and a very focused amount of tenacity.
A single DNS record and distributing the signing key to probably thousands of machines able to send mail, some of which are probably 30 years old and unable to do the dmarc crypto...
That's why experienced Java devs generally try not to put any logic code in POJOs.

So you never generally even open those files unless you're expending the 5 seconds it takes to add a new prop. But as I said I could make each property use one line of code if I chose too...something like "String x;" just like all other languages.
I'll stick to regular email till I'm dead. Thanks.
Capitalism is neither good or evil, it is a neutral force that can be leveraged for both. I don't want to offer excuses, but rather find explanations. Imagine you are the CEO of Intel (or VP of that business unit) - what would you do in their shoes?
Is the cache smart about prefetching related files to your current activity?

If not, it's so tiny that while it will give you amazing performance on disk and database benchmarks I'm not convinced it will be notably better than an SLC cache when doing anything else. And an SLC cache doesn't require an extra chip.
Penny-Stock Peddlers Piling into Reddit Forum Prompt Rule Change
Can you spread Covid-19 if you get the vaccine?
> The lack of E2E encryption and sender authentication makes it completely useless these days.

Both SPF and DMARC provide sender authentication.
I don't know. I understand the journalistic theory behind it, but as applied here, it feels like the equivalent of an investment bank explaining that it's unfair to hold it accountable for its false Libor submissions. The NYT's institutional reputation was a fundamental part of what made this op-ed work - nobody would have believed it if it were on a random anonymous Blogspot - and that reputation can't be cleanly divided according to the company's internal firewalls.

There's a point where you have to hold organizations accountable under normal standards, rather than letting them set up special rules to define their bad conduct out of existence.
The notation is from math; the point of it is that you can manipulate it like a normal expression, but it's "anonymous"; o(1) means some function that goes to zero, but we don't bother with a name, just recording the asymptotic behavior.

For example, f'(x) = lim (f(x+h)-f(x))/h can be rewritten with an error term f'(x) = (f(x+h)-f(x))/h + o(1), and then you can manipulate it more freely, say like f(x+h) = f(x) + hf'(x) + o(h). There's no need to drag out a bunch of useless names, each qualified by a set membership, to do this. I mean e(h) in o(1), e2(h) := h e(h) in o(h), etc.

The failure of "reflexivity", eg O(f) = O(f), is because the anonymity hides whether the two O(f)s are referring to the same function (ie. exactly what a name would tell us).
This works great when you have all of your computers in an office, like in 1999.
Real shame if this domain got blocked because of a contraband file, eh? Just pay us and we'll make sure you don't have any problems.
Children’s Screen Time Has Soared in Pandemic, Alarming Parents and Researchers
I don't think you said the word "gaslighting" enough times.
How do hackers get access to these devices and learn about how they're deployed in order to be able to exploit them? Can someone ELI5 this?
Could one implement a distributed filesystem using Akka?
> Who ever implements it gets to decide

That is true. And as the post mentions, Daniel did decide to allow some Rust into the tree, years after he wrote that post. Sometimes people change their mind. It's often a good thing!
It’s crazy to me to think that the USA has some gorgeous, tall mountains, and the mountains in Pakistan are twice the height!
With Cluster + Sharding you can have zero(ish) downtime though when you scale horizontally. Messages sent to Sharded actors are buffered if their nodes ever go down and things will just resume as normal.
> The software manufacturing industry could do with some more silicon sympathy.

These are still orthogonal concepts. First of all, it's all about cost: if the operational costs of running a piece software over the lifetime of said software are significantly lower than the cost of optimisation, there's nothing to be gained from doing the latter.

Developer time is more expensive than a faster CPU, additional RAM or slightly higher power usage. Back in the day, the iron was expensive and developer time was cheap. Today it's the other way around, so saving on development time is more important than optimising for specific hardware.

Hardware-level optimisation becomes especially bogus if your deployment target is data centres - you often don't even know the deployment target beforehand (could be an ARM CPU, could be an x86 CPU). With many modern SoCs (see the M1), it's even impossible to optimise at that level, since you don't even get the required hardware specs and simply using Apple's libraries will get the best results.

So my argument still stands: there's litte benefit in general from going into such detail. Feel free to disagree, but developments like the Go language, SoCs, and GPGPU compute seem to point another direction.

> It is to learn how to build a computer.

And how does that translate to actual hardware then? Very poorly still. The fact is that unless you work with certain embedded systems, you never get close enough to the hardware to benefit from this.

This is time better spent on learning how to use your tools and to learn how to benchmark and optimise based on algorithms and data structures instead, because that's where the inefficiencies start.

Besides, most programming languages are so far removed from the hardware, that there's absolutely nothing you can do to optimise (JS, Python, Go, Java, C#, Haskell, LISP, etc.).
Well one issue with them is that they're totally optional. The protocol should have this built in. The way it is now is a kludge. Even mails from big companies still end up in my O365 junk box. I didn't check them in detail but something failed there. At the same time the spammers are actually pretty good at avoiding spam filters.

Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge.

If we'd require emails to be signed by default this issue wouldn't be present.

What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.
You are missing the point entirely. All of those examples you've listed are clearly marked in some notion of "prerelease". Even in the FreeBSD example, you're going to see that one version is labeled in such a way to make it sound safer. "Long-Term Support" labelling of one version says nothing openly about the unlabeled version.

It's exactly the lack of label on non-LTS versions I'm talking about. It has a real impact on people, looking at which version to install, and having no guidance that "this version not labeled in any special way, yeah, probably don't use that". And no, digging into the developer mailing list to figure out what the versioning malarkey a particular project is using is not a documentation of it.
Fairly sure that's not true. The two are equivalent, one is easier for humans to reason about but for a computer they're isomorphic (I assert).