skysight-inc/HackerNews huggingface dataset:
> and there’s really good man page documentation now

Well, my pet peeve has always been git-tag. When I discuss about technical documentation, I actually use man git-tag as a reference of what NOT to do.

The summary (called NAME in manpages):

git-tag - Create, list, delete or verify a tag object signed with GPG

... which might make sense but is already confusing to a beginner because of its reference to GPG (are all tags signed with GPG?).

But DESCRIPTION is actually the best:

Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.

Unless -f is given, the named tag must not yet exist.

If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message.
Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message.

If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied.

Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.

A GnuPG signed tag object will be created when -s or -u <keyid> is used. When -u <keyid> is not used, the
committer identity for the current user is used to find the GnuPG key for signing. The configuration
variable gpg.program is used to specify custom GnuPG binary.

[... spoiler: it doesn't get any better]

So this should be a description that makes beginners understand git-tag.

Instead, it is a sequence of unrelated sentences that merely describes functionalities in response to command line arguments, in a very convoluted way (I think "If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied" is a little gem).

This is how I would write it:

Create, view, and delete tags.

By default, it creates a new “lightweight” tag, which is simple a reference to the current commit (eg: “git tag v1.2”). If you specify “-a”, a “annotated” tag is created instead; an annotated tag is still a reference to the current commit, but also remembers the date in which it was created, who created it, and optionally saves a message associated to the tag (like a “commit” message for the tag).

Annotated tags can also be cryptographically signed with GnuPG, using “-s” instead of “-a”.

You can also tag a commit which is not the current head by simply specifying it on the command line (eg: “git tag v1.2 abcde1234”).

Use “git tag -l” to view the list of all tags.

Use “git tag -d” to delete a tag.

So I think git still has a long way to go with documentation.
This comment is why people make fun of HN.
Git the ideology is great. Git the tool and UI are good for power users, but are abysmal for beginners and non-technical folk.

Github has done a lot to make it better, but even github is confusing for non-technical people.

We need some merger of tools like github with everyday applications. In the same way OS's provide a file picker, github should make a "branch/file picker and committer" so that regular people can contribute to things stored in git.
My parent comment was talking about "him" selling the company in 5 years. Your argument does not work against that specific point.
Ok, so this starts off as “Graphics for the JVM” which sounded promising, but then the first line starts talking about desktop apps and warning bells start going off. If you read the post, it’s totally fine…if you are trying to do fast drawing or something. But no, we’re making desktop apps, with circles and triangles and squares. This just isn’t how it works, and the reason is the same as it always has been: a drawing toolkit is not a GUI toolkit.

If you want people to make good apps, you need to give them buttons and checkboxes and text fields. If you don’t, we’ll, they’re going to do it wrong. Time and time again people have tried doing this and the best we’ve gotten out of it are game UIs and Flutter, which are a solid “mediocre” in the UI department. The former probably gets a pass because it’s allowed to be quirky, but the latter is literally run by a megacorp and it’s still struggling to get basic things right.

Heck, even Swing and HTML are better than this; at least they give you components that someone actually spent time on implementing and making half-decent. Maybe they suck, but they suck together in a consistent way that is at least partially battle-tested, a must for any GUI toolkit. They’ve gotten to the point where they’re no longer just a middle finger to people with accessibility needs.

Look, I don’t want to rain in this author’s work. If you’re going to treat it as an accelerated Graphics2D, go right ahead, this seems like it would be an excellent solution for you. JVM bindings to Skia seem awesome. Just don’t, like, draw something that looks like a GUI in it.

(I could go longer about the characterization of mobile apps as constantly being purged from RAM and losing your work and IntelliJ being a good Java UI, but that would probably make this divisive comment longer than it already is.)
Improving the Utilization of Micro-operation Caches in x86 Processors [pdf]
I just hope we don't get compromised CA because a lot of governments currently try to fight encryption.

But agreed, it is a good idea. The only disadvantage I see is that some sites might not want to pay for a certificate and don't know how to easily obtain free ones. So it might kill some sites.
Is this a problem? We're always going to need native blobs to interface with the OS. The JVM can package these native libraries within the jar so for the application developer it is indeed as simple as adding the jar file to your project.
Not for the market leader, and maybe not for number two. But if you're at the end of the pack, nobody buys from you and you look at the 10 billion people market you could get with a lifetime vaccine...

Which is why monopolies are bad. You don't have a pack anymore, and the leader(s) don't have incentive to do much disruption.
Part of the problem with git is that too much of the metadata around a repository (config, heads, remotes, branches, tracking etc) is stored in separate little files somewhere in '.git' This critical state of the repository should itself be version controlled so changes can be examined and rolled back in a clean consistent manor. Git has a reflog so experts can go dig around for the stuff you lost. Imagine if git were more like 'nix'. (that last statement might not help my argument for some of you ;-)

Read the various stores of git blunders in this thread with the idea in our head about how it would be different with this change.
Git should have been a library to create multiple compatible CLI/GUI implementations.
The Git CLI has become too bloated to use. It will take a month to read through the manual and learn all available commands. A well-designed VSC should not take that long to learn.
>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is.

A copy&paste of my previous comment:

Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain").

Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file format of BLOBs and SHAs, etc. If I were to implement a DVCS, I would inevitably end up reinventing many of the same technical architecture decisions that Linus came up with. But none of that insider knowledge really helps me remember git syntax if I haven't been using it in more than a month. Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes

The git UI and unintuitive syntax is just too hard for me to remember unless I use it every day.

Also to add.. the concept of "git index" as a staging area adds some complexity as well. Yes, there are good reasons for it (1) it lets one craft a specific subset instead of all changed files to commit and (2) it's a performance boost because a Big-O type O(n) loop runs faster when iterating through the staging index (small "n" of dozens) to detect changes instead of looping through the entire source code tree (large "n" of 10,000+ files in a big repo). But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". For a newbie, the extra indirection layer of "staging index" seems superfluous and confusing. That's why some present an alternative porcelain to git that doesn't expose the staging concept: e.g. https://gitless.com/

(To clarify, I'm not recommending Gitless but just giving an example of why some felt motivated to simplify Git's porcelain.)
You don't need to change config files.

`git remote rm origin`

`git remote add origin new-url`
That was... unexpectedly sweet.

But now that she won against cancer, she won't have to deal with it anymore. That was on the fine print, after all.
Congratulations !
Primary energy vs final energy: why replacing fossil fuels may not be so hard
The Magic of Gaussian Noise
A year doesn't sound too bad I think MySQL 8 has been generally available since april 2018 from Oracle

Honestly I don't know if they're even working on MySQL 8 for Aurora MySQL
It's a testament to where you work. If you worked in sweatshops firms, who effectively hire anybody who is willing to work without any sort of coding test, there is an amount of developers there who are incapable of developing anything.

If you worked in startups in the valley, there's usually a pretty decent high technical bar to hiring.
"There is still a chance that between since the last git pull command someone has pushed a new commit. In that case a merge will occur in your history." If you want to prevent these merge commits (I do, I think they're really ugly), you can add git config --global pull.ff = only
Mobile app is serviceable, not fantastic. On iOS if you tap on an email notification it'll just open the app showing some old email, not the one I just clicked. Why?

That said, I'm a very happy paying customer.
Unix Philosophy and EDC
Pretending to be a user is a good way around some anti cheat systems as well.

The computer game FIFA has an online marketplace where you can buy and sell players, and a lot of people write Chrome extensions (or Puppeteer bots) to "script" hotkeys or create sniping bots, but since EA track you constantly, they can figure it out eventually. Instead, I wrote some code to control the mouse and keyboard with cliclick (https://github.com/BlueM/cliclick), move the pointer around naturally, etc. and you can leave it running for hours without incident. https://pyautogui.readthedocs.io/en/latest/ is another approach to doing this for any Pythonistas in the house.
Not at all! Desktop apps require platform-specific executables and installers so this is unavoidable. But the author made it sound like a piece of cake for developers used to making JAX-RS services.
This is great, but even if it is not really in the scope of the article, it's extremely important to know how TikTok makes money. Maybe an external link?

Also, anyone else remembered that scene in Idiocracy? (Not that Tiktok is likely to be as bad...)
'We Are Shipping to the U.S.': Inside China's Online Synthetic Drug Networks
Have a look at Let's Encrypt DNS challenge. I created a DNS wildcard certificate for a subdomain I own and use it for all my internal domains. A great way to get HTTPS on non-public networks.

HTTP over VPN is still weaker than HTTPS over VPN. For example HTTPS also handles authentication which HTTP doesn't. If you're outside of your VPN, a MitM could redirect you to http://my-internal-domain.example and resolve its DNS to an attacker's website. Your browser would not understand the difference between this and your actual website in your VPN. It would send all the site's cookies to the evil website, and if Service Workers[1] worked over HTTP, this would actually be a way to completely compromise an internal HTTP website. So it's important not to whitelist such HTTP sites as if they're secure.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
Its not always the code you work on. It might be other internal services or sites.
"Peeping Tim", Apple that is, has a nerve. The mass surveillance should be investigated.
Aperocky's comment you were initially responding to asserted, correctly, that "The worst hit place right now is the ~United States of America."

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

You chose to redefine "worst hit", after two rounds of failing to clarify your criterion, as "deaths today".

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

That basis entirely dismisses the facts that:

1. Cases today translate directly to deaths in the 2--4 week future, at a best-case rate of 0.5% CFR and far more plausibly 1.5--3% CFR, based on present reported cases.[1]

2. US new cases per capita are at least on par if not worse than Europes's.

3. EU daily case rates are trending at worst flat, and are generally decreasing.

4. US case rates are rising, at an acellerating rate.

The US today reports 158,363 new cases (7-day average), and a 3% CFR. In ~2--3 weeks, likely daily deaths will be 2,375--4,750, or 7.5--15 per million.[2]

Germany, to use your favoured example, reports 18,363 new cases (7-day average), and a 2% CFR. In ~2--3 weeks, likely daily deaths will be 367--550, 4.4--6.6 per million.[3]

All Europe reports ~220,000 new daily cases (16 Nov 2020, not smoothed). in ~2--3 weeks, likely daily deaths will be 3,300--6,600, 4.4--8.8 per million.[4]

To provide an analogy, you're laughing at Europe being in a ditch whilst the US is racing toward a cliff's edge. Assessments of present health or wealth must include obvious future consequences or risks. You entirely ignore these, and reframed the initial criterion to do so.

Your analysis suffers from presentism and risk blindness and is utterly flawed.

________________________________

Notes:

1. I'll ignore the fact that reported fatalities undercount true COVID-19 fatalities as demonstrated by overall excess deaths by about 30% per an August 2020 New York Times report and other independent studies and data.

2. Using 1.5--3% CFR.

3. Also using 1.5%--35 CFR, despite Germany's lower experienced CFR.

4. Again at 1.5--3% CFR. Based on reported values, whic undercounts recoveries, experienced CFR is ~4%.
How to not reissue 100,000s of EE certs after the Dangerous Delegated OCSP issue
I route my domains through cloudflare for this reason. Just makes life easier for my <1k visitors/month sites.
Git is hard if you don't take the time to learn/teach it.

As a checkmark on a resume, knowing git doesn't mean much. Most developers know how to branch, commit, push and pull. Maybe they know a little bit of reset to get themselves out of bad situations.

We had one highly-skilled developer with a background in contributing to very unrelated FOSS join a frontend team once, adding a rule about avoiding merge commits in PRs. Within a month or so they all learned how to rebase and cherry-pick.

Git as a skill needs to be taken more seriously, not something you learn on the way to doing actual work.
But you should close it if they made it easy for that purpose.
So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful).

Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios.

And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for the same question, highlighting just how much inherent complexity there is in the product.

Managing software versions across repo can be a very, very complicated problem. Git provides you with a pile of tools to do 'almost anything'.

A 'well designed product' would make the toolsets and concepts focus heavily on the 'main operations' and then have clear, clean rational idioms, practices and tools for the odd cases, and 'dangerous cases' wouldn't be allowed without some kind of special command.

They have the 'Golden Rule of Git' which is to not rebase on a public branch - this is an excellent example of poor product design. There should be no 'golden rule' that developers have to understand - it shouldn't be possible (without special admin commands). If branches are named/tagged and managed properly, the system would be smart enough to let you know you can't do that, and why.

Administrators exist for a reason, 'sudo' exists for a reason etc.

People who love powerful things, and have an inclination towards complexity seem to love git, people who have a product orientation see it differently.
Tables are better as well in the sense that they are a higher level representation than divs. The problem was that people were then using tables as a way to layout pages rather than to use them to display tabular data.
Also old != will last forever
This post is only about the Skia JVM bindings and that is indeed only the graphics layer. What you are looking for is Jetbrains Compose which is built on top of these bindings and provides the GUI toolkit.
> with a lot of quality and performance drawbacks. They were so significant that only one company managed to build a decent-looking app in Swing [Link to JetBrains].

Until I found the J-editor, I sort of agreed. I never understood why that project didn't get any traction; very well made IMO, and it looks good too.

https://github.com/gnooth/j
If you're ok with fronting your sites with Cloudflare you can get "fake" HTTPS by using the flexible option (HTTPS from the client to Cloudflare, and HTTP from them to your server)

This satisfies the need to be on HTTPS, without actually having to change anything in your server.

Not saying this is ideal, but for websites that don't _need_ it it could be the best/easiest approach.
Apple messed up by not engaging and assissting relevant software vendors with this change in time...
> The Git CLI has become too bloated to use. It will take a month to read through the manual and learn all available commands. A well-designed VSC should not take that long to learn.

I think the git cli is a classic example of the 80:20 rule: 20% of the commands make up 80% of typical usage. While it may take a month to learn the entire git cli you can get up to speed with the basics in a few days and then dive in to the other stuff as and when you need it.
It doesn't completely block users from your site. It just makes them extra aware that any middleman will be able to see what they are reading, see anything they send and could possibly modify the traffic.

If you are concerned about the power-users who enable this being aware of these facts then maybe you do need https after all.

(Of course I suspect this mode will be made the default at some point, but that is probably at least a couple of years off.)
Your phrasing is definitely a better initial starting point. I do think that my phrasing has its place if a non-answer is given after the second or third time.

Your follow-up questions are great too.

This sort of dialog / FAQ for “what do you have to hide” needs to be available somewhere online with a catchy URI e.g. https://privacymatters.org (I don’t know if this is real just an example).
It's already common to use unsigned documents in court, as long as you can show provenance is legit or if the counterparty is willing to acknowledge authencity.

In fact, it's quite common that the issue over unsigned documents in court is the interpretation, not authencity.

I think the issue of having to teach users how to opt in to signing emails in potentially controversial cases is preferable to having to teach them how to handle email communications that are permanently provable (for starters, never ever again leave out a quote and never ever write ambiguously).
It's not user controlled if it is on by default.
It tracks all the lags there! Perfect, thanks!
Git also sucks when someone in your team drags their feet and doesn't use it properly. And when your team is mostly made of non pure comp. science background who have learnt SQL on the job, trying to get them to stick to git is really difficult. There almost needs to be something in between that satisfies this kind of intermediate technical ability and interest.

I think Atlassian could come up with something suitable.
For many and most physical keyed locks, you can decode the lock with special picks or impressioning tools. It can be pretty time and skill intensive though.
If indeed there is a mafia-controlled black market in ticket sales, perhaps the mafia got a corrupt bureaucrat to use state force to shut down competition.
In many country's such software is illegal and you can be held accountable, especially if you provide it in a way which makes you earn money.

If you make sure your software is just more economical/accessible without giving a unfair advantage is often less illegal or at least tolerated in many counties.

And many counties include EU countries like Germany.
Some Clojure libraries have a hard dependency on Java (or JavaScript, in the case of libraries supporting ClojureScript) - Clojure does not cover all use cases. For example, if you want to do anything more complicated than find-all-matches with a regular expression you need to call the underlying Java classes from Clojure. I expect this is probably the biggest obstacle to getting Clojure on CLR working properly: the language is not the issue, the libraries are.
Why are you lying? Do you work for Apple?
Cross compilers are nowhere near the same as Docker on ARM Mac building x86 Linux containers. The biggest difference: no one expects you to be able to run your MIPS binary on the machine you built it on.

Edit: although sometimes you can through qemu.
Personally, I use Ansible for provisioning my Vagrant VM. It's not what it was made for, but I enjoy being able to write the provisioning in a self-documented yaml file using Ansible modules for helpers, instead of writing a shell script to set up the machine.
Of all the parts invloved in setting up a web server, is adding a letsencrypt a significant further barrier? In what situation would a non-tech-savvy user ever be doing that in the first place?
Well, quite, but that doesn't obviate the point. What you're describing has an exact corollary: "Saying FP is not as good at handling state as OOP just shows a lack of understanding of FP, of structures such as the state monad."

Yes, using strict patterns to deal with the weak points of the overall paradigm is absolutely fine, but it's patching over cracks rather than using the best tool for the job. OOP is very good at handling state but less good at pipelining data, FP is very good at pipelining data but less good at handling state.
Which is a poor choice of name because it requires some knowledge of the parent company in order to know whether the first letter is an 'i' or an 'l'
I agree and I want to add that I particularly appreciated how you consistently, in programming terms, communicated the type of things. Eg:

(proves a b)

So far saying “the sequence with the Gödel Number a proves the formula with Gödel Number b”

In my experience, most mathematicians would have instead written "So far saying 'a proves b'". Repeating the type of the parameters consistently made it significantly easier for me to follow along. I hope this becomes more common.
The phrase that I hear often when complaining about git: "Git good".
You're attacking a strawman here. The issue was that he was making a profit by reselling tickets, not by automating filling forms in a website. The mechanism is not particularly relevant.

By analogy, it is legal to park my car in my own garden, but not legal to park it in my neighbour's garden. If I were to do that, I might expect to be punished for "parking my car".