Readit News logoReadit News
vthriller commented on Zig quits GitHub, says Microsoft's AI obsession has ruined the service   theregister.com/2025/12/0... · Posted by u/Brajeshwar
jappgar · 2 months ago
Hint: Type the '.' key on any code page or PR.
vthriller · 2 months ago
And now it opens... some VSCode-esque editor in the browser that asks me to sign-in? Why would I want something even more resource-hungry and convoluted just to look up a random thing once in a while?
vthriller commented on Zig quits GitHub, says Microsoft's AI obsession has ruined the service   theregister.com/2025/12/0... · Posted by u/Brajeshwar
mkornaukhov · 2 months ago
IMHO, the main advantage of github is that it is an ecosystem. This is a well-thought-out Swiss knife: a pioneering (but no longer new) PR system, convenient issues, as well as a well-formed CI system with many developed actions and free runners. In addition, it is best to use code navigation simply in a web browser. You write code, and almost everything works effortlessly. Having a sponsorship system is also great, you don't have to search for external donation platforms and post weird links in your profile/repository.

All in one, that's why developers like it so much. The obsession with AI makes me nervous, but the advantages still outweigh, as for me, the average developer. For now.

vthriller · 2 months ago
> In addition, it is best to use code navigation simply in a web browser

How do you define "code navigation"? It might've got a bit easier with automatic highlighting of selected symbols, but in return source code viewer got way too laggy and, for a couple of years now, it has this weird bug with misplaced cursors if code is scrolled horizontally. I actually find myself using the "raw" button more and more often, or cloning repo even for some quick ad-hoc lookups.

Edit: not to mention the blame view that actively fights with browser's built in search functionality.

vthriller commented on Two billion email addresses were exposed   troyhunt.com/2-billion-em... · Posted by u/esnard
willvarfar · 3 months ago
I'd be really surprised if Gmail's + behaviour isn't so well known by spammers that they just strip them off?
vthriller · 3 months ago
Not sure about normalizing recipients' emails but some are definitely aware of it because I've seen spam that asked to "reply back to defi.n.it.ely.not.shady+email@gmail.com" or something.
vthriller commented on FBI tries to unmask owner of archive.is   heise.de/en/news/Archive-... · Posted by u/Projectiboga
DaSHacka · 3 months ago
I don't know why all the archive sites don't share backups. The Wayback Machine and archive.is are the largest archive sites by far, and they don't share bulk downloads of the majority of the websites they catalog.

They of course don't have to, but having something like Anna's Archive but for website history would be great.

vthriller · 3 months ago
My guess is the sheer amount of data that archive.org has, which means:

- even higher costs associated with seeding archives (egress traffic, storage iops capacity required etc)

- chances of finding a 3rd-party seed for arbitrary file would be pretty slim, which means seeding on your own most of the time, which would make this hardly any better than offering files over HTTP only.

Anna's Archive, after all, is only an index.

vthriller commented on Zed is now available on Windows   zed.dev/blog/zed-for-wind... · Posted by u/meetpateltech
trenchpilgrim · 4 months ago
> The world moved into dynamic linking in the 1980's for a reason.

Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.

vthriller · 4 months ago
> Storage is cheap

My /usr is 15G already, and /var/lib/docker isn't that far off despite people's obsession with alpine images. If more people would dismiss storage as cheap it'll quickly become expensive, just not per GiB.

> update distribution is free

I wouldn't be surprised if at one point Github would start restricting asset downloads for very popular projects simply because of how much traffic they'd generate.

Also, there's still plenty of places on the planet with relatively slow internet connectivity.

vthriller commented on Discord says 70k users may have had their government IDs leaked in breach   theverge.com/news/797051/... · Posted by u/PaulKeeble
philipov · 4 months ago
No, it's very much used to express the sentiment "I don't care about this, and wish people would stop talking about it."
vthriller · 4 months ago
...which could also be a PTSD-esque reaction and not a sign of ignorance. As in "I'm so tired of being affected by this nonsense, when this would even stop".

People who don't really care would, in my experience, use sarcastic tone more often.

vthriller commented on Bat: Cat with syntax highlighting   github.com/sharkdp/bat... · Posted by u/Olshansky
freddie_mercury · 4 months ago
>> That allows you to concatenate and page multiple files at once like bat does? >cat is literally called “cat” because it’s intended purpose is concatenation.

cat's behaviour and bat's behaviour is different, though.

  >cat a.txt b.txt                                                                                                                                                                                         
  It was a dark and stormy night.
  Once upon a time.

  >bat a.txt b.txt
  ───────┬──────────────────────────────────────────────────────
         │ File: a.txt
  ───────┼──────────────────────────────────────────────────────
     1   │ It was a dark and stormy night.
  ───────┴──────────────────────────────────────────────────────
  ───────┬──────────────────────────────────────────────────────
         │ File: b.txt
  ───────┼──────────────────────────────────────────────────────
     1   │ Once upon a time.
  ───────┴──────────────────────────────────────────────────────
This difference becomes more useful once we have a more meaningful example:

  >cat *.py
  (thousands of lines of output)

  >bat -r :5 -H 2 --style full *.py
  ───────┬──────────────────────────────────────────────────────
         │ File: __init__.py   <EMPTY>
         │ Size: 0 B
  ───────┴──────────────────────────────────────────────────────
  ───────┬──────────────────────────────────────────────────────
         │ File: editor.py
         │ Size: 2.4 KB
  ───────┼──────────────────────────────────────────────────────
     1   │ import collections
     2   │ import contextlib
     3   │ import glob
     4   │ import io
     5   │ import os.path
  ───────┴──────────────────────────────────────────────────────
It's hard to imagine many people have the muscle memory for the combination of cat, head, and whatever else you need to add headers with the filename and file size, call out empty files, highlight the second line, show line numbers, do syntax formatting, and wrap to the terminal width (head doesn't do this).

vthriller · 4 months ago
What you're showing here is not concatenation, there are fancy borders between file chunks and whatnot. Unless you have very different, unconventional definition of concatenation.

In fact, you're at odds with bat's README:

> you can still use bat to concatenate files. Whenever bat detects a non-interactive terminal (i.e. when you pipe into another process or into a file), bat will act as a drop-in replacement for cat

> It's hard to imagine many people have the muscle memory for the combination of cat, head, and whatever else you need to add headers with the filename and file size, call out empty files, highlight the second line, show line numbers, do syntax formatting

Honestly, it's harder to imagine many people with need for most combinations of these features. I can see general audience who would happily use one feature at a time, and if someone is constantly doing obscure one-off file analysis, chances are bat is just never enough, they're going to write long pipelines with awk/perl or use vim macros anyway, so there are no time savings nor convenience from using bat. (Is it really that much more convenient to read syntax-highlighted heads with line numbers? And I can barely remember the last time when `head` that also shows file sizes could've been much more handy than `du * ; head *`.)

Also, good luck using all that bat muscle memory in docker containers or old-school fleet of remote servers.

> and wrap to the terminal width (head doesn't do this)

Terminals already wrap long lines just fine, they don't need help from anything. They can also re-wrap lines when window gets resized.

(edit: expanded quote, markup fix)

vthriller commented on Modern messaging: Running your own XMPP server   codedge.de/posts/modern-m... · Posted by u/codedge
vthriller · 4 months ago
> support clustering (for high-availabilty purposes)

That reminds me of one idea I had back in the day. You see, not everyone has the skill nor time to set up their own server, so clients rely on 3rd party servers. But sometimes these servers either experience intermittent connectivity issues or just die out altogether, which means users now have to set up second account and re-add everyone, while also scattering chat history across multiple accounts. What I'd like to see is some way of linking accounts across multiple servers, so that:

- message delivery could have transparent fallback (it gets delivered to me@bar.com if me@foo.com is unavailable)

- you don't have to add and authorize multiple accounts

- rosters and chat histories also get synchronizes between the two

A lot of that could probably be hacked around just on the client side, and I don't have good answers to questions like "what happens if I want to unlink two accounts for some reason".

(And going a bit off-topic: I also wish I could use multiple email addresses while registering in other places, because email provides too can fail, close altogether, or even just ban you for no good reason while also having crappy bot-driven support@.)

vthriller commented on Modern messaging: Running your own XMPP server   codedge.de/posts/modern-m... · Posted by u/codedge
kuon · 4 months ago
XMPP has very nice server implementations, and the protocol is OK regarding complexity.

But the clients are lacking. On linux there is gajim that is "okish" but it lacks calling capacity with mobile clients. On mobile there is conversation and derivatives on android which are "nearly there" and monad on iOS.

Globally, the main lacking features are:

- voice and video calls cross platform

- gif integration, tenor/giphy/imgur...

- fast sync (if you open gajim after being offline for a week, it takes ages to catch up)

vthriller · 4 months ago
> On linux there is gajim that is "okish"

In my book it only got worse. Way worse. Sure, it looks more familiar to those who is used to iMessage/Whatsapp/Telegram, but I bet it would still look quite alienating for that audience. And for those who remember Gajim 1.x, disastrous UX doesn't outweigh introduction of reactions, history syncing and whatnot. Last time I checked it a couple of months ago:

- It was not possible to close group chat without leaving MUC.

- I had to constantly open separate search dialog to write to someone who's already in my roster but is not in the list of active chats.

- Speaking of active chats: what annoys me the most about modern IM clients (and that includes Gajim 2.x) is that list of chats is sorted by the last activity date. I don't even know how Whatsapp/Telegram users live with this, I got so fed up with hovering my mouse/finger over one chat and tapping it only for the whole thing to reorder in the last jiffy and opening something completely different, I just dropped my account from one of those centralized mass-market services altogether. It is that annoying.

- It had lots of smaller warts like nickname autocompletion requiring way more key presses (especially after someone mentions you).

vthriller commented on Stepping Down as Libxml2 Maintainer   discourse.gnome.org/t/ste... · Posted by u/joecool1029
CaliforniaKarl · 5 months ago
And see also this LWN article: https://lwn.net/Articles/1025971/
vthriller · 5 months ago

u/vthriller

KarmaCake day614November 1, 2016View Original