Hacker Newsnew | past | comments | ask | show | jobs | submit | domoritz's commentslogin

For another grammar-of-graphics-based visualization library (flexibly compose charts rather than simply pick a template), check out Altair https://altair-viz.github.io.


You might already do this, but great opportunity to support them with a donation.


We are indeed a monthly GitHub sponsor.


Arxiv can recompile latex to support accessibility and html. Going to pdf submissions would be a major step backward.


Make it an external service then, and leave the thing that's already working great to just be.

The reason authors like and use arxiv is that it gives 1) a timestamp, 2) a standardized citable ID, and 3) stable hosting of the pdf. And readers like the no-nonsense single click download of the pdf and a barebones consistent website look.

All else is a side show.


You have to keep in mind that an increasing portion of their time and labor is going towards moderation and filtering due to a mass influx of nonsensical AI generated papers, non-academic numerology-tier hackery, and other useless drivel.

Spinning the service off forces other the labor out onto other universities rather than leaving them to solely Cornell


Is the problem the storage cost for hosting them, the HDDs? I'm sure they can be offloaded to cold storage because most of that slop won't be opened by anyone.

Arxiv doesn't need moderation. Nobody is asking for Arxiv moderation. It needs minimal checks to remove overtly illegal content.


> Arxiv doesn't need moderation. Nobody is asking for Arxiv moderation

Seems like a lot of people are asking for moderation. And moderation is a pretty big part of the existing offering[1].

[1]: https://info.arxiv.org/help/moderation/index.html


When you stop moderating input, that's when someone builds a fuse filesystem on top of it. We had those for discord (dsfs), twitterfs, redditfs, yt-media-storage, etc. It's also when someone starts using it to distribute malware, like websites built on a combination of GitHub and a cdn.


We are talking about a different kind of moderation. People want to filter out incorrect information that in their opinion damages the reputation of Arxiv, eg covid stuff. It's not about dumping binary data.

This is a motte and bailey fallacy. The real question is about moderation with the goal of checking truth and the scientific content. Obviously illegal content and ddos type overloading attacks need to be blocked.

Very different philosophies are clashing here. Arxiv came about in an age of different zeitgeist. We may never get back to that moment.


> Is the problem the storage cost for hosting them, the HDDs?

No. Around half the cost is infrastructure. The other half of the cost is people. i.e. engineers to maintain infra and build mod tools for moderators to operate.

> Arxiv doesn't need moderation. Nobody is asking for Arxiv moderation.

This is just not true. Tons of people ask for arxiv to have moderation. Especially since covid, etc when antivaxxers and alternative medicine peddlers started trying to pump the medical categories of arxiv with quack science preprints and then go on to use the arxiv preprint and its DOI to take advantage of non academics who don't really understand what arxiv is other than it looks vaguely like a journal.

And doubly so now that people keep submitting AI generated slop papers to the service trying to flood the different categories so they can pad their resumes or CVs. And on top of that people who don't actually understand the fields they are trying to write papers in using AI to generate "innovative papers" that are completely nonsensical but vaguely parroting the terms of art.

The only reason you don't see more people calling for arxiv moderation is because they already spend so much time on it. If they were to stop moderating the site it would overflow into an absolute nightmare of garbage near overnight. And people wouldn't be upset with the users uploading this of course, they'd be upset with arxiv for failing to take action.

Moderation is inherently unappreciated because in the ideal form it should be effectively invisible (which arxiv's mostly is).

If you want to see the type of stuff that arxiv keeps out, go over to ViXrA [1] or you can watch k-theory's video [2] having fun digging through some of the quality posts that live over on that site.

1. https://en.wikipedia.org/wiki/ViXra

2. https://www.youtube.com/watch?v=1at9BjQP8CI


The UX has many rough edges especially in the default element apps. UX was the primary reason my university department passed on switching to matrix from slack so far.


I suspect most use of columnar databases is OLAP, which is different from what people usually mean when they say time series data.


Google produced a podcast introducing ML concepts with the same game a few years ago. https://pair.withgoogle.com/thehardway/


So many data probes would be solved if everyone looked at a few outputs instead of only metrics.


Urg, the bar charts to not start at 0. It's making it impossible to compare across model sizes. That's a pretty basic chart design principle. I hope they can fix it. At least give me consistent y scales!


I don't understand why there isn't an obvious, visible watermark at all. Yes, one could remove it but let's assume 95% of people don't bother removing the visible watermark. It would really help with seeing instantly when an image was AI generated.


I like the idea of having types at runtime for parsing etc and generating validators in various languages. What stopped me from going there so far is that I already have TypeScript types provided for the various libraries I use. How good are the tools for importing TypeScript types into ArkType/Zod and working with types in various representations in parallel?


The way zod and arktype generally handle this is by providing treating the schema as the source of truth, rather than a type. They then provide a way to define the type in terms of the schema:

  // zod 3 syntax
  import { z } from 'zod'

  const RGB = z.schema({
    red: z.number(),
    green: z.number(),
    blue: z.number(),
  })
  type RGB = z.infer<typeof RGB>
  // same thing as:
  // type RGB = { red: number; green: number; blue: number };
For the initial migration, there are tools that can automatically convert types into the equivalent schema. A quick search turned up https://transform.tools/typesgcript-to-zodghl, but I've seen others too.

For what it's worth, I have come to prefer this deriving types from parsers approach to the other way around.


With Zod you can build a schema that would match an existing type. Typescript will complain if the schema you build does not match the type you are representing, which is helpful. From memory:

  import { z } from ‘zod’

  type Message = { body: string; }

  const messageSchema: z.Type<Message> = z.object({ body: z.string() })


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: