MontyCarloHall

I agree that the site is barely usable, but that's entirely due to a shift in Twitter's userbase caused by top-down policy changes (e.g. boosting right-wing spam), not any engineering shortcomings.

If Musk had never purchased Twitter and Jack Dorsey performed the same reduction in engineering staff, I doubt the site would be materially different from how it was pre-Musk.

Those are due to deliberate policy changes from Musk to boost engagement of his right-wing sycophants, not due to any technical failings. From a strictly technological point-of-view, Twitter works just as well as it did pre-takeover, and certainly did not catastrophically collapse as many predicted.

>thousands of middle-class "bullshit jobs" are disappearing, but rather than being replaced by a wave of productive jobs [...] we're just seeing unemployment, underemployment.

Jobs are neither fungible nor mutually exclusive; there is no reason to assume that someone working in a bullshit job would thrive in a non-bullshit job that contributes to society in more productive ways, nor does the existence of bullshit jobs prevent people from working non-bullshit jobs. I hate to say it, but perhaps many people are employed in bullshit jobs because they are not capable of anything more challenging.

Twitter is a concrete demonstration of this. There were so many prognostications [0] that Twitter would imminently implode after downsizing from ~8k to ~1.5k employees following Musk's takeover, and when these claims never came to pass, it was a wake-up call to the rest of the industry [1].

[0] https://news.ycombinator.com/item?id=34617964

[1] https://www.livemint.com/companies/news/elon-musk-fired-80-p...

>I use nucgen to generate a random 100M line FASTQ file and pipe it into different tools to compare their throughput with hyperfine.

This is a strange benchmark [0] -- here is what this random FASTQ looks like:

  $ nucgen -n 100000000 -l 20 | head -n8
  
  >seq.0
  TGGGGTAAATTGACAGTTGG
  >seq.1
  CTTCTGCTTATCGCCATGGC
  >seq.2
  AGCCATCGATTATATAGACA
  >seq.3
  ATACCCTAGGAGCTTGCGCA

There are going to be very few [*] repeated strings in this 100M line file, since each >seq.X will be unique and there are roughly a trillion random 4-letter (ACGT) strings of length 20. So this is really assessing the performance of how well a hashtable can deal with reallocating after being overloaded.

I did not have enough RAM to run a 100M line benchmark, but the following simple `awk` command performed ~15x faster on a 10M line benchmark (using the same hyperfine setup) versus the naïve `sort | uniq -c`, which isn't bad for something that comes standard with every *nix system.

  awk '{ x[$0]++ } END { for(y in x) { print y, x[y] }}' <file> | sort -k2,2nr

[0] https://github.com/noamteyssier/hist-rs/blob/main/justfile

[*] Birthday problem math says about 250, for 50M strings sampled from a pool of ~1T.

>Ye Olde ARPAnet Kludge

Seems fitting that NetBSD's internal mailing lists still use ossified address syntax from a time before DNS.

You are figuratively killing me with your literalism.

It’s a bitter monkey paw irony: when you ask FOSS advocates how developers would be paid in a fully FOSS world where piracy cannot exist because all software is free, the answer is often “service contracts.”

The monkey paw curls. Now we live in a world where software is nothing but service contracts and more closed than ever.

TIL about ACLs! I think that would nicely solve the group permission issue.

This wouldn’t be robust to moving/renaming files. It also would preclude features like having an expiration date for the URL.

How would you implement things like version history or shareable URLs to files without a database?

Another issue would be permissions: if I wanted to restrict access to a file to a subset of users, I’d have to make a group for that subset. Linux supports a maximum of 65536 groups, which could quickly be exhausted for a nontrivial number of users.

>Nobody has ever walked past a photograph because they can't inspect its digital authenticity hash.

This has rapidly changed over the last few months. As more and more pictures/videos going viral on social media are AI-generated [0, 1], real pictures/videos of remarkable things are increasingly falsely called out as AI-generated [2]. People are definitely starting to care, and while the toy camera in the linked article is merely an artistic statement, having some ubiquitously standardized way of unambiguously validating content generated by a real recording device is going to become paramount.

[0] https://www.today.com/news/bunnies-jumping-trampoline-viral-...

[1] https://www.youtube.com/watch?v=9O-8kAnBL2s

[2] https://old.reddit.com/r/skiing/comments/1oeda67/my_highligh...

I agree that Tesla's network is universally pretty reliable. For the other networks, I've found it can be quite location-dependent, likely proportional to the density of EV drivers. Bay Area or LA? Pretty solid. Orlando? Not so much.

I believe most new EVs have heat pumps [0], but this wasn't common until a couple years ago.

[0] https://www.recurrentauto.com/questions/which-electric-vehic...

How much of this is due to a high level of pre-purchase excitement followed by buyer's remorse? Anecdotally, I know several people who were gung ho about getting an EV, fully willing to pay its cost premium, who initially loved their EVs but sold them within a year or two after encountering issues that only become apparent with semi-long-term ownership:

— In the US, charging infrastructure is still quite poor, with a high amount of disabled or damaged chargers that aren't apparent on maps. Nothing worse than planning a route around the only charger within a few dozen miles and arriving to find it broken. The overall overhead of having to plan driving/parking around chargers is also too onerous for some people.

— Similarly, people underestimate how much harder long road trips are on EVs, especially when fast chargers are damaged and don't actually supply anywhere close to the advertised amount of current.

— People underestimate how much range degrades in cold weather. One person I know bought their EV in the spring, loved it until winter came around, and then promptly sold it the next spring. In a similar vein, people don't realize how poor and battery-hungry climate control can be in an EV, especially in models without a heat pump.

It would be interesting to rigorously study this, examining whether people buying EVs are more likely to sell them within the first couple years of ownership versus people buying comparably priced ICE cars.

The one issue with this approach is that it would still traverse all hidden folders, which could be expensive (e.g. in a git repo with an enormous revision history in `.git/`). `-not -path ...` just prevents entities from being printed, not being traversed. To actually prevent traversal, you need to use `-prune`.

>Those examples would actually be fine if this were something only did once in awhile (or in a script). But I search from the command line many times per day when I'm working, so I prefer a more streamlined interface.

Makes sense. If I had to do this frequently, I'd add a function/alias encapsulating that `find` incantation to my .bashrc, which I keep in version control along with other configuration files in my home directory. That way, when moving to a new environment, I can just clone that repo into a fresh home directory and most of my customizations work out-of-the-box.

Depends on how big the directory is. If it only contains a few files, I'd just enumerate them all with `find`, filter the results with `grep`, and perform the actual `grep` for "bar" using `xargs`:

   find . -type f -name "*.foo" | grep -v '/\.' | xargs grep bar

(This one I could do from muscle memory.)

If traversing those hidden files/directories were expensive, I'd tell `find` itself to exclude them. This also lets me switch `xargs` for `find`'s own `-exec` functionality:

   find . -path '*/\.*' -prune -o -type f -name "*.foo" -exec grep bar {} +

(I had to look that one up.)

>some of the default tooling feels dated: GNU coreutils and friends are often stuck around mid-2000s versions

That’s because they’re not GNU coreutils, they’re BSD coreutils, which are spartan by design. (FWIW, this is one of my theories for why Linux/GNU dominated BSD: the default user experience of the former is just so much richer, even though the system architecture of the latter is arguably superior.)

>It is possible, but not to the degree that all long Covid cases are being confused with external factors.

Didn't mean to imply that all cases are, just that our definition of and knowledge about long COVID is nebulous enough that some nontrivial proportion of cases are likely attributable to external factors.

>Additionally, long Covid can cause brain fog. This was shown in brain scans from a popular HN post about a research paper just yesterday

Absolutely, just as other infections can cause severe lingering symptoms [0]. But we don't really know how prevalent these are, nor the severity of the prevalence. Studies like the one you link typically select for the most severe cases. We don't know whether it's useful to generalize from those.

[0] https://en.wikipedia.org/wiki/Post-acute_infection_syndrome

Fine, here's a source where both the second and corresponding authors are from Harvard that says the same thing [0]. That said, you don't need to be from a prestigious institution to observe the basic statistic that long COVID is most frequently reported in women ages 40-60.

[0] https://jamanetwork.com/journals/jamanetworkopen/fullarticle...

Couldn’t it be the other way round, that changes in health caused by other external factors erroneously get blamed on COVID?

For instance, a disproportionate amount of long COVID cases are reported by women between the ages of 40 and 60, the exact age range when most women experience menopause [0]. Menopause can cause brain fog, fatigue, and other symptoms that mirror those of long COVID. Since pretty much everyone has had COVID, it’s a basic statistical certainty that many women caught COVID exactly when their menopausal symptoms started (whose onset can be extremely sudden), and falsely causally associate the two. The exact same conflation likely happens in children, who also go through several profound developmental shifts.

[0] https://telegraph.co.uk/news/2022/12/28/long-covid-may-actua...

So many puzzles like this basically require you to brute-force the solution [0], which just isn’t all that fun. I’m glad the designers explicitly acknowledge they’re trying to avoid this, and really hope that their claim that this actually can be solved with logic holds true:

   What if instead of doing the full colored puzzle, we find partial sets of tiles where there is only one unique solution? This adds enough constraints to the problem that it becomes feasible [without resorting to brute force].

[0] https://www.puzzlemaster.ca/search/?c=woodpacking%2Cwoodtang...

It's a real shame its raster functionality wasn't integrated into Illustrator. Adobe really butchered the whole Macromedia portfolio, didn't they?

(For those unfamiliar, Illustrator is a pure vector graphics editor; once you rasterize its shapes, they become uneditable fixed bitmaps. Fireworks was a vector graphics editor that rendered at a constant DPI, so it basically let you edit raster bitmaps like they were vectors. It was invaluable for pixel-perfect graphic design. Nothing since lets you do that, though with high-DPI screens and resolution-independent UIs being the norm these days, this functionality is less relevant than it used to be.)

Right, the vast majority of compute for autonomous warfare will be at the edge. The latency/jammability of having to communicate with a massive datacenter halfway around the world running bleeding-edge models is a nonstarter. Not to mention that these models are overkill for something like an autonomous suicide drone that just needs a relatively simple CNN trained to recognize enemy uniforms/materiel/buildings/etc.

>The problem seems to be that no one has figured out what the network effect in LLMs is.

At the very least, the exact same network effects with respect to advertising that search has. The vast majority of frequent ChatGPT users I know mostly use it like a search engine.

That said, those network effects will be massive. Ads in LLMs are going to be unprecedentedly lucrative, irrespective of the platform. Google/Meta currently charge so much for ads because they have such enormous proprietary profiles on users based on their search/communication history that they can offer advertisers the ability to target users with extraordinary granularity. But at the end of the day, the ad itself is static and obviously an ad. LLMs will make these ads dynamic and insidious, subtly injected into chats in the way a real-life conversation might happen to discuss products. LLMs will become the ultimate word-of-mouth advertisers, the final form of astroturfing.

This post underscores how traditional imperative language syntax just isn't that well-suited to elegantly expressing parallelism. On the other hand, this is exactly where array languages like APL/J/etc. or array-based frameworks like NumPy/PyTorch/etc. really shine.

The list summation task in the post is just a list reduction, and a reduction can automatically be parallelized for any associative operator. The gory parallelization details in the post are only something the user needs to care about in a purely imperative language that lacks native array operations like reduction. In an array language, the `reduce` function can detect whether the reduction operator is associative and if so, automatically handle the parallelization logic behind-the-scenes. Thus `reduce(values, +)` and `reduce(values, *)` would execute seamlessly without the user needing to explicitly implement the exact subdivision of work. On the other hand, `reduce(values, /)` would run in serial, since division is not associative. Custom binary operators would just need to declare whether they're associative (and possibly commutative, depending on how the parallel scheduler works internally), and they'd be parallelized out-of-the-box.

Perfect! Exchanges like this are why the internet is still a great place.

Ah, that makes sense. I would update it to say something like "the price was competitive with the generally overpriced market."

I agree it's not written in the clearest way, nor verifiable (though Stefano Marinelli does seem to be a semi-public figure in the online IT community, so it's not some anonymous blog).

>So we have just learned in paragraph 1 that the current system is dated and full of security holes and missing features. In paragraph 2 we have learned that the current system's infrastructure is "solid" and "working fine".

This confused me too, until I realized that he probably meant that his company set up the hardware infrastructure ("reputable IP classes, redundant datacenters"), but doesn't manage the software. Otherwise, why shred your own credibility from the first sentence by crapping on the "ancient," "insecure," and "ineffective" Exchange server?

>How can the price be both "reasonable" and "absurd?"

Agreed, this part makes no sense.