dvogel

I couldn't agree more. Thus far I'm still objectively more productive than all of the AI enthusiasts I've worked with. I think a lot of the activity with these tools is coming from people who just enjoy using them more than they enjoyed coding. They feel more productive not because they are producing more but because they are producing somewhat less with much effort. It takes them roughly the same amount of time even if it changes the distribution of time spent on each task.

and in recent weeks it has started to dominate the Twitter discourse.

As a general rule, I don't waste my time with the advice of people who still think Twitter is a source of wisdom.

You're mistaking a compromised build pipeline versus a compromised source repo that only triggers in some build pipelines. You can do reproducible builds from compromised source tarballs. Nothing about reproducible builds necessarily requires source control. Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise. However I have yet to see a reproducible build project that includes such cross-build checks.

No, it wouldn't. The xzutils attacker compromised the source repository. The build pipeline portions were used to obscure the purpose of the exploit embedded in the source code repository.

(Not OP, but...) I still fail to see the current value in confirming that a reproducing builder also included the same compromised dependency that I did when I built it. I understand that reproducible builds are guarding against dynamic attacks within build infrastructure. However I just don't see those happening. Compromised source dependencies are a 100x more common problem.

US-centric here: I feel that uploading a small percentage of a file as a condition of downloading the whole thing may very well fall under fair use

This is not consistent with current Fair Use application. The TL;DR is that the use must be for a new expression that is protected by either the 1st amendment or copyright itself. I don't know of a single case where it has applied to mere distribution. I would be astounded if there is such a case because that isn't within the expressed purpose of the doctrine.

But as a standard library abstraction, it’s too opinionated. It categorically excludes cases where sources form a tree: a validation error with multiple field failures, a timeout with partial results. These scenarios exist, and the standard trait offers no way to represent them.

This seems akin to complaining that the CPU core has only one instruction pointer. There is nothing preventing a struct implementing `Error` from aggregating other errors (such as validation results) and still exposing them via the `Error` trait. The fact of the matter is that the call stack is linear, so the interior node in the tree the author wants still needs to provide the aggregate error reporting that reflects the call stack that was lost with the various returns. Nothing about that error type implementing `Error` prevents it from also implementing another error reporting trait that reflects the aggregate errors in all of the underlying richness with which they were collected.

I lived in DC for 5 years. From 2011 to 2014 and 2019 to 2020. I saw _a lot_ of cops, of nearly every jurisdiction, but never a national guard member.

My understanding of the claim is that the mainframe data is stored in a high fidelity format but some records simply lack a full year. At the time social security was instituted it was common for people to not know their own age precisely. Beyond memory issues arising from old age, most people just didn't have a pressing reason to track it. So social security benefits were granted to people who seemed old enough even though they didn't have a birth certificate or similar. The claim, as I've heard it, is that the DOGE dolts transferred this data to a more modern system where they blindly passed incomplete or placeholder values into an 8601 library implementation that uses the 2004 standard's reference date of 1875 by default.

Unfortunately paying for these services to avoid ads will never work. It was first promised by cable TV when they first scaled out coaxial around the country. You paid for TV in part to not have ads. That worked great until the advertisers increased their bid. It was tried when VHS kicked off but eventually even tapes rented from Blockbuster had ads once the advertisers increased their bid. And now it is happening to streaming services. For over a decade I paid Netflix specifically to avoid the ads but as more people do that it decreases the supply of passive attention, which prompts advertisers to increase their bid again, and now it's almost impossible to continue paying to avoid ads. Now I have to pay a fee and watch ads. I would gladly pay YouTube to avoid watching ads but it just won't work. They will start taking my money each month and then they will also push ads at me after I pay them consistently for a long time. We're well beyond "fool me twice" territory.

Both TST and Sidebery are leagues ahead of tab groups IMHO. Frankly sidebar tabs just work better for 16:9 aspect ratio because with a maximized window most sites don't make good use of 1/4 of the width anyway.

When I initially read the htmx documentation I was confused because it kept talking about a hypermedia client. The context clues suggested they were referring to htmx but my brain kept saying "isn't the browser the hypermedia client?" Eventually it sank in that htmx is an extension of the hypermedia client. When I first tried to use htmx I experienced a lot of discomfort regarding areas where htmx feels non-standard, such as redirects in the hx- readers on a 200 response. Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away.

The founder of neovim did briefly attempt to participate in the vim dev process. This was a few months later. The most relevant thread is here:

https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...

He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:

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

In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.

I feel the same way. Legacy vimscript certainly had some warts but vim9script has been much nicer IME than lua. Elsewhere I've likened vim9script to typescript 1.0. It has just enough types to be useful but not enough to let you go down a rabbit hole. That's sort of the sweet spot when scripting another application.

    $ du -s -h .vim
    22M .vim

Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).

I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor.

My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).

This is all correct. To quote from the official description of vim9script:

    Vim9 script and legacy Vim script can be mixed.  There is no requirement to
    rewrite old scripts, they keep working as before.  You may want to use a few
    :def functions for code that needs to be fast.

This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2...

My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):

    You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*

    Bram,
    I happy to see there is still some hope for this patch getting merged.

    Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
    
    If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.

Bram replied (in part):

    It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.

As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.

That is interesting to me because that isn't my experience. I just tried the lock screen for example and I couldn't get any of tabs to reload, foreground or not. I'm on Android 10 running on a Moto G7. Maybe it's affected by vendor settings?

What FF mobile fiasco are you speaking of? I am using FF mobile happily and have been for years. I haven't noticed any issues with it. Was there a business level fiasco or something?

As Cosmo magazine is to sex ed.

This glosses over the outright fraud within the banking industry that was at the heart of the S&L crisis. Without the fraud there would have been enough assets and financial incentive to consolidate instead of liquidations. The Fed policies only had the effect of forcing the industry to account for the rot within.

This is a pattern I've noticed throughout history. I really wish there was a popular science book that tried to answer the question: why do humans seem to make so much progress with each initial invention? It seems like everything from bridges to antibiotics, the initial inventions have lasting power because they address 80% of the problem. The track record of success inventing an 80% solution as the first entrance is astounding but it is clouded by our focus on the exceptions like flight where we were stumped for a long time. Surely there's some survivorship bias too. We don't remember the bridge designs that failed immediately, but I'm focused less on that. Why are _any_ of the initial designs in so many fields still around? Why are fundamental shifts that completely upend our understanding of fields so rare?

I'm not necessarily advocating for the approach described in the article but it wouldn't worry me from a security perspective. The security model of eBPF is pretty impressive. The security issues arising from engineers struggling to keep the entire model in their head would concern me though.

One of the biggest issues ruby faces is performance. The productivity of the language is undeniable. That is a big reason start-ups so often choose ruby. Eventually Salesforce or Microsoft acquires these ruby start-ups though that the apps run up against enterprise managers who have traditional baroque "cost optimization" incentives. Very few people, especially managers, are comfortable making the argument that paying for more machines is better than paying for more cheaper devs so you see these successful apps rewritten in java, C#, etc. Someone shows execs a chart with costs per user plummeting (usually with a deceptive Y axis), everyone pats each other on the back, and then they lament not being able to find ruby devs when they acquire the next company. I'm hopeful that ruby can close the perf gap enough to slow/stop this weird cycle.

This approach precludes any justice from being achieved in countries permeated by corruption.

If the image is accurate I think "motion led" would also be in scope for initial collection. There is a filtering process after the search term net that determines whether it is in scope for the warrant. Given the dubious framing of these search terms and past examples like the NSA watching every Linux Journal visitor I'm disinclined to trust such a process. RIP to work schedule of the poor intern who has to weed out all the results for suburban parents setting up Halloween decorations with glowing eyes.

While the FBI's behavior in many cases is extremely suspect in this case there seems to have been legitimate contact between these suspects and real foreign agents in early 2020, prior to any FBI involvement.

Wikipedia is good for general knowlege. Legal charges are made with respect to a specific statute. In the U.S. treason will only ever be charged when we are at war.

That would have been more possible a decade ago when the web browsers were less compatible and sites relied on the lowest common denominator feature set. With the increase in compatibility sites now rely on libraries that each depend on a different 90% of the feature set. Breaking interactions between those dependencies has a cascade effect that leads to really, really, really frustrating experiences today. e.g. a UI that looks perfect and has interaction effects working but a background interaction fails silently. A decade ago compatibility issues were more common but IME they were less frustrating because there was usually a rendering artifact or foreground error that made it clear the author just didn't support your browser.

It is being likened to bubblesort in various places but your description (which I quite like) makes it seem like quicksort with an intentionally bad (worst possible?) bifurcation.