dvogel · HackerTrans

dvogel

no profile record

comments

geçen aydiscuss

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.

2 ay öncediscuss

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.

3 ay öncediscuss

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.

3 ay öncediscuss

(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.

3 ay öncediscuss

> 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.

7 ay öncediscuss

> 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.

12 ay öncediscuss

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.

geçen yıldiscuss

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.

2 yıl öncediscuss

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.

2 yıl öncediscuss

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.

3 yıl öncediscuss

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.

4 yıl öncediscuss

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.

4 yıl öncediscuss

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.

4 yıl öncediscuss

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

A lot of that is git submodule history.

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).

4 yıl öncediscuss

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).

4 yıl öncediscuss

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.

So entirely the opposite of the python3 split.

4 yıl öncediscuss

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.*

The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:

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

Then shortly afterward the other author gave Bram an ultimatum:

    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.

Considering where the patch started, iterative feedback seems appropriate.

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.

The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

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.

4 yıl öncediscuss

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?

4 yıl öncediscuss

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?

4 yıl öncediscuss

As Cosmo magazine is to sex ed.