jkeisling/hacker-news-corpus-2007-2022 huggingface dataset:
We are a long way from solid-state batteries being a thing. 20 years minimum.

The one key problem is that you must put them under insanely large pressures to make them work. Basically the solid components are far too diffuse and low density to work at 1 atm.

Enough pressure is required for them to be potentially explosive if "opened" either intentionally or accidentally. And you thought lithium fires were a problem!

This itself is a not-yet-solved element of the technology that is no where near to being scalable at production.

The technology is overhyped if ANYONE says it's "just around the corner" - it's NOT.
The articles are published here:

https://papers.ssrn.com/sol3/cf_dev/AbsByAuth.cfm?per_id=256...
>If the Universal Declaration of Human Rights were part of the Czechoslovakian constitution at that time, this development would not be legal.

Which wouldn't stop anything in and of itself. The current Chinese constitution allows freedom of speech, for example.
In my circle of male friends, I am the only one who reads fiction. My female friends are more likely to read fiction and some even belong to book clubs, where they sit around and discuss books. In my entire life as a reader, I've never been able to discuss fiction with people in real life.

Non-fiction is completely different, as most of my friends read pop-science or political books regularly.
To play devil's advocate, couldn't this just be a way of filtering out people who would likely be less committed to finding a job, or less likely to apply for one they saw in an ad?

From the article:

> Companies trying to run ads on YouTube or elsewhere on the web could direct Google not to show those ads to people of “unknown gender”—meaning people who have not identified themselves to Google as “male” or “female.”

Not allowing an "unknown gender" doesn't necessarily mean purposefully excluding nonbinary people. A better option would be to allow people to choose "nonbinary" as a gender, no?

Not that I'm defending Google's ad monopoly.
I'm sympathetic to the cause here, but the bigger problem is that excluding "unknown" has value in the sense of "don't show my advertising to people that google can't track" or "people who aren't logged in and Google can't guess".

They could probably fix this by distinguishing between people who don't select a particular gender vs people who Google doesn't know anything about.
Is "communist" not a description of the economic system?

How "communist" was Pinochet? He had total 1-party control, after all.

Is North Korea a Democratic Republic? That's what they call themselves, after all.

You information sources are sick though, bro. Nobody has better information sources than you.
If forwarding is failing DMARC, that's on your system, not the senders. There is nothing the sender can do to help the situation.

Basically DMARC needs either DKIM OR SPF to pass to consider a message passing. Being no SPF record will ever include (forwarders aren't allowed to originate messages from the domain) that means DKIM has to pass.

DKIM works by signing the message body and selected headers with a private key, while the public key is published to DNS. This allows a receiver to fetch the public key from DNS and validate it was really sent by the sender. It should be clear at this point that you'll be able to forward a DKIM signed message as much as you want as long as you don't modify the message when sending. If on the other hand your forwarder modifies the headers (including subject) or the body DKIM will fail.

In other words, if your going to use a forwarder, make sure that forwarder will forward the message as is. You can add headers, but don't remove or modify any existing headers and don't modify the message itself.
Whether or not it's a DEX doesn't matter at all.

In this hypothetical world of regulation which has made some BTC "tainted" through surveillance, it will always be in the BTC receiver's best interest to verify the coins are "clean". Only a fool (or fellow criminal) would transact with tainted coins; most people would probably not use a DEX, or else use one which verified clean coins anyway without being regulated to do so.
The setup works both way.
Fwiw, Rms is being cancelled after doing his best work on software (yes, I'm predicting that his prime is behind him). You can understand that different ways, but primarily it's just timing (changing culture, Rms is old too).
I think the culture within COBOL is equally backwards. As someone else said, it’s targeted at people who’s main skill isn’t software engineering, but understanding of business logic.

I was once spoke to a consultant who in a past life fixed big COBOL projects. He said that one of the common technological and organisational challenges he faced was getting people to use ‘malloc’. Apparently there are COBOL programs that just SEGFAULT when the input reaches a certain size, and some developer has to change an array allocation size. COBOL developers would be hostile to the idea of dynamic memory allocation, and he’d have to explain that the rest of the world had been doing that for the last 30 years.
Can anybody tell me about playwright vs puppeteer? The API looks very similar. At first glance it seems to be written by some of the same people. The major difference appears to be supporting different engines.

It looks like puppeteer may now support FF, but not WebKit/Safari.

It just seems like there is probably a story there.
Is there a modern equivalent to the mentioned research test program that allows browsing submissions?

I would love to have a known problem set with browseable submissions in different languages. To see if I can get close to the optimal solution with my own preferred languages. But also to learn what an idiomatic solution in another language looks like.

The research problem from the article is interesting because it encompasses IO, some data structures and an algorithm for generating output.

edit: aside from single-binary problem sets like this, it would be nice to also have a more open category for "distributed systems" or "concurrency-related" problems to solve with modern coroutines/fibers/greenthreads or even AMQP-style message queues.
Avoiding taxes for corporations most often involves pouring money into projects, which in turn creates jobs, which in turn puts money into peoples hands. Of course this is not an issue for big companies that have the capital to do this.

This is arguably a more efficient transfer capital rather than raising taxes and then dealing with bipartisan political entities in the most efficient use.

Id also point out that the new tax policy also raises wealth tax by a significant amount. Also, its probably better to deal with wealth tax on a state by state basis, since this in turn forces the development of generally low tax areas since its favorable for people to move there (like all the companies setting up shop in Austin right now, which in turn raised the wealth of anyone there who owns a house by close to 100k at this point)
I’ve been trying to contact Paddle for some days to figure out some legal details but I’ve been unable to...
In "metamathematics" in the 1920s, sets were divided into 2 kinds or types as an attempt to evade a certain paradox. ("The set of all men who do not shave themselves" if I recall correctly.) One of those kinds of sets were called classes.

So, nothing to do with OOP.
In my opinion, he overengineered his entire post because what he is saying is your product and the labor making the product are two separate markets. You are not the only employer in town, if another employer pays more then your employees are not going to stick around to produce <insert_cheap_trinket_here>. Meanwhile customers are in a different market, only willing to pay the current price, so raising prices will just decrease demand.
I came to say the same thing. The article hints that such a use is possible, but makes it sound like it is a modern discovery of its capabilities. Turns out that poisoning was always an effective way of killing enemies (even still today), and there are many tales of goblets or gems that could detect or (as an embellishment) purify a poison. The fact that such a goblet actually existed is the real story here.

I'm very surprised no historian is grabbing this research opportunity to see what salts, oils, etc. (based on historically known poisons) and what concentrations the goblet can reveal.
Firefox 4 is a great success considering the difficulties, delays and stumbles between the 3.5 and the 4 release.

I used Minefield (and now Nightly) all through the FF4 development and really considered at one point the project has become victim of scope creep. Was worried about my favorite browser getting pushed into secondary choice for many by Chrome, but the entire Firefox team pulled back and did deliver an awesome release.
Thanks for the info. Surprisingly, when I was googling RBParser, I got two different results: one being the RBParser class from Smalltalk (I guess that's the one you meant), the other is a new project with the same name hosted on github [1] -- a Ruby code parser written in OCaml. Both make perfect sense in my search.

[1] "Pure and fast Ruby source code parser for OCaml"
https://github.com/m2ym/rbparser
I find it ironic he refers to grc.com for security advice. Birds of a feather...
Asia is pretty MSFT-centric, but I was a little surprised that on my trips to the Philippines, beginning in 2009, I began seeing a lot of Firefox installations, even Firefox-only, on a lot of boxen in the Internet cafes there. So it seems the tide is turning.
It probably has more to do with a lot of asian companies imposing tight restrictions on what can/cannot be installed on work computers rather than a microsoft-centric tech culture.
Worth mentioning there's no official confirmation yet, but this is the filing in question: http://www.sec.gov/Archives/edgar/data/1518293/0001518293110...
I read "Surely You're Joking..." and "What Do You Care..." with the idea that he's probably underselling himself.
I expect large companies will rethink scalability and not put all eggs in one basket.
> Asia has a pretty Microsoft-centric tech culture.

Which is a good thing for Microsoft but a bad thing for Asia.
That could actually work if you did it the reCAPTCHA way, i.e. "which two of these three comments are spam?" Where one of the three is already known to be spam. Of course the chance of getting it right by guessing is pretty high but there may be ways around that (by showing more confirmed non-spam comments perhaps). A cool start-up idea right there!
Everyone already does, and is trying to login right now.
Check your logs.
I worked in a datacenter (serving many companies you've heard of) during a catastrophic power failure that lasted almost 24 hours. It's kind of like a plane crash - it's never one thing failing that causes the problem (that's what redundancy is for) - it's that perfect chain of events, multiple 'once in a lifetime' failures that causes it.

For example, power outage occurs at the same time the UPS batteries are being changed. Bypass fails and Diesel generators fail to kick in. Circuit breakers blow everywhere making it extremely difficult to get the generators back on line. This all happens in the middle of the night in a winter storm (or 'lightning storm) which causes a further delay in response time.

Been there, done that.

Edit: Also, bureaucracy, lack of documentation, and a manager CF added several hours to the outage. Sometimes you just have to STFU and let the geeks fix the problem.
For those interested:

https://secure.wikimedia.org/wikipedia/en/wiki/Theanine

and there are supplements available if you don't want to give up coffee.
I'd choose node.js for the API. Using the same language on both the server and client can be a big plus. It makes context switching much easier for devs...

Then choose between Javascript, Coffeescript or Typescript.
Just curious to know how much this oil costs when you buy it from the supplier directly.
The concept of a global community of startup people is nice, but why do I have to use your platform to be a part of it?

That question felt unanswered to me after 60 seconds on the landing page.
https://news.ycombinator.com/item?id=4908877

https://news.ycombinator.com/item?id=8354505

https://news.ycombinator.com/item?id=5834879

https://news.ycombinator.com/item?id=4666069
I think the drive at least will be keeping an eye on its own power rail voltages and logging whenever they sag out of spec.

Those logs will be used to rapidly deny your warranty claim when you try to return it for not working properly...
> I gather that serious historians consider the mystical writings of Paul as primary, followed much later by realization of the need to invent a figure of Jesus to have been heard to dictate doctrine; and then to invent apostles to have witnessed it; and finally invent a timeline of dictation events.

Someone, somewhere may believe that, but it certainly isn't a shared belief of most serious historians (much less something most, or any, serious historians would consider strongly supported by historical evidence.)

About the only part of that on which there is broad consensus is that, of the writings incorporated into the scripture, the Pauline corpus is most likely the earliest to have been written in its current form.
Given a choice between hosting servers on AWS, and trying to build my own reliable infrastructure with a single sysadmin, I'll take AWS in a heartbeat. But I do want to quibble with one of your points:

It is easy to be an arm chair coach and scream that... they should have predicted this storm

I'm not as smart as the AWS developers, and I have a lot less experience with large-scale distributed systems.

But thanks to my own cluelessness, I've blown up smaller distributed systems, and I've learned one important lesson: Almost nobody is smart enough to understand automatic error-recovery code. Features like automated volume remirroring or multi-AZ failover increase the load on an already stressed system, and they often cause this kind of "storm."

So I've learned to distrust intelligence in these matters. If you want to understand how your system reacts when things start going wrong, you have to find a way to simulate (or cause) large-scale failures:

This is something that Google does really really well by the way, I've watched them turn of 25 core routers simultaneously carrying hundreds of gigabits worth of data, just to verify that what they think will happen, does happen. http://news.ycombinator.com/item?id=2475112

You also need to pay particular attention to components with substantial, ongoing problems, and make sure you don't let known issues linger:

I work at Amazon EC2 and I can tell you what's going on (thanks to this handy throwaway account). What's happening is the EBS team gets inundated with support tickets due to their half-assed product. Here's the hilarious part: whenever we've asked them why they don't fix the main issue, they keep telling us that they're too busy with tickets. What they don't seem to realize is that if they fixed the core issue the tickets would go away. http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_d...

Now, I'm not saying I could have done any better than Amazon (evidence suggests otherwise). But I do know that I'm not smart enough to understand these systems without testing them to destruction, and aggressively fixing the root causes of known problems.
Great stuff, going to share this with the interns on Monday.
This is really fun. This is like the Yo for notes!
But since its public and anyone can see what I've written, I probably won't use it for collaboration!
SEEKING WORK | Pristina, Kosovo | REMOTE

I am an experienced full-stack developer. I specialize in creating web applications with Angular / React on the front end and Nodejs (Express) / Spring Boot on the backend. I have professional experience in enterprise application development with cutting edge tools like Typescript, GraphQL, Rxjs, Golang, Docker, Kubernetes, React, NGXS and so on.

My background and skills include:

1) Highly skilled in designing, testing, and developing software

2) Experience with front-end frameworks (Angular, React)

3) Experience with back-end frameworks/technologies (MERN stack, MEAN stack, Spring Boot).

4) Experience in database management

5) Experience working with Docker and Kubernetes

6) Experience working with in an agile environment with a scrum team

7) Experience working with tools like Jira, Asana, Trello

If you are looking to get a project done, or you have an existing project that needs modifying, I would love to hear from you.

Github: https://github.com/adoi Blog: http://adoilogs.com

Email: adonismurati [at] gmail.com
Generally when you are on salary, you get paid a set amount of money for some number of hours worked annually.

You don't get paid different rates for different work.

While it is possible to have a salary position with expected outputs (teach x classes a semester, launch 1 product per quarter, etc.) the better position descriptions will talk about responsibilities not metrics.
The most valuable thing for me is my photo library. All of them are currently in Google Photos. Is there any easy way to backup just that? I don’t care about my personal email, tasks, calendar etc. It’s just the thought of losing my photos scares me.
No the endpoint is shared across all customers, the service providers do not self host, generally. The end point is the infra provider. Later I might try to code sign that and open up the cloud console for visibility, but not short term
That's a good way to put it, and I don't doubt you. It's just that the childless are frequently spoken to as if getting a family is the only way to unleash this potential, and I want to provide a counter-view.
A few things:

1) tx settlement time is ~3 seconds on mobilecoin, p99 latency right now with single block finality. Eth and Btc are great but they aren’t that fast (for payments speed really matters).

2) with respect to privacy, the key innovation of MobileCoin is that when all of the systems are operational, there is no transaction graph stored in the ledger. The links between transactions are known only to the counter parties to those transactions. In the event of a failure of the Secure Enclave, links between transactions degrade to probabilistic links between transactions (and forward secrecy can be restored upon recovery of the enclave).

The effect is a payment system that is both fast and privacy-protecting with no central authority, a quality not present in any other payments system I am aware of today.

Does that answer your question?

Oh, last and perhaps most important, because of our consensus design, we don’t use a ton of energy like btc and eth.
As the post says, "the knife cuts both ways".

You're missing the point! One can't say what are the cultural elements of "great". All you can do is tradeoff one element for another. What defines a great company culture is one that is held consistently, and that you, personally, as a person with your own particular outlook (let's call it red or blue), enjoy and are productive in. What's great for you is not what's great for another.

Too bad we can't understand this in our politics.

> Reinforcing that "whatever the cultural values might be they have to be strongly endorsed by the leadership" can be part of that, but that's describing something other than the "great culture" itself.

Necessarily so! You cannot define "great" culture because there is no such single thing. You can define consistency, though. This is the critical element because it means that you can predict the repercussions of your actions and act accordingly. Rewards and punishments don't feel capricious and subject to "politics". You don't have to guess what your particular manager will do based on his particular and inconsistent whims.
seems so.

https://twitter.com/MacHeist/status/556879808840630274
I find it mind boggling that something as simple as this can actually be patented.

unsigned average(unsigned a, unsigned b)
{
return (a / 2) + (b / 2) + (a & b & 1);
}

That makes the patent system seem broken to me.
Hi HN,

I am the founder of ToolJet https://github.com/ToolJet/ToolJet. We are excited to launch ToolJet 1.0.

ToolJet was in beta when we first launched on HN in June (https://news.ycombinator.com/item?id=27421408). . Since then, we have grown to 5,000 stars on GitHub, contributions from 100+ developers and hundreds of thousands of docker pulls. Today, we released ToolJet 1.0.

We believe our open-source and plugin-based approach helps the engineering teams to customise our low-code framework as per their requirements.

What is ToolJet?

ToolJet is an open-source low-code framework to build and deploy internal tools quickly without much effort from the engineering teams. You can connect to your data sources, such as databases (like PostgreSQL, MongoDB, MS SQL Server, etc), API endpoints (with support for OAuth2 authorization), and external services ( Stripe, Slack, Google Sheets, Airtable, etc) and use our pre-built UI widgets to build internal tools.

In v1, there are major changes in the architecture of ToolJet ( without affecting backward compatibility ). The changes in v1 are:

1. We ported the ToolJet server from Ruby to JavaScript. Codebase is now 100% JavaScript/TypeScript.

2. We altered the architecture to support extensibility. We built a plugin system so that any JavaScript developer will be able to extend ToolJet easily. For example, a simple plugin for connecting ToolJet with BigQuery can be built in less than 30 minutes.

3. Redesigned the application builder with a focus on usability. Added keyboard shortcuts such as undo, redo, deletion, clone, etc.

4. We built a commandline tool tooljet cli and published it on npmjs. The tool can bootstrap new plugins, add npm packages as dependencies for plugins, run tests for a specific plugin, etc. This tool saves time taken for building and testing plugins.

5. ToolJet was launched with 15 UI widgets. Now there are 35+ widgets including chart, map, QR scanner, list layout, file picker, etc.

6. Integrated with 20+ data sources including cloud storage like S3, GCS & Minio.

7. Added the ability to run JavaScript code snippets from within the client.

8. Added user groups feature and permissions based on user groups.

9. Redesigned the application builder completely. All the panels and tools have been redesigned with a focus on usability.

10. We also added collaboration features so that teams can communicate in real-time. The editor can easily become a collaborative workspace for building internal tools.

11. Added support for deploying ToolJet on more platforms including Azure, GCP, AWS EC2 using AMI.

We are still in our early days ( just 10 months old ) and there is a lot of features to be built and improved in the coming months and years. Feedback from the open-source community helped us get here, any feedback is appreciated and happy to answer any questions.