skysight-inc/HackerNews huggingface dataset:
WildBit had a really cool project a while ago called Conveyor. [0] It’s a shame it never took off.

It was built on git, but hid the complexity of branching + other git things behind “tasks”. You’d start a task, and silently push that branch out to everyone. It’d silently merge things in the background and handle a lot of the chores you have to do with git rebasing and such to keep branches mergeable.

It failed miserably with us because it perpetually created impossible to solve git issues. Someone accidentally removes a gitignore file and commits a config file with a password? Your SOL. It will keep coming back because it will exist on at least one other person’s device which will get force pushed back to the repo.

The weird plumbing exists because version control is hard, and prone to humans throwing wrenches into its nominally perfect system.

The real reason you don’t remember every magic git incantation is because you normally only need a specific one, once a year. But it has to be there!

[0] https://web.archive.org/web/20190226201600/https://conveyor....
I think car manufacturers are reluctantly coming around to EVs because as you said staying with gas cars is unsustainable (how many hundreds of billions of dollars of government subsidies and bailouts has GM consumed just to stay afloat to date?) -- but there is still a fatal flaw. Car dealers will never get on board with EVs. It represents an existential threat to them. Most of their profit comes from service, and EVs require much less service. The problem is that (most) car manufacturers are not allowed to sell to anyone other than car dealers. (State franchise laws require you to sell 100% of your cars to dealers if you have any dealers at all, and except for Tesla and some other EV startups, all the car manufacturers already have dealers.) So there is going to be an indispensable component of the automaker supply chain which will continue to be part of the anti-EV conspiracy indefinitely for the foreseeable future. Dealers also pay for more advertising than the carmakers themselves, so the media will keep fueling the fire as well.
> There is no reason to discredit his claims as "false"

I'm just pointing out that he made false claims. I'm not concerned with whether it was intentional - many of the claims he made in the book was false. Some of the premises he attempts to support were supported with conflicting information.

I simply wouldn't trust anything he's written in that book unless he republishes it with the corrected information, and retracts the mistakes. Has he done so?

The fact that he allows the book to continue to be publish and circulated is enough for me.

Also, he's been found citing his own books in his research papers - nothing shockingly wrong with that, but poor practice as far as research goes.
Friendships at work can boost happiness
I wonder if there’s a shoe insert one could make that would poison gait analysis. Something in your shoe that gives you a different limp every so often. Lift your heal a little or put a lump under the ball of your foot.
The ordering of the arguments changes behavior, I don't think that's a good thing or desired outcome, at most it's a bug_feature.

It tend to happen when big project rolls out batteries itself, in this case command line parsing.
I disagree. We shouldn't have to know how a branch or commit is stored. Whether git interally makes a new ref, copies everything to a new directory, or does some hashing magic doesn't matter to the user.

I agree that we end up needing to know about refs because of git's user interface, but I consider that a flaw or limitation.
From the changelog [1]:

> - DTS to PTS reorder bsf

Interesting, I wonder what this is / why you'd want it. In particular, when you have the DTS but not the PTS.

The recent gstreamer 1.22 release [2] had what I read as the opposite—calculate a plausible DTS from the order and PTS. They did a nice job of explaining why it's useful. AFAICT, this approach is the only viable way to get B frames to work properly from a received RTP stream.

> H.264/H.265 timestamp correction elements ... Muxers are often picky and need proper PTS/DTS timestamps set on the input buffers, but that can be a problem if the encoded input media stream comes from a source that doesn't provide proper signalling of DTS, such as is often the case for RTP, RTSP and WebRTC streams or Matroska container files. Theoretically parsers should be able to fix this up, but it would probably require fairly invasive changes in the parsers, so two new elements h264timestamper and h265timestamper bridge the gap in the meantime and can reconstruct missing PTS/DTS.

Looks like the ffmpeg thing is dts2pts_bsf.c. [3] I haven't really read the implementation, but I was hoping the comment at the top would illuminate things, but "Derive PTS by reordering DTS from supported streams" isn't enough for me.

[1] https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/rel...

[2] https://gstreamer.freedesktop.org/releases/1.22/

[3] https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/rel...
TVs are consuming devices. If you are only wishing to consume git, you need to know "git clone" and "git checkout", and that's it, no need for internals. Or manybe not even that, you need to know where "download" link on Github interface is.

If you are encoding video, you often need to know about chroma subsampling, and colorspaces, and fractional framerate and all the other absurd technical details. It is actually much worse than git.

You can avoid those technical details if you use high-level software, only stay on happy path, and avoid any complex operations. You'll take longer and produce worse quality output than if you had fully mastered the software -- but often this is OK.

This is true both for video encoding and for git.
Related (but not as widely known as Slotin/Daghlian):

https://en.wikipedia.org/wiki/Cecil_Kelley_criticality_accid...
This article makes an explicit assumption: that code that is easy for you to read at a glance is inherently "good". The article then makes weird quasi-moral judgements like, maybe if you are a single person writing difficult-to-read code then "maybe you just don't need to write good code". Code that is optimized to be easy to read often has lots of duplication and very little abstraction.

This is even a well-understood tradeoff, and is why people working as cogs in massive organizations are often expected to code in languages like Java, Go, or C, which all purposefully offer very little in the way of abstraction, so the code is somehow more "obvious" and easier to read by whomever comes into the codebase next and needs to rapidly make some kind of change without breaking stuff.

The problem is... this is actually really shit code. The more duplication you have and the less abstraction you have leads to way more places for bugs to creep in. Yes: having the weird unified mechanism that no one is used to to handle memory management or authentication might seem a bit annoying when you sit down to someone else's code, as they are effectively using a bespoke framework.

But, let's reframe that: they are using a "framework"! And it probably has some kind of internal logic, and was likely designed for a reason to solve a real problem! If you take a few moments to orient yourself in the codebase, rather than assuming "I don't understand this so I guess it is bad code" you might come to understand it and then appreciate the work that went into the abstraction.

The alternative to this is frankly code that I enjoy, as I'm a security engineer looking for bugs: I'm going to look for things that are duplicated for bugs that were fixed in one place but not the other or for correct--yet somehow slightly different--behaviors which lead to parser differential vulnerabilities; even just boilerplate: the chance you got it right everywhere is about 0.
Future Internet PKI schemes need to be bootstrapped through web PKI
The authoritarian Windows PC in the workplace didn't let me dial the color the way I want. That was before the recent firings at Redmond. All window managers need to let users adjust the color, especially the absolute #ffffff white. Because eye hurts.
For Safari, there is port for this called Vimari
https://apps.apple.com/us/app/vimari/id1480933944?mt=12
APIs cost more than people think. On the small scale it doesn't seem like much, but then you have to account for the abuse cases. After that, you have to deal with the regular scaling, and eventually legitimate high-volume users. After a while, maintaining the API itself becomes a project of it's own. Keeping it cheap as your product gets bigger is another task, and maintaining parity/versioned endpoints adds more pain on top.

For a lot of products, the cost-benefit analysis doesn't align with exposing unlimited free APIs. We see this pretty often with data that scales beyond simple static metrics like weather updates or RSS feeds.
https://archive.is/pkLcH
LastPass - The gift that keeps on giving
> nvenc AV1 encoding support
> QSV AV1 encoder

That is captial 'A' A W E S O M E.
FFmpeg is always on the bleeding edge, love it.
> None of these can be understood if you think that a branch is nothing but a ref.

To the contrary - all of these can have "branch" changed to "ref" and they still make perfect sense. "ref" is just as much a sequence of commits as "branch" is. Every commit is.
Good stuff. Some suggestions:

In "hyped for you", remove the name of the company, and expand the game description to another row. Add tags. Remove the lightning bolt icon. What is that even? No, don't explain. Just remove it. If it isn't worth sorting by, it's not worth showing.

Describe what this website does, on the website. What it does exactly. Pretend I'm 5 years old. The title of this HN post ("Former game devs building a platform showcasing game projects") is 100% more descriptive than the explanation on the site, because you don't have an explanation on the site. It's a good start. Use that. Put it at the top. "Former game devs building a platform showcasing game projects".

"Hyped for you" makes no sense because I'm not logged-in. You can't possibly know anything about me. So it should show something else.

Remove the "hype" button from the "explore new games" section. How can I hype a game before I've clicked into it to view what it is?

Add pagination. (Unless you really only have one page of games, and pagination is implemented but not visible.)

Add a title that says "Project Goobii" on the page. Maybe above the "welcome".

Add left/right arrows to the carousel at the top, so users can scroll through instead of waiting for it to move on its own (and users love to interact with carousels!)

Clicking on a game in "hyped for you" shows the game, but doesn't change to a new URL. How can I share this page with my friends? How can I bookmark this game?

Also on the game page, the carousel of screenshots should be clickable and expand to show larger versions of the screenshots. Too-small screenshots are worse than no screenshots.

EDIT: More

Loading the page again, after going to a game page, shows that game page. I guess you're using cookies for navigation. Good guess, but the wrong way to do it.

Your logo is cool, keep that.

Have an "about" page with a contact email at least.
I'm pretty sure every person who says "branches are nothing but refs" understands why they are called branches.

They just want you (and others) to learn. This is an important piece of puzzle that many people miss.

Would you sacrifice all those (other people's) learning opportunities just so that you don't get annoyed?
The Firebird, The Silver Horse-shoe, Raggity and the Cloud, Folk Tales from the Soviet Union (multiple volumes), The Ant and The Pigeon, Dunno and Friends (I think), When Daddy was a little boy, Outer Space or Bust - these are some of them.
That's why we use fossil [0]. It just gets out of the way. It has its own server, wiki, ticket system and now, even chat!

The main complaint I see here is that it doesn't have rebase, and my point is the goal of the code is for the product to work, not to have a beautiful commit graph.

I've used CVS, SVN, Git. But nothing comes close to the usability that fossil provides.

[0]: https://www.fossil-scm.org/
I wouldn't call myself a power user by any means, but for many parts, the documentation is quite thorough, and if you're wrestling with some specific filter long enough, you might even begin to understand some of the magic incantation required to get it to work.

It's helpful to have some background in media container formats, compression algorithms, sound formats, and all the jargon and acronyms associated with the above. Easy!
The artists don’t work with scammy ticket salesmen (well they do work with TicketMaster). Scalpers buy tickets from TM and then resale them.
There's also a 7.50 electronic transfer, what is that even?!
Video (and audio) of a discharge: https://youtu.be/-jbnFuVWTdk?t=136
Worse still in this enumeration, TypeScript isn't a replacement like the others at all: no major js platform (browsers, nodejs) supports it. (here the term "native support" is thrown around a lot, but I feel at this point you're already well in llvm territory with the definition of "support")
Capiche? I agree with you! Haha.

I’m just curious where the FTC would draw the line. The root commenter made a good point that they seem to make a value judgement of what AI means. We can stretch that meaning pretty far if we want :)
This is extremely pragmatic wisdom and I love it.

I like writing legible code for its own elegance and for my own sanity, but given that you found your way to be productive, I admire your radically honest (and accurate) understanding of what happens to received code no matter what!
Seems like a broken 2FA implementation.
I had a chance to trade a 2001 multigame cabinet that I got out of a dumpster for a Popeye cabinet.

I regret not making that trade, the old Nintendo cabinets were beautiful, plus Popeye is a great game.
> The buck is supposed to stop at security, not at each employee's personal hygiene … if your game plan depends on the latter, it's game over.

I have to take security trainings twice a year that literally talk about the buck stopping at my digital hygiene and I better not fuck it up for The Company.

Companies have to understand breaches will happen, but preparing employees on how to spot attacks or understand when they've been breached is a huge component of their ability to repel or minimize attacks.
These examples like "wordbook" and "nameknown" reminds me of Newspeak, in the sense of building words by concatenating simple words.

https://en.wikipedia.org/wiki/Newspeak
Hey Yahivin! I love the idea and would love to use it and spread it. I think the best way to jumpstart that is a VS Code extension that allows Civet to be used as an Emmet style tool for the modern developer - write code really quickly and have it convert to production grade typescript following all your eslint / prettier rules, and use it as a personal speed up tool for just writing. When your coworkers start asking how you're moving so fast you tell them about Civet!
What kind of cameras and difficulties are you talking about? It’s almost always just a DCIM folder on the sd card.

Videos, OTOH, are stored rather arcanely, at least on my Sony, with separate directory structure for each format.
Lots of ways to get started!

States can withhold sending of collected fuel tax to feds.

States can remove exception that appears to be in State laws which allows IRS to file property lien without a court ruling.

States can mint their own gold or silver backed money.

States attorney general can start enforcing anti-monopoly laws against the medical cartels.

Unfortunately for civil rights and privacy, Americans no longer care.
While I agree that self-hosted PWA will have _some_ success (especially for easier use cases) and that cloud services are worse for the user than a local app in use cases suitable for the latter… it seems like a big load of wishful thinking to believe that PWA would replace cloud services in any significant way:

The truth is that we already had and have local apps that worked fine for the user (that is: native local apps, including cross-platform) and that despite that, cloud services gained terrain on them enormously. The main reason being that cloud services offer enormous benefits to the selling/operating company: the revenue is more calculable and less prone to the piracy issues of local software. The proportion of users who have enough awareness to recognize the problems of cloud services are a minority.

And the only thing that self-hosted PWAs really add compared to the classic native local apps, compared to which they have a lot of disadvantages, is that their development has a somewhat lower learning curve compared to cross-platform native software development (though the latter isn't that hard either and the reasons why many native apps were not cross-platform have nothing to do with technical problems in most cases).

As for the way the article pits "communities" against "big tech": I see that more as a matter of open source and open data communities… for which local PWAs really aren't that much of a big game changer as the article imagines.
https://news.ycombinator.com/item?id=34939717

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

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

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

https://news.ycombinator.com/item?id=34964335
What if you do this with no fine tuning?
Yeah, not all people work optimally that way

I agree it may not be optimal for everyone, and I might be more social than some. I've just learned a lot working with people who knew more or less than me at the time and some of my more fun+stressful experiences involve spending hours in collaboration fixing a problem on a tight deadline.

I have no idea what this has to do with anything that anyone said here.

The original article talks about a hypothetical single developer project vs one with code review/pair programming and suggests that mob/pair/reviewed programming leads to better outcomes. I didn't think about solo open source projects which might be great work by one person, more like things that a business is built on which might be the responsibility of only one developer. I work on commercial software mostly for small companies with over stretched development teams. I've seen this kind of solo project built many times, and after the developer leaves it's abandoned or rewritten, which is just a huge waste of time. So "optimal" in the larger scale.

I do like pair programming, which I would define very loosely as real time collaboration on a single shared problem whether that's in person, in a zoom call or just over slack. I was trying to imagine a software development situation with multiple programmers and NO collaboration. Punch a clock, pick up jira tickets and never talk to a peer? I wasn't presenting that as a realistic scenario.

I admit I am prone to hyperbole, but however you define pair programming or code review, I think all software benefits from collaboration between programmers, users, designers, architects and product/business people. One of the more intense forms of that is pair programming, and I happen to enjoy it.
The comments in this thread are very interestingly making the Author's point.

Yes, you can be "technically correct" saying branches are just refs, but it's not a useful statement for most users.

I believe the author makes a very valid point, and we could do with a bit less "technically correct" and more with language targeting the usage rather than technical implementation.

Git is confusing enough for many people, and we don't have to make it more confusing for them.
You can absolutely argue the benefits of a GC, and there are plenty of GC'd languages that as you say are great productivity enhancers.

If anything, D should stop pretending that it doesn't have a GC and stop trying to appeal to people who don't want a GC, it's a losing battle. D should just accept the fact that it is a GC'd language and start making the argument for why it's a better GC'd language than Java or C# or the host of other GC'd languages.

The vast majority of C++ developers do not want a GC'd version of C++, but it's possible that Java developers could be interested in a C++-like language that has a GC and good C compatibility.
I generally agree but for my own side projects, I like to keep a lot of code in one class if it makes sense to be there so I'm not jumping around a lot. For work code, I follow SOLID, DRY and 12 Factors so multiple people can be working in multiple classes and not usually running into conflicts.
iPhone Passcode Problem-Thieves Can Ruin Your Entire Digital Life in Minutes
Git's other (compounding) problem is how the CLI is an inconsistent mess.

Why do you create a branch via the "git checkout" command? Why do you delete tags using "git tag -d" but delete stashes using "git stash drop"? If you want to blow away local uncommitted changes, you can use "git reset", "git reset --hard" or "git checkout (file)" - which (I think) all do totally different things.

Git's data model may be elegant, but its hard to appreciate it through the tangled mess of git command line options.
Ah, the beauty of shared libraries, that "modern" languages don't seem to care about.
If you want to know a bit more about what is important in this major release, you can watch my presentation about FFmpeg 6.0 at Fosdem:

https://fosdem.org/2023/schedule/event/om_vlc/ (Video + Slides)

It’s a bit less dry than the changelog, notably for the evolutions of the APIs.

What’s also important is the changes about the release schedule that we’ve been pushing with the community. Major version every year at the beginning of the year, with ABI and API break, minor releases during the year and an LTS every other year…
I know a lot of people look down on ChatGpt. But I have been using it for creating scripts to use with ffmpeg and I was able to get most of the things that I needed with very little massaging required. You can then ask ChatGpt about what it did and why so it will explain it as well so you can get some basic understanding on how things work. People don't realise what kind of tool Chat Gpt is and how to properly utilise it but it can be very useful for stuff like this.
Let's see how readable the "ea" is when you're 80.
I coincidentally just watched a YT video by RobWords on the same subject last week: https://youtu.be/aMA3M6b9iEY

It’s an interesting watch but I do see why the attempts at “purifying” the language are troubling if taken as an actual attempt at anything other than a fun conlang.

Edit: oh the video is mentioned on the site. :)
I use the heck out of fossil and have little idea how it works underneath. I consider fossil the gold standard for a good versioning system ui. I don't think git has any excuse for being as weird as it is.

fossil init repo; make a new fossil repository

fossil open repo; open a fossil repository somewhere

fossil add file; note: very different than git add. in fact I was very confused by git add, in fossil the repository knows what files are managed by it and there is no staging area. so you only use "fossil add" when adding a new file. If you move a file use "fossil mv" to let fossil know what you did. Along with "rm" when you remove a file. The staging area still feels like an unnecessary added bit of friction.

fossil commit

There are others I use often "merge", "sync", "revert" but they tend do what the command appears to do. Speaking of revert, the git equivalent is really strange , even among the rest of the strange git ui. Shit! I messed something up and want to revert back to the last committed change, easy, just run the command "git reset --hard HEAD"