skysight-inc/HackerNews huggingface dataset:
> All other Mastodon instances

By "all" you mean the fraction of a fraction of moderators of specific instances that signed onto the petition.

The vast majority of Mastodon instances will happily federate. My instance definitely will. Why not, it's free content
Very interesting read.

I didn't expect to also end up reading about the Digital Antiquarian's take on Mao's Cultural Revolution, but I simply had to follow his link in the opening paragraphs of this article.
Yeah but just because types exist at compile time doesn't mean they exist at run time.

For instance with Generics in Java a List<String> is the same as a List<Integer> at run time, the compiler can enforce rules that let you add a String to one but not add a String to the other but the runtime has no idea. This has various negative consequences but it also let them retrofit generic collections on top of the old collection implementation in Java unlike the disaster in .NET where both had to coexist for years.

Similarly C compiles to machine code and in machine code there are just memory locations and registers, types are implicit in how you use those things but not spelled out explicitly. C++ does have RTTI but is one of the many open pits, like Exceptions, in C++.

Typescript types are the same way, once the compiler has done its type checking you know the code is going to behave according to the type system even if the types have been "erased".
>Nvidia has no motivation to make a consumer card with lots of VRAM

Money
DOS may be easy to emulate and re-implement because it's a single task operating system that does not do much. Most of hardware is accessed directly, and needs to be emulated instead. We enjoy great compatibility because of the enormous leap in performance since then (the slower the system the easier it is to simulate correctly on a modern one), and the combined knowledge of all the ins and outs collected during the PC boom by software authors and hardware makers implementing and re-implementing compatible devices.
This is the correct viewpoint. ChatGPT is one specific implementation of the technology, which was most people's first exposure to it. The broader applications of the technology itself are still in the very early stages, but are already making significant impacts.
High utilization time is irrelevant; autonomous vehicles further encourage low-occupancy vehicle use (both additional trips and trips that are converted from walking/bicycling/mass transit), and should not have 'a place in transit' except in limited cases like, for example, rural transportation for senior citizens. They have no place in urban environs; there's no need for them beyond profit.

Ride-share vehicles crippled the world's cities by causing a massive increase in low-occupancy vehicle trips, increasing vehicle ownership, etc.

> No one is targeting transit.

Uh, there's been a concerted effort since the 1940's by the automotive industry to kill public transit, but ok.

Whether they intend to or not is irrelevant; these self-driving-car companies are clogging up our roads because apparently it's acceptable to "fail fast"

https://insideevs.com/news/670739/cruise-robotaxi-stuck-musk...

https://insideevs.com/news/625602/gm-cruise-chevy-bolt-gets-...

https://www.theverge.com/2021/10/14/22726534/waymo-autonomou...

https://www.theverge.com/2021/5/14/22436584/waymo-driverless...
>That’s why so many laws are written to moderate advertising (eg not show a camel smoking a cigarette), moderate content (tv and movie ratings) etc.

It's a good argument, and perhaps once we started down that path we were always going to get to this point. I've had the same thought about gambling being banned on twitch so minors can't be influenced by it. But then they can click on one of the many GTA RPers role playing as a gang member.

I actually do agree gambling is bad, but I think this all just proves the slippery slope is real. As soon as you draw even a single line, you provide arguments for drawing another.
I think that's pretty much the crux of every argument here - move those other kids somewhere else. Don't worry about improving their situation, but make my situation better.

Cite a study, draw incorrect conclusions from it that support your argument, find some exception to the norm and use that as your example, and don't forget - describe how you were brought up and how that was better.
To be fair, most of the alternatives are garbage, but also most of Kryptonite’s own products are garbage. There are ~3 worthwhile bike locks on the market. 2 of them are made by Kryptonite. The rest provide the same value as the TSA. Mostly theatrical.
> can resist the urge to announce it as the graphics API to end all graphics APIs

Please quote the text that made you believe this. It's a very negative take.
remote control of an ethernet cable
> TS is already a new (superset) language which compiles to JS.

Yes, but also no. The point is that it doesn't really add more semantics over plain JS. You can erase all the type annotations (well, replace with "any") and it'll do the same thing if you ignore the type checking.

If there's any "transformation" from TS to different-looking JS[0], it's mostly just syntactic embellishment (think LISP macros and such), not semantic.

[0] Not sure if there is, tbh
It occurs to be that this might actually be a practical algorithm on an FPGA. It would need a couple of refinements to handle multiple of the same value, but for constrained length lists to sort it could be a useful technique.
> Construction projects always take far longer and cost far more than expected because of what's happening in the field, not because of what's happening in the office, so software simply isn't a bottleneck in this industry.

It seems like there are at least two problems software could solve here.

The first is that right now it takes effort for tradespeople to find work. They have to advertise or form relationships with general contractors etc. But then they have the incentive to draw out the work, because it's easier to extract more hours from this job than to do this job quickly and then have to find another one. Make it easier to match buyers and sellers so as soon as you finish a job you've got another one lined up and that incentive disappears, and maybe even goes the other way, because if you were the lowest bidder on a job you thought would take three days and you can get it done in two days, you still get paid what you bid. Which gives the general contractor more slack in the event of some other construction delays.

The second is efficiency. A lot of jobs are small and the major cost is travel time to the site. If you could get many contractors into the same system, you could do some optimizations there, by assigning jobs to whoever is nearest and minimizing the transportation costs, or letting contractors automatically adjust their bids based on their proximity. Which the contractors should like, because it reduces the travel time they don't get paid for.
With the Code Interpreter beta active, it will compile and run that code in the same chat window.
Debian in fact has a partners programme: <https://www.debian.org/partners/>

(And there are many more organisations and individuals who support the OS as well.)

Otherwise, this harkens back to "nobody ever got fired for buying IBM", Microsoft's "Linux is Cancer" and their "Get the Facts" FUD campaign (See: <http://news.bbc.co.uk/1/hi/technology/3600724.stm>), and much spew from SCO against IBM during the former's lawsuit against the latter.

The fact that Red Hat are now IBM and the Circle Has Closed is only all the more ironic.

(Red Hat was in fact my own first Linux over a quarter century ago, though I switched to Debian shortly afterward after realising that the latter was far, farr, far easier to install and maintain, for reasons intrinsic to the Debian Project's orientation and both social and technical structure. Incentives are very curious things.)
There's already a solution to this that doesn't involve replacing personal transportation with private interests that control all movement. San Francisco in particular used to be famous for it.
I think you're right. What are the best systems for doing this today?
This is the perennial problem with language design. Everyone wants something and they even have reasonable grounds to ask for it.

I myself have come across moments where some rtti/reflection would have been useful. In those cases I was often able to use branded types. Having something like that built into the language might be nice. But I'd also support TypeScript and JavaScript developers making the choice not to support it ever. IME, working around rtti type code often forces the programmer to come up with a much better approach.
Do you disupte any of the things I mentioned? Yes, obviously PhD students with kids and health issues exist, but on average, PhD students are younger, healthier, pay less taxes, qualify for more benefits, and don't have children. The MIT estimate is based on all the above not being true, but that's simply not reflective of the PhD student population.
There's also a huge moral hazard in these negotiations due to the different traditional ways ( arising from the problem that all parties have perfect knowledge of the agreed upon price, but very imperfect knowledge of the putatively agreed upon product) that we view responsibilities of the person spending the money versus the person delivering the product. and it is doubly hazardous in that it disproportionately harms the honest, thorough vendor by artificially equating their product to the dishonest, corner-cutting vendor.

The buyer has an advantage in that they can negotiate the vendor down through competitive bidding techniques, and by doing so transfer the fault for insufficient delivery entirely on to the bidder instead sharing the fault themselves. If I work two contractors against one another to drive one into the position where they are now no longer safely comfortable they can deliver the product they promise for the agreed upon price, (however I am now safely in my own comfort zone knowing that I've got the lowest possible price extracted from them), well if they fail to deliver what is requested it's now their fault for promising they can do it, not mine for pressuring them into a risky position.
I watched an extremely cool talk in college where a professor showed off some of the functionality of gdb by hooking it up to a running copy of Nethack and using it for various cheating. It was a bit over my head at the time but still felt pretty magical.
36k before taxes

- 2.2k (FICA)

- 4k (Health Insurance)

- 4.3k (Income Tax)

- 1k (3% matching Simple IRA)

but ignoring 3.8k into HSA and 6k going to Roth IRA because we are probably too poor to do that

=

whopping 24.5k

If you spend less than that I'd love to know what is in the care packages your mom sends you each week.
Agree, zod, arktype, and typia are impressively easy to use! Though, I feel that this environment created a different problem of spreading developers into multiple solutions. So for lib devs like me, we end up having to choose between coupling with a single validation lib or managing support for multiple (like tRPC does). To address that, I ended up doing a reusable lightweight lib that wraps that logic for supporting multiple: https://typeschema.com
I agree the cost difference being substantial, but something seems off here. I think you can buy nVidia cores that can beat anything AMD has for ~$1500-2000. That is gaming focused, but it makes me extremely skeptical of the overall numbers.

If the AMD chip really is better for your job, that's not that crazy a claim, but it make no sense that nVidia wouldn't have something for 1.5-2x as much. This seems to be the going rate, currently.

If you're getting comparable speed for 1/9 the cost, I don't think that product would exist for very long. I've been looking at graphics cards and nVidia clearly beats AMD in every category with around a 50-100% markup.
> Suppose for example that you talk to it about combating judicial bias.

Ok, here you go.

https://chat.openai.com/share/b083b98d-6904-4c85-94fc-abdc76...

A quick discussion of where things are "now", some proposals, a selection of three and then ethical concerns about implementing the proposals. I propose a method of increasing diversity and have it critique it.
> the industry still vastly underestimates those variables?

Do they usually? I don't know, but curious.

My only experience with the construction industry was the construction of my house and those of a few friends where I was able to follow along.

The cost was exactly as estimated a year+ earlier and the timeline was pretty much spot on except for weather-induced delays (can't blame them for mother nature).

The people I've seen complain about cost/delay are also those who changed their minds in the middle about details, so of course it caused delays and cost.
I agree... the speculation is becoming less on the market and more on whether these companies can execute. Everyione knows it's in their long term interest to make EVs.
Wirecutter is not objective.

https://www.xdesk.com/wirecutter-standing-desk-review-pay-to...
Interesting, like which games? I know RDR2 uses normal Vulkan swapchains.
There’s a ton written about this if you search for “typescript enums.”

I just finished removing them from a major project. Here’s a few of my personal notes:

1. They don’t play well with duck typing. (Eg. show me a subset of an enum)

2. They require an import every time you want to utilize them.

3. They are pretty wordy compared to union strings.

4. Their string value version encourages misuse as a key-value pair.

5. Unless you use the string value version, they suck to debug because logs just show 0,1,2,3.
But not in the linked article.

“It supports various graphics APIs, such as OpenGL®, OpenGL ES™, WebGL™, and Vulkan®”

Seems strange that’s missing from one and showing in the other.
Yup noticed this. Which just reinforces my belief that MacPorts is better designed than homebrew.
For Google Search, the sad part, is that the search algorithm hasn't gotten worse. But the web itself has. There is so much more spam, with actual human generated content being siloed more and more in walled gardens, that it starts to become a major issue for Google.
By "weasel language", you make it seem as if we're intentionally lumping in kids who aren't really problematic and being sneaky about it. We could all stand to be more nuanced, and there may be some people here who are just that harsh, but I think you're reading too much into our intentions. I doubt most of us support zero-tolerance policies (if informed about it). Frankly, I think administrators have to be willfully perverse to actually enforce such policies.
Instead of pleading to the TypeScript gods, why not make a deal with the JavaScript deities? Let's get type-checking into JS!

If I want runtime types, I reach for type guards. If I need to do this a lot, then I reach for io-ts or zod and pretty much exclusively write types as validators/codecs/schemas or what-have-you.

I don't think TS - as a specification, type-checker, community, or otherwise - needs to concern itself with runtime validation UNLESS JS gets some agreed upon way to do it.
You are still my favorite clown, don't worry. No need to stalk my comments.
I was perfectly satisfied with using https://zod.dev for some runtime data validation, and found it really cool that I didn't have to define some nominal type off to the side and could instead just say what I meant inline using a fluent API.
I know a fair amount about this and will happily answer additional questions. There are two main ways to work for DARPA. Bid on contracts when they are opened up for public bid. The other way is to work at DARPA to do this you need an incredibly unique idea that solves a particular office director's mandate for their tenure then you apply as a program manager. Most program managers are academics with unique ideas to solve the needs of that particular office head. You can only work as a program manager for a certain amount of time, I believe two years, before you have to rotate out.

If you work as a contractor on a DARPA program, you generally get to keep all IP rights. I've used these programs to fund companies before.
Could it simply be that almost everyone who is interested has tried it out, and those that didn't find it useful have dropped off?

That doesn't sound like something horrible. That sounds like a normal adoption pattern.
Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate:

> 3. Impose no runtime overhead on emitted programs.

> 9. Use a consistent, fully erasable, structural type system.

It's also explicitly called out as a non-goal in that doc:

> 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

> 6. Provide additional runtime functionality or libraries. Instead, use TypeScript to describe existing libraries.

[0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
Fairphone launched headphones recently maybe you could look into that if money is not issue

Marshall are also relatively good

My first marshall lasted for 18-24 months of 16 hours of daily (ab)use, battery was not an issue, just wear and tear because I've never been careful with them
Yeah, my GPU isn't so terrible terrible lately, but that's been a big draw. Eventually, you just get fed up and start looking elsewhere. Some of these AMD cards are complete trash.
It really is astonishing how much you can get done this way. I've been setting up a home lab for myself, and the answers Gpt4 gives are miles ahead of the stack overflow results or documentation of the apps or whatever else. Rarely (very rarely) it will give me a wrong answer, but then I paste in the error message or describe the problem I had and it almost always comes up with the correct answer 2nd try. Final step is asking where I might learn more because it's not working, and gpt always gives me a better link than google.

I'm convinced the people who say it's nothing but a BS machine have never tried to use it step by step for a project. Or they tried to use it for a project most humans couldn't do, and got upset when it was only 95% perfect.
As listed, Typebox is excellent for this use case - it correctly implements the JSON schema spec and allows you to use it to write OpenAPI specifications. At my company we use this to write type-safe handlers & generate our API documentation!
Thank you for your comment, it made me notice that I sold out. I just added some more inventory, but it may take a little bit longer to ship than usual, because I still need to assemble those units...
Any criticism boiled down far enough ends up in "they did things in a way I didn't like". It's not a meaningful response.

In this case, the criticism was in response to a perspective on these past events that is in my view overly informed by nostalgia, and while I don't make a general habit of snatching rose-colored glasses off anyone's face, in a public setting and especially in this public setting it is not unreasonable to do so.

I'm glad you found some good in the Poignant Guide. I had a similar experience with the Camel Book, a decade or so earlier, with similarly favorable outcomes - had my mom not proven amenable to being wheedled on the subject of an expensive birthday gift in which she could see no immediate value, I would likely not even be a working programmer today, to say nothing of someone able to grasp some rudiments of what may in a few more decades develop into a recognizable engineering practice. But I don't still use Perl or defend it, because beyond the most ephemeral and exploratory of contexts it is objectively godawful, and even in that context it lacks compared with tools that at least don't falsely advertise themselves as production-worthy. When people criticize it, I understand that they are criticizing it and not me.

And finally, on the point of whimsy versus professionalism - I mentioned the development of engineering practice, and that's a desirable outcome already too long in coming, because when we're trusted to build systems on which people's lives and livelihoods depend, we bear a responsibility of which a whimsical approach to the work constitutes active dereliction. Would you trust your life to a whimsical airplane, or your retirement to a whimsical advisor? Of course not! No one would, nor should they.

Other preparadigmatic engineering disciplines had the advantage of us here; a whimsically designed boiler, for example, will most likely maim or kill its perpetrator well before the bad idea gets much chance to spread, while we easily fall prey to the sorts of delusions that come from working with ideas and materials whose potential danger is much less immediately obvious. I would like us to be better at recognizing and extirpating such errors, and criticizing them where the opportunity arises seems like a decent way to advance that goal. I don't mind if you don't like it, but I would like you not to like it for better thought through reasons than these.
It totally depends on the era and the algorithm.

The first big mining wave was 2014-2015. This was done on 5850s, and GCN 1 and 2 GPUs. This was Bitcoin, so it was computation-focused, and I think in this era it was definitively AMD dominated due to VLIW allowing very dense execution resources plus early GCN having a large amount of raw integer processing power.

The next was 2017-2018. By this era bitcoin itself had moved off to FPGAs and ASICs, so this was around Ethereum which primarily worked based on proof of memory bandwidth. AMD GPUs were falling behind Maxwell/Pascal in terms of their memory compression (although they did use it) so they were equipped with more memory bandwidth to compensate. So for a given AMD card (Polaris, Vega, etc) you got more memory bandwidth per $, but in terms of the actual compute efficiency, NVIDIA had already pushed ahead even in Ethereum. NVIDIA was usually superior per-watt with cards like 1060, 1070, 1070 Ti, and 1080 Ti, and AMD just let you burn more watts.

However when it came to altcoins, where it was not just raw bandwidth, NVIDIA's superior compute/GPGPU efficiency took over and there were some coins that NVIDIA was 2x or more more efficient on per-watt and also the winner in absolute performance.

(the thing to remember is that compute is the part that ASICs can do efficiently, and I always questioned whether those altcoins were really ASIC-resistant. But the ProgPOW-style algorithms doing better on NVIDIA cards never bothered/confused me, the reality is that most GPGPU programs "favored NVIDIA" during this era and Ethereum's proof-of-bandwidth model was an exception. Pascal was an efficiency beast and Polaris and Vega were only ok at best, outside their enormous, dangling memory buses.)

This state of affairs persisted throughout the 5700 series until AMD launched the 6000 series, where they shifted to a design with smaller memory buses and more cache, which put them in the inverse situation of 2014-2015 where they were getting more out of a weaker memory subsystem than NVIDIA. And I think they did this on purpose because they wanted to "opt out" of the mining boom/bust cycle, and NVIDIA made a similar approach with Ada that has been extremely unpopular (despite AMD leading the way on this a few years before on their cards too).

Isn't it wonderfully coincidental that out of any amount NVIDIA could have put into the LHR to slow down when it detected mining, that they put in the exact amount that dropped their cards to the same relative mining performance as AMD, and moved to the same cache-based approaches in the next generation as well? That has always been my take around LHR - it's not that they didn't like mining revenue, it's that they didn't want NVIDIA cards to be disproportionately pulled off shelves like happened to AMD in the 2014 and 2017 mining booms. People remember the "AMD was $1600, NVIDIA was $2400" situation already, they didn't want that to persist and turn into actual marketshare.