skysight-inc/HackerNews huggingface dataset:
tl; dr: jekyll-last-modified-at, a popular plugin to get the last modified time of a file for a Jekyll site, was causing slow generation times so I wrote a more performant (~70% time reduction for full site regen) alternative at https://github.com/klandergren/jekyll-last-commit, and you get commit info like author, date, and message.

I have a 1000+ page Jekyll-based site that was seeing slow generation time—on investigation I discovered the plugin jekyll-last-modified-at was spawning a new process _for every page_ to determine the last modified time (via git commit history). Even after using Jekyll's --incremental option—which has its own issues like needing `regenerate: true` in the front matter to regen on data changes—this was still too slow.

So to address I did two things:

1.) opened two PRs to improve performance, both referenced from this issue and available to try out: https://github.com/gjtorikian/jekyll-last-modified-at/issues.... these were done in the style of the existing codebase and basically just improved caching and switched the git invocation to a single bulk call

2.) created a new plugin https://github.com/klandergren/jekyll-last-commit that uses libgit2 (via https://github.com/libgit2/rugged) to interrogate the git repository directly.

Implementation details available in both places! Up to you which approach works best for your setup.

Notes:

* this is only likely relevant to you if a) you want additional commit info beyond date or b) you have a very large Jekyll website (many 100s of pages that each need last modified date); for smaller sites the performance difference will likely be negligible

* performance will vary based on how many files you have and how frequently they change throughout the commit history

* the original PRs were done in 2021 and the plugin was written in December of 2022 when I wanted to play around with publishing a ruby gem

* this was a pretty quick project—if there are issues or errors please report them!
When I was studying tax law in law school, I remember learning that the earned income tax credit (commonly "EITC", but referred to in the report as the "anti-poverty earned income credit") is notorious for being filed incorrectly at a very high rate. This is due to the complexity of the credit and the fact that the people who are eligible are less likely to have a paid tax preparer.

On its face, this article looks like it has "discovered" that people who claim the EITC are audited at a much higher rate than other people. This is not news to anyone who works in tax or tax policy.

It would be different if they had shown that the EITC audits were not warranted — that would be very newsworthy. But if they are auditing people and finding that there are mistakes that need to be fixed, that's not evidence of wrongdoing.

It could be evidence that the EITC should be simplified — something that tax policy folks have been saying for a long time.
Maybe most of the good products come out of places without too many C level types :)
Taxation is not slavery.
It isn't about difficulty. It is about compliance.

People who haven't complied with the law for their filings are going to get targeted more.
Yes, absolutely. Also evading sanctions, buying prohibited goods etc.

To remind, most people in the world live in countries with oppressive governments.
To report a bug would cause almost a hara-kiri I can assume. It's a crazy evil society where anybody had to commit hara-kiri. It doesn't help anyone if you kill yourself. If you want to atone for your sins better do it by working harder. Is that a major difference between East and West? Is that a benefit of Christianity that you can be forgiven for your sins, once you admit them?
I have a group of friends who looked at the BBC article talking about this RTR MOU - https://www.bbc.com/news/business-64206913 - and after reading it, were claiming confidently that it helped push forward right to repair in a good way - I actually spent the time to look at the MOU the article linked and knew right off the bat that it was a load of crap, only meant to extend an easily broken olive branch to farmers. (Right at the bottom, look who is signing the MOU - "SALES AND MARKETING VP" - gee, why isn't it a CEO, or the board of directors?)

It's cementing my personal opinion deeper and deeper within me that that the media is directly responsible for forming the viewpoints and ideas of a huge amount of people - and they're violating this responsibility in huge ways by having inexperienced/irresponsible journalists and journalism - not to mention the corporate and governmental meddling that's pervasive to journalisms core.

It's somehow become a foreign concept though it wasn't long ago that you could take your TV, vacuum, appliance, computer, small electronics, into repair shops and have experienced, knowledgeable people able to diagnose and repair problems quickly and efficiently. Sure, electronics have gotten more discrete, smaller, harder to replace without specialized tools... The concept is still the same despite what these massive corporations tell you.

Apple "supports" individuals by allowing them to pay for a massive/heavy shipments of tools, equipment, instructions, etc. to replace parts on your devices - when they could just provide easily available parts like chips, boards, screens, etc. to third-party repair shops (not "apple-authorized" that come with all kinds of riders and caveats). All so Apple can look at legislators who don't understand intent of laws and societal desires and say "Look, we're trying! We support RTR!"

John Deere is pulling the exact same thing - and the media is playing right along with it.

It's economically cheaper and more advantageous to go through all these motions to extend this fake peace offering to farmers and have the media convince everyone that it's 'actually really totally right to repair guys' while at the same time controlling absolutely everything in their supply chain so they make profit on their devices at every single corner of market capture - sales, repair, maintenance, customer retention (oh dang, it's too expensive to repair my tractor/phone because the part/board costs 40-50% of a new device, might as well buy a new one!)

It's a disgusting anti-consumer practice and it's only going to get worse.

The one good thing about inflation and consumer electronics being more expensive long-term is we might see legislation that forces companies to actually allow consumers to repair and maintain their devices, with access to parts, schematics diagrams, etc. etc. I somehow doubt it though.
It's not that they have documentation as much as it is that the tax code is more subjective for high earners that run businesses, because what is an isn't a legitimate business expenses or R&D or whatever is not always clear cut, and the tax code gives a good amount of leeway. And even when it doesn't give much leeway, it's still a lot of work for the IRS to prove their case unless the fraud was explicit and deliberate.

The tax code is this way on purpose. It's designed to encourage businesses and people to spend.
It's sad how many russian people fall for the western narative of "a better life", not realizing how many benefits they have in their home country.
Ask a heroin user. They clearly want to, and right now they have to deal with some unsavory characters and products.
Yeah these are based on numbers from Levels, which is known to report salaries from top tech companies. I'm sure numbers from BLS or even something like Glassdoor are far more accurate when thinking about the industry as a whole.
How does this differ from NOAA weather.gov api?

https://www.weather.gov/documentation/services-web-api

Or is this a friendlier overlay of their interface?
It really depends... I'm sure they're not going to be using one single key for everybody; it'll be 802.1X, which a lot of devices don't support.
Xenocara under OpenBSD and Hyperbola don´t run as root.
Ah, that's part of the root of this issue - we don't know based on the facts in evidence if this is a widespread concern or not. We only know that it's a concern to those three people.

As you can see, there are more than three people in this thread alone who feel strongly in the opposite.

It seems to me the right things to do would be for the ASF to reach out to some Apache organizations to ask their thoughts, and for the article authors to approach (or create, if necessary) similar representative groups to make a formal statement of position.
A hydraulic piston, which can be a hand powered jack, and a rifling button makes it possible to easily rifle most any metal pipe.

Plus in 99% of shootings the targets are fairly short range where rifling isnt even very important.
appears to pretty much US only, unfortunately. it's -5 where i am right now, but this claims that it is actually -17 (a very big difference)
I hit a question limit on the last attempt, which I've never seen before.
While that may be the case, it is still evidence the government is ideologically captured by activists and willing to spend money on nonsense.

Hard to imagine healthcare is run on a lean, waste-free budget with that sort of stuff.

(Cue discussion about covid rationing involving "equity" considerations, etc)
This is just wrong. MathML is not about notation, it is about rendering. Notation is secondary (as is evidence by the number of translators out there). Having native rendering yields numerous benefits including:

* Less works for developers who no longer need to pick, integrate, and maintain a third party library for rendering.

* Faster user experience, as the MathML code can be served directly and rendered by the browser (as opposed to parsed and rendered with the javascript engine).

* More options. Maybe LaTeX is not the right choice of syntax (more people write math then professional mathematicians and PhD students). As translating to LaTeX is hard, translating to MathML is easier (I know, I’ve written one my self).
It's no work at all to go from regular language to context-free language, and a whole lot more work (parsing) to go the other way.
[Deleted for my poor reading comprehension].
Have you seen https://github.com/MicroCoreLabs/Projects from

http://www.microcorelabs.com/about.html ?

Some of them implement 'Microsequencing'

( https://en.wikipedia.org/wiki/Microsequencer ) which could maybe be useful?

Conceptually, I mean.
Standard topics for me are:

1. What's up? (chewing the fat about any relevant life topic)

2. My frustrations with the process and possible improvements.

2.1 Followup to recent changes in this area.

3. Experience with recently developed/released features.

4. Follow-up to company wide changes (related to things such as layoffs, direction changes, etc.)

I used to not be a fan of 1on1s while working on-site but since I've started full-remote it has become more valuable time for me since that's basically the most time I spend with my lead in a sprint or two.
Unity Developer | Walking Tree Games | On-Site in Karlsruhe, Germany | Full-Time

We are Walking Tree Games, an independent development studio from Karlsruhe/Germany. We are looking for a Unity Developer (f/m/d) to join the team for our upcoming PC strategy game THE TRIBE MUST SURVIVE.

Apply here: https://thetribemustsurvive.com/jobs.html#unity-developer
I'd suggest at least some amount of small talk updates. Being a person to each other is a good way to develop a good relationship and have sympathy for one another, which can improve working relationships to no end. Doesn't have to be artificial, just share some thing about what is going on with you (but keep it positive), and listen to their personal update too.

I'd also use the meeting to signal any feelings you have about the direction of the team/company, as well as ensuring that your view of where the work is meant to go is valid. Keeping everybody with an aligned idea of goals is important when you're collaborating.

If you feel the need for a deep dive, I'd suggest picking a single topic before hand to ensure that the 30 minutes is used effectively, but I would say that if they're a manager that getting technical is probably not the goal here. As a manager, you want to know about risks and opportunities to make future decisions. I'd aim it at that level.

I wouldn't worry about blowing your own trumpet - you're going to be your only advocate here and you'll be competing with others that do.
Doubly so given that they simply don't have the political leverage to repeal the policy in question over the preferences of the Senate or incumbent administration. This is less of a policy goal than a campaign issue designed for pay off in the 2024 election.
What part of that video are you referring to? I also don't use dishwasher pods, if that's part of what you're saying.
People joke about militaries writing docs about the exact number of turns each screw can take, but a-10 are still airworthy and the last one was built in the 80s

Quips aside, software life expectancy matters, so total documentation approach is not something that works for everything. But if your software has generations of developers, maybe it's worth thinking about it.

That or a total rewrite every skip generation. I can see both working, and maybe total rewrites are a better approach in a world of ever changing requirents.

Thing is, documentation is great to capture static knowledge, and a evolving software is not static by any means

If I had to pick and choose, I'd say written requirements with change management for every domain object APIs within the software object model, and anarchy underneath.

The code conforms to the requirements, and not the documentation conforms to the code, so to say. Contract driven, in a way, but only where it's relevant.
> or, through inaction, allow a human being to come to harm.

This has always felt like a gaping hole to me. It seems like to work it would have to a) always make perfect predictions of the future, and b) agree with relevant humans what "harm" is.
They roll pretty well until they get mushy, then the seeds are pretty easily dispersed by rain. And the mature tree does really well on hillsides/near streams. So maybe water is the answer?

Also, I'm certain that something ate them. I've personally seen Squirrels, groundhogs, horses, and cows eat them.
Not trying to be dismissive of your approach either. While I can think of ways it might cause problems in theory, I really have no idea how likely those problems would be in practice.

> I did consider that myself but I didn't want to manage sockets in addition to processes, plus file descriptors would be idiomatic to pipelines.

A socket is just a file descriptor at the end of the day. Some shells (I think some variants of ksh?) have actually used socketpair() to build pipelines instead of pipe().

> the environmental variables might also be carried over, so how does that grandchild process get restricted from writing to the socket?

Unix domain sockets let you know the PID/UID/GID at the other end (SO_PEERCRED, SCM_CREDENTIALS, etc). So when the shell gets a connection, it can tell whether it is coming from one of its direct children, or a grandchild.

However, I'm not sure if one actually should restrict subprocess. If a child process spawns a subprocess, why shouldn't the subprocess be allowed to negotiate the input/output format, etc? The parent process might just be some kind of launcher and the child might be the one that does all the actual work.

In any event, what's to stop fd3 being inherited by grandchild processes too?
> ...because I can find a library that solves the problem I am working on.

I couldn't find it, but is there a "Rosetta Stone" of language ecosystems, where in a "libraries" section it lists Python/Go/Rust/Ruby/Perl/Lisp/etc. library near-equivalents?
Surely that vision is exactly what (vanilla) Gnome is? On Desktop and on Mobile (with LibAdwaita). Incidentally they also seem to get a lot of criticism for having a strong vision.
Managers dont have the time to figure out if someone did something well or poorly. The code works and so they move on. Certain people leave a trail of bad code with nice looking syntax. Working directly with them, it will be obvious, but otherwise forget it, you will never figure it out. All it takes is them speaking well in meetings/good at project planning/BSing some design.

The result of their bad code is future changes take 2x-3x as long. But no one can tell if those timelines are just what they are, or that there is a problem with the existing code.
You know what they say, economists have predicted nine out of the last five recessions. This has the same energy.
Under “Weather Sources”

> All weather data comes from the AWS open data program https://registry.opendata.aws/collab/noaa/. This is a fantastic program, since it is more reliable than the NOAA distribution, and means there are no data transfer changes!
At my previous job, my manager and mostly of my colleagues was 7 hours ahead, so I was struggling a lot in the first months and I was feeling a bit abandoned.
Then me and my manager, agreed to have a regular 1-1 weekly meetings to discuss the open points and the difficults that I was facing. This was a big improvement for me but also for him to have an idea of what I was doing.
We also discussed about strategies and roadmaps in our projects and sometimes about our future because we faced at least three fully reorg starting from C-level. He also gave me some feedbacks about my job and my approach.
For me this weekly hour was a gold mine.

My actual manager is in my timezone and the whole team usually meet everyday for a 30 minutes daily sync, so no need for a dedicated 1-1.
User as in reader? That's definitely not true. It becomes integrated into the document (vs a rasterized image), can copy/paste, etc.

User as in author? That's true, but latex -> mathml conversion already exists and is decent, and will get increased attention now that the major browsers all support it to a baseline level.
Utility scripts in Ruby can be very powerful, but also very messy. In this episode I showcase dry-cli, to help you maintain advanced ruby CLI programs.

Wondering, what is your approach to this?
haha, worth a try
"As a counterpoint, my experience has been that having a recurring 1:1 on some cadence makes it feel less weird to flag an issue."

Agree with this completely, and is something I always introduce straight away with my team.

If someone stops me in the corridor
/ sends a slack to say "Jim's tapping drives me nuts" (as a lame example), then it's now a big thing. I have to stop what I'm doing to establish how much of a problem it actually is, and how soon I need to deal with the issue. It takes a lot to interrupt someone for something that potentially is a small, yet personally important thing, so people are less inclined to do it.

If instead, at the end of a regular scheduled one on one, as we're winding down, at the inevitable "anything else" stage, someone mentions "oh, yeah, small thing, but Jim's tapping drives me nuts", then we can discuss and establish a path forward in an open environment. Invariably they feel listened to, we can decide a way to approach the issue, and it's far less dramatic.
I like having an open API. Every weather site eventually becomes trash as it is loaded with obnoxious ads. Maybe the answer it just to have numerous weather front ends.
MathML has more capabilities than the ad hoc notation of LateX simply in virtue of being XML-based. Whether these capabilities are ever realized is another question, but LaTeX had a pretty big head start and better tools.
We've had 3 years of reduced exercise, and people are 'making up' for being cooped up by engaging in more activities that they couldn't before. Taking those road trips, going to that amusement parks, snowboarding, mountain biking, etc.

Not to mention supply chain shortages in medical and medical-adjacent fields, paramedics, etc. at a time where some people have overlooked long COVID symptoms

As well as an economic depression at a time where we're suffering a cultural PTSD from the previous few years.

Even if COVID isn't found directly responsible for these deaths, I suspect it is indirectly responsible.
> and I wonder if a better one could be imagined + implemented...

There is a ton of data using industry defined conditions and a ton of research has gone into determining the types of conditions that can affect accident rates. The only reason we can't compare is because Tesla only releases what we see in the link above. [1]

Best guess estimates of normalizing autopilot data against the average mix of highway/city driving finds that AP's safety advantage effectively disappears. Of course this is rough and Tesla likely has much better data that they are choosing not to share. [2]

[1] https://www.iihs.org/topics/fatality-statistics/detail/urban...

[2] https://twitter.com/NoahGoodall/status/1489291552845357058
Thanks for introducing me to MoCA! Gigabit magnitude networking over coax that can coexist with DOCSIS sounds exactly like what I'm looking for.
Yes, Congress passed the Weather Research and Forecasting Innovation Act back in 2017 which not only gave massive funding injection to model development activities, data procurement, and more, but also formalized the new next-generation community modeling initiatives which are focused on tackling the dominance of the EC models in the 2-5 day forecast space.

The diagnosis of the problems of the American forecast modeling community here is based on flawed premises. There are three major factors which led to the ECMWF leap-frogging the US in day-ahead forecasting capability. The first is the consolidated investment in supercomputing resources; the WRFIA tackles this by earmarking a much larger allocation of funding for NOAA's next gen supercomputer, but this still pales in comparison to ECMWF investments.

The second factor is the fragmentation of the research and operational weather modeling communities due to the divergent investment from NOAA and USAF in the 90's and 2000's; USAF in conjunction with NCAR sponsored the development of the WRF model which was widely adopted by the research community. NOAA continued investing the GFS lineage of models. The bifurcation of these communities slowed down the ability to matriculate advances in model developments to operations, and this was exacerbated by an old, closed-off approach by NOAA which made it extraordinarily difficult to run and develop the GFS on anything other than NOAA hardware.

Finally, the ECMWF went all-in on 4DVAR data assimilation in the late 90's, whereas the American community pursued a diversity of other approaches ranging from 4DVAR to ensemble Kalman filters. 4DVAR necessitates advances to core weather model software (e.g. you need to write a model's adjoint or its tangent linear in order to actually use 4DVAR) adn the US' failure to adopt it led, imo to a "double edged sword" effect of (a) failing to provide impetus to greatly improve the US modeling software suite and supporting tools, and (b) being a worse assimilation technique unless advanced EnsKF techniques are employed using very large ensembles of models (expensive).

The other problem as others have pointed out is that there is no accountability in the US private sector weather market. Virtually every player is re-transmitting raw model guidance or statistical post-processed forecasts using DiCast, _maybe_ with a some manual tweaking of forecast fields by humans. But this is not transparent, and many companies - if we're being charitable, here - are not honest about what they're actually doing to produce their forecasts. Put another way - there's a lot of BS claims out there, and it seems that investors have been more than happy to fund it over the past few years.
There's probably no reason it canont be done; the fact that Dart is doing it is because some language was needed for Flutter and the Flutter team chose Dart. In other words: cross-platform UI was the point, not starting with a language and then strapping a cross-platform UI to it (looking at you, Xamarin/MAUI...).