skysight-inc/HackerNews huggingface dataset:
Yeah, yeah, yeah. C is horrible, and programmers are all idiots because they didn't see how wonderful the stuff you like is. Sure. To steal a line from Jane Austen (or at least a film adaptation), "You tell yourself that, if it gives you comfort."

The reality is that your approach didn't meet the needs of the real world as well as the C approach did. You may dislike it, you may resent it, but your way didn't work very well.

It's not only because Unix was free, and C came along for the ride. It's also that Multics took several times as long to write, and required bigger hardware. (So Unix would have been cheaper even if the OS was not free, both because of lower cost to write, and because of lower hardware cost for a system to run it on.) And less cost opened up far more possible uses, so it spread quickly and widely. (How many Multics installations were there, ever? Wikipedia says about 80.) Which is better, the language and OS that have flaws, or the language and OS that run on hardware you don't have and can't afford?

And Unix was far more portable. Didn't have a PDP-11 either? No worries; it was almost entirely written in C. You could port it to your machine with a C compiler and a little bit of assembly (a very little bit, compared to any other OS). Didn't have C either? It was a small language; it wasn't that hard to write a compiler compared to many other languages. If you were a university, you could implement C and port Unix on your own. But once on university had done so for a particular kind of computer, everyone else could usually use their implementation.

And the final nail in the coffin of your style: Programmers of that era preferred that languages get out of their way far more than that languages hold their hand. Your preferred kind of languages failed, because they didn't work with people. It may have worked with the people you wanted to have, but it didn't work with the people that actually existed as programmers at the time. A tool that doesn't fit the people using it is a bad tool.

But all is not lost for people like you. There are other languages that fit your preferences, and you can still use them. Just stop expecting them to become mainstream languages. The languages that the majority of programmers found better (for their use) are the languages that won. And that majority was not composed entirely of fools and sheep.
Yeah, reminds me of the scene in the previous Spiderman film where he tries to intentionally flunk out of a class and the teacher points out that the only likely way to get 0 out of 100 on a multiple choice quiz is to know the right answers and intentionally avoid them.

And this is the same oil majors that put lead in gasoline because ethanol was a competing fuel, blatantly lying about the safety of this and poisoning several generations.
Sourcetable.com | Full Stack Engineer (React / Python / C#) (Senior/Staff) | Full Time | San Francisco or Mexico City

Sourcetable is building a spreadsheet-based data platform to make data accessible to everyone.

We’re hiring for a staff level full-stack engineer to join the team, working on our React.js / Python codebase (C# is helpful too).

You do not need a degree to apply, but you must be able to demonstrate that you have worked on hard things and have experience commensurate with the role. It will be helpful if you have previous experience at a startup.

https://sourcetable.com/about is a good place to learn more about what we're up to. You will be joining as person no.8 on the team.

If interested, email me (founder): eoin+hn@sourcetable.com
Model 3 can be had for under 30,000 in most places?
I looked at all (I think?) of the people on Nebula. I only recognize a few and none of them are people I follow on Youtube. The average quality might be higher, but it doesn't seem like Nebula is a platform for the niche YouTubers that make the platform worthwile for me.
As counter point, the way that Zig implements hash maps is absolutely instrumental for TigerBeetle.

Zig hashmaps _are_ quite a bit more cumbersome than, eg, in Rust --- you need to decided whether you want the allocator to be bundled with the hasmap, and its also up to the user of the hash map to provide equality and hash code (and, of course, there's manual defer instead of RAII).

However, this flexibility and verbosity comes with a super-power --- you can pass an allocator to a hash map at creation time, and then _not_ pass an allocator when you actually use the hash map. This is huge. This means that we get compile-time guarantee that we follow rule 3 of NASA's 10 rules

3. Do not use dynamic memory allocation after initialization.

And we _still_ can enjoy using a hashmap from the standard library! No other language I know has an equivalent tool.
I would prefer if the two entities are separated though. The thermostat should come from a private company that optimizes for the weather locally and possibly takes in data from the electric company through an API so the end user has more control and the motivations for both entities stay intact.
You hear a lot about the Xerox Star, but most of the articles (and there were many) are behind paywalls, or just plain lost. But they're all in one PDF on bitsavers. I posted them here.

https://news.ycombinator.com/item?id=36574631
There isn't, especially not for something that stirs up regional drama like SCS maps. PRC censors rather there be no politics at all.
Your point is well-made: the status quo is safe! Introducing any new product into an organization takes both a recognition of pain and some courage. In the case of Oxide, the pain is apparent: extant systems are expensive, vendors gaslight and squabble when issues arise, these heterogeneous solutions are surprisingly brittle. This is true even when dealing with what is ostensibly the same company! Try getting Dell, VMware, and EMC to agree whether a problem is due to the server, hypervisor or SAN!

In addition, app teams (i.e. the folks who deliver revenue to the business) are more productive on public cloud. They don't file tickets, they make VMs. Oxide is intended to bring the hardware, software, and interface innovations of the cloud into enterprise data centers with greater reliability and lower TCO.
It’s funny you say that, once you see a bit of of gpt content, it stands out.

One thing I will say is that it is a decent editor. If you feed it a document, it will produce pretty good suggestions about improvements etc.
Seeking work: US (Indiana), Remote — although on-site 1-2 weeks per quarter is fine.

Technologies: Generalist; lately full-stack web (React, Python, JVM, .NET, TypeScript, all databases)

Resume: https://neolefty.org/resume/resume.txt

Email: bbbaker@alum.mit.edu

Friendly and experienced engineer who enjoys helping a team gel and building useful things. Skills are up to date, and I love a good startup, but I can also handle legacy (codebases and people) just fine.
Maybe. But as we’ve seen (https://www.imore.com/iphone/lackluster-iphone-14-plus-sales...), the Minis did outpace the non-Pro 14s. Obviously as the 14s sit on the market if they will outsell the minis. It’s just a matter of essentially a self-fulfilling prophecy of being available and the latest SKU. But the velocity was not there. So expect Apple to react accordingly. I’d like for them to settle on set sizes. Hands aren’t evolving every year, they need to stop screwing around.

I use an iPhone 12 mini that I ordered on launch day and love it. Finally a worthy successor to the 5S/SE1.
A new Tesla factory comes to a parched corner of Mexico – Rest of World
Location: Angola

Remote: Yes

Willing to relocate: No

Technologies: Go, Node/Typescript, ExpressJS, NestJS, PHP, Angular, HTML/CSS/Tailwind, Git/Github Postgres, MongoDB, Redis, Kafka, Docker/Compose/Kubernetes, AWS/GCP/Do (all the compute, storage, networking primitives + lambda, beanstalk, queues, ecs/eks, etc), Bare metal, Devops/CICD (Ansible, Jenkins, Github Actions, etc), Banking and Payments (cards, banks, ACH, PCI, Stripe, kyc, fraud, tokenization, double entry accounting), Crypto (bitcoin at al, no NFTs), SCADA, Linux sysadmin

Résumé/CV: https://linkedin.com/in/figassis, https://github.com/figassis

Email: figassis [at] gmail com

Backend software engineer with 12+ years of experience building for multiple industries: education, energy, transportation, government, fintech (most recent experience) Currently exploring career growth opportunities and some stability. For the last 6 years I've been building robust payment systems for US, European and African companies. My latest project (PCI certified payfac with card payments, kyc, anti fraud, bank payouts, etc) was applauded by JPMC as the fastest successful implementation to date.

I work most often with: Go/Node, Postgres, Redis/Kafka, Docker/Compose/Kubernetes, AWS/DigitalOcean/Bare metal. I run all my personal projects from a k8s cluster on bare metal that I've maintained for over 6 years. Hats I can wear: Backend/Infrasturcture/Devops Engineer, Systems design, Software Architect, Head of Engineering
Which are things that most people cannot do. And that's a good thing.
Acceleration makes you a much worse driver, because you don't anticipate anything anymore. I've noticed this after buying an EV, and the Tesla drivers on 280 are even worse than me :-).
Maybe nobody (corporation/gov) is paying for that right now, but if all of those things become cheap enough to make sense to do (cost of transmission/ storage/processing are low enough to turn a profit or get the data you want) then someone (corporation/gov) will do it.
Who? People who record something and want to edit & post ASAP.
Ambani’s Jio unveils $12 4G phone with digital pay and streaming
The problem I believe is being discussed is that dereferencing a pointer after the memory it references is freed does not throw a warning at compile time. This means the programmer has to manually keep track of pointers, making sure not to free the relevant memory until there are no more references to it lingering about. While there are programming techniques which to lesser or greater extent prevent problems from occurring, e.g. by allocating all memory needed at the begin of the program and freeing all of it at the end, doing no (de-)allocation while the program is running; such solutions still require some discipline on part of the programmer and for some it is a tall ask.
...record for EV cars. 1000HP and a literal ton of batteries will do that. The top 50 ahead of it is pretty much every supercar made in the last 20 years and they all have less HP. Additionally, it cooks brakes and turns like a 4500Lb Sedan would. The Ring is a fast track with lots of acceleration zones. None of this should shock anyone. It is fast in a straight line, it, by definition, can't stop or turn nearly as fast as a supercar ever could. It is an incredible work...but not magic.
Like reddit's ELI5 (explain it like I'm five), but ELIHAM (explain it like I (only) have a masters)?

Yeah, if someone could please do that.
As a user, this is miserable. Matrix is used as a decentralised bouncer for tens of thousands of users to access IRC (including me) and while the bridge has certainly had problems over the years (e.g. occasional delays & a recent spate of dropped messages), it's also improved loads too - e.g. with support for restarting the bridge without reconnecting all the IRC users (https://github.com/matrix-org/matrix-appservice-irc/issues/1...) and all the other stuff in https://github.com/matrix-org/matrix-appservice-irc/blob/dev....

By now requiring users to go and contact chanops to ask them to explicitly plumb IRC channels to Matrix, it's just going to waste time for chanops, precipitate weird cross-plumbing failures, or fail outright (given plumbing channels with more than 100 users has to be done manually to prevent abuse).

It's very unfortunate that it's come to this, and I can only hope that the whole "opt in with a chanmode" thing happens, if portalling is off the table.

In fact, wouldn't it have been better to just ban the bridge by default, and let chanops unban it if they want people to be able to access via Matrix, rather than encourage people into the weird world of plumbing?

EDIT: clarifying that i'm not neutral on this, given i'm project lead for Matrix, and also responsible for running the Libera bridge at Element.
Loud minorities can form a market, if they are willing to put their money where their mouth is. But too often they don’t (cf. the “brown manual diesel wagon” from the car world. Enthusiasts say they want one, but when a manufacturer puts one out, they don’t buy enough of them).
> But by hodling fiat long term - you are just losing money.

Real interest rates are typically positive, so no, you are not.
Do you have a source for that? I thought it was closer to 5pJ/byte.
My sister is decidedly non-tech, and can to visit a few weeks back while working remote, and she used chat gpt over and over and over again for different small tasks.
No one commits as they write each line of code. There's always code in flux and you are not integrating with everyone else every minute.

Branches vs. on-trunk misses the mark, IMO: the question is what's your practices like for how frequently changes get integrated. There's multiple dimensions of freedom in how you do things.

Branching is a nice tool to have.

Avoiding long-lived feature branches is best (particularly with a big subset of the team working in them). (But, dang, sometimes you need these abilities, too, so having a workflow that supports them well is good).
One thing I can articulate - I want my children to have high expectations for themselves and be "ambitious" about persuing hard opportunities in front of them. Versus having victim mentality.

One thing that's obvious is my wife and I both exemplify this attitude, as do our immigrant parents (eg her dad went from broke immigrant to international biz owner).

I also think raising your kid on a religious context (religion is at its base the idea that your choices matter a lot) is a positive. I say this as someone who grew up an atheist, but that's another thing we are doing.
I use AWS Amplify, it uses CloudFront under the hood.
Is there any jurisdiction in the world where people are guaranteed a right to privacy in public spaces? And if there were, in what impossible-to-imagine way would that possibly be enforced? I think the fight for an expanded right to privacy should be focused on realistic goals, not this kind of paranoid all-or-nothing nonsense. If you don't want to be recorded in public there is one and only one solution.

Stay inside.
Thank you for your detailed reply.

> it is (theoretically) trivially easy to work around - just contract out your modifications, have the contractor keep the copyright and act as the only user of the software with an indefinite license

Would this not require the contractor to comply with section 13? At this point, you would be paying the contractor for ensuring legal compliance instead of doing this yourself, which is something that companies sometimes do anyway.

> AGPL doesn't actually say how compliance with section 13 must be achieved... MIDI is technically a network protocol

MIDI is indeed a network protocol, but I wouldn't read section 13 as requiring that the network used for the offer of source code or the source code itself is the only network used by the software. If you had a remote MIDI sequencer that users could connect their musical instrument to, it would almost certainly have something like a Web interface as well (MIDI isn't by itself an internet protocol, which I'm sure you already know) where the source code could be offered.

Ambiguities inherent to the diversity of software don't negate the general legal principle of good faith. Posting a link to a repository on GitHub with your modifications is usually sufficient for compliance, and edge cases like where GitHub is down or blocked for your user can be resolved with good-faith email correspondence. Given how much fuzziness there is in law, I don't think it would help much to be more prescriptive in say, requiring the offer to be made over HTTP.

> or-later is generally a bad clause for any license, since it hands over all licensing grants to whatever entity you trusted to write the license

This is true, but I consider it to be the lesser of two evils. The evil that or-later avoids is that of licence incompatibilities and ambiguities, which are frequently complicated by a difficulty in tracing the authorship of older software. Those programs which were licensed with an or-later clause can typically be 'rescued' by a new revision published by the licence steward, similar to how the FSF carved out an exception to the GFDL for Wikimedia as discussed elsewhere in this thread. The evil that or-later causes, that the licence steward makes a compromising change, is quite limited: since they can't restrict rights beyond the older licence, the worst-case scenario is that they go against the spirit of copyleft and make it a fully permissible licence, which is still 100% FOSS and in practice the FSF are not going to do any time soon.

Again, thanks for going into depth. I agree that there are improvements to be made, and I certainly wouldn't consider the AGPL-3.0-or-later to be the 'be all and end all' of FOSS licensing, but I'm not yet convinced it's a bad choice! :)
> If I were to use indices out of range, presumably that would that give me a compile time error?

yup

$ zig test test.zig
test.zig:8:56: error: index 3 outside array of length 2
std.debug.print("\ncompile error: {d}\n", .{slice2[3]});

> Could I use variables as the indices and, if so, could I get a seg fault at runtime or are there some sort of guards on there?

Bounds are checked by default:

$ zig test test.zig
test.zig:9:56: error: index 3 outside array of length 2
std.debug.print("\ncompile error: {d}\n", .{slice2[invalid_index]});

But you can disable them by building in `ReleaseFast` mode[1]

Here's a test file you can use to play around with it if you like:

const std = @import("std");

test "bounds" {
var arr = [_]u32{ 1, 2, 3, 4, 5, 6 }; // 1, 2, 3, 4, 5, 6
const slice1 = arr[1..5]; // 2, 3, 4, 5
const slice2 = slice1[1..3]; // 3, 4
const invalid_index: usize = 3;
std.debug.print("\nslice2: {d} {d}\n", .{ slice2[0], slice2[1] });
std.debug.print("\ncompile error: {d}\n", .{slice2[invalid_index]});
try std.testing.expect(slice2.len == 2);
}

1: https://ziglang.org/documentation/master/#Build-Mode
It should definitely be illegal. There are so many other options for charging these kinds of fees, all of which were used by public bodies in the US in the past, from dropping envelopes of money in a box to paying a person at a kiosk or using a vending machine to buy passes. Many of these payment methods are still in use at some parks/facilities.

The noose is tightening around the necks of those few of us who do not use smartphones. I hope a future wave of 'tech minimalism' gains enough traction to ensure that there are alternatives, but for now, as we ride the wave of tech-optimism and the mass adoption of intrusive technologies in the name of convenience or cost cutting, most people seem to see asking for alternatives as unreasonable.

There is an element of innate freedom in anonymous, analogue processes, even if they are not entirely 'anonymous' - such as writing a car license plate number on an envelope of cash for a drop box - it might as well be if the information is never entered into a searchable digital database where it will presumably be stored for eternity.

I few years ago I went camping at a state park in a system that had recently introduced usage fees (having always been free in the past). The state apparently partnered with some obscure parking app company to collect the fees. The use of the state park required submitting a considerable amount of information to a third party, with little or no information on how that data might be used, stored, or sold - in essence you had no choice but to submit to a third party's TOS in order to use public facilities at all. I did not like this at all, and having no smartphone, I paid cash at the manned office - only to have them collect my information and enter it into the parking app database.

A few months ago someone here made a comment in another discussion about having a pervasive sense that things are not quite as they should be. That stuck with me.
sure, but that's just one example...
Google's and IBM's previous "quantum supremacy" demonstrations were quickly crushed by improved classical simulations. Let's see if it survives this time.
Only 8 dashes, I wonder if ASEAN will ban the movie for not existing.
Onsite, 3-days per week.
Sure, but my comment meant to address systems thinking and application design, not micro optimisations.
Hard disagree on that, at least in the educational system I'm familiar with. The meagre time allocated in school schedules allows the teachers to barely introduce the students to concepts and techniques, and actual skill needs to be developed on your own.

(I can agree with a weaker version of that statement: homework that can be done by ChatGPT doesn't have any value and should be done away with.)
The warfighters themselves are receiving ever smaller pieces of the budget pie for the things that matter to them. Weapons, ammo, equipment, pay, and benefits. They have also been told to do more with less for decades even though the Pentagon receives more than enough money to provide them what they need.

The real issue is broken procurement systems that take too long, cost too much, and produce generally poor results.
Nobody Can Program Correctly – Lessons from 20 Years of Debugging C++ Code [video]
> The theoretical basis for these experiments depends on sampling the output distributions of random quantum circuits; unfortunately, understanding how this theoretical basis can be used to define quantum supremacy is an extremely difficult task. Anyone attempting to understand how this sampling task relates to quantum supremacy must study concepts from random matrix theory, mathematical analysis, quantum chaos, computational complexity, and probability theory. Resources connecting these concepts in the context of quantum supremacy are scattered and often difficult to find.

At the end of the day, people writing these papers are also human. The very same sorts of humans who pad resumes with shiny technology and self-serving complexity.

This might be a case of a rabbit you do not want to chase.
PostHog | Remote (US/Europe timezones) | Full stack engineer, technical ex-founder, tech lead | https://posthog.com

PostHog is the only open-source Product OS, combining product analytics, session recordings, feature flags, cdp and a data warehouse in one.

We have a culture of written async communication (see our handbook [0]), lots of individual responsibility and an opportunity to make a huge impact. Being fully remote means we're able to create a team that is truly diverse. We're based all over the world, and the team includes former YC founders, CTOs turned developers and recent grads.

To apply see https://posthog.com/careers or email us careers@posthog.com

[0] https://posthog.com/handbook/
You didn't miss anything.
My family: not tech savvy, haven't mentioned AI once to me, except my mother-in-law who asked if I'd heard of it and wanted to (honestly) know what I thought.

My friends: very, very much in tech, we have a channel in our discord where we just laugh at AI/ML/Musk/Crypto because it's so stupid. It can't even fucking add two numbers. It doesn't actually help with internal, brownfield projects with complex business logic and custom internal integrations. It can't summarize legal documents or answer technical questions without completely making crap up. It's just sparkling auto-complete.

My work: I've been put on an LLM project. The purpose? Dunno. The goal? Dunno. Our VPs are on the hype train and I'm along for the ride as long as my paycheck keeps clearing (and interviewing in the meantime). They're literally taking tech and trying to find a use for it. It's just the blockchain hype all over again.
I've thought about this too.

The other issue is that tests can have bugs too, sometimes you are just fixing a test bug.