seeknotfind

It's only $100k.

#7 is kind of funny - post on social media. Lol.

I love the opening #if 0. So many tricks from multilingual quines, maybe they can actually be useful :)

And a bank account number to send it to!

How about an LLM agent which automatically finds inconsistencies in RFCs.

I use email drafts for this.

Hey but consider this is allowed on Twitter, that's at least something good. Self driving is so nice, wish they'd have it too.

Well this is a buffer overflow attack, not injection, but hey, it's in a SQL program!

Though SQL injection and other injection attacks are definitely not dead. All it takes is one programmer mistake and poof! Lots of XSS rely on accidentally injection of some value. Also hey lots of LLM based attacks are injection. Injection is not dead... oh no oh no

One reason to prefer textual UIs is that you can use them from any computer anywhere fast (no slow video VNC). Also, if you are already using a terminal, then improving that experience is nice. There is a big enough market there for this company.

However, I'm not sure what a "proper" GUI is. Terminals have a widely used open standard. These protocols are more standard and interoperable than any GUI framework, and they are supported on every system. Once you add video in there, close a few more gaps, I think competing with the browser, or bringing the full computer experience to the terminal is reasonable.

Obviously if terminals add something like video, it's "copying" rendering pipelines from "proper" GUIs, but making the terminal experience better, which could also be viewed as bringing UNIX zen to GUIs, if it makes it big, you'll love it too! <3

One reason programmers do this is so that they can make a one character change, e.g. "else if (1 === 1)" -> "else if (1 === 2)" in order to change the logic there. For C programers you see a lot of '#if 0' '#if 1' for this same purpose. Though, given that it's used everywhere, I'm not sure if it's really for that purpose.

One of the reasons the FD interface is so complicated is because there are many of the same operations, but they do different things to different underlying kernel implementations. In Linux, you have no standard way to tell what the underlying FD is. It's such a wide surface, different kernel surfaces might implement some of the many different file APIs (polling especially) slightly differently. In many cases, you can reuse standard tooling, but random ioctl calls mean you can't always reuse tooling. Nonstandard implementations of standard file calls can make it dangerous if you don't know which type of FD you have. So the good thing is they are standard, you use the same set of tools (file APIs) to operate with them, so it makes the system interface smaller and simpler, but it lacks the fidelity to create orthogonal meta programming over them. It sounds like an unimportant complaint that you can't tell the underlying type, but it also means most languages refer to FDs indiscriminately. You don't typically get type safety in languages for FDs (e.g. different class for an FD backed by shared memory instead of a real exclusive file), and even if you do have these classes you can't really guarantee they are correct at runtime if you get an FD from another process (e.g. over UDS from a child process), so languages leave FDs untyped.

About the global cursor, it's not an issue because you can dupe it to get a copy with a different cursor. So only references to the FD with that specific FD identifier have a location associated with itself, and that's because the OS can only look up the state on that FD. So dup gives cursor, but if an FD represents a physical seek, it might be the case that a dup'd FD actually does affect the functionality of the first FD by linking the two together, as that's a choice you can have in the kernel when implementing an FD. Dup also mean no new cursor.

So that's what I mean, the complexity of the real world means these objects are fundamentally different, and having the same APIs shoe horns them into something they're not. I've worked in large systems where you have very specific type-defined capabilities and messaging, and you end with different engineers creating many types which are equivalent but have independent implementations. This is another kind of nightmare because you need to convert many types to use them, which ends up being the source of a lot of boilerplate, and many things are nice, but it takes a very influential and powerful architect to curb complexity in such a system, and in the end complexity is inevitable, even if specific bouts of it spring up and get fixed, you end up with many many many APIs. So despite FDs being a very corset type API, it's brazen simplicity has eliminated an entire layer of complexity from our software.

Perhaps my complaints of FD's complexity are the misplaced pangs of an idealist, forgetting the importance of the big picture. FDs are the APIs we need, but not the ones we deserve. I think their role in the structure of our programs is far more important than their exact nature. Perhaps one day they can be replaced, but whatever does replace it will certainly have learned a lot from the humble FD.

Ah! Well as a systems programmer, it's not so rare. FDs are really not a friendly interface, and I'd love a better interface (FDs have their quirks), but as an application programmer, it's really sad we don't take advantage of FD passing to build more modular programs. For instance on desktop operating systems, you pass paths, not capabilities to use files, and the norm is giving programs access to read large swaths of user data. This is not secure, and it's one of the issues well-passed FDs could help solve. In general, despite the challenges in making them secure, I'd strongly advocate for more modular and integrated applications.

As for the seeking abstraction, it fits well with other buffered device driver information streams. Yes, it's a complicated and confusing interface, but the key thing is it allows you to share an OS/system/hardware level resource between multiple programs. We want to take advantage of that. It's the abstraction we've got sure, but it's what we do with it that counts!

SIMD is no mallot. It's absurd and wasteful to allocate page aligned memory by creating an even larger malloc allocation which will allocate extra pages via mmap underneath. Use mmap to directly allocate page aligned memory. That's what is designed for.

Maybe in areas with comparable sourcing, regulation, and market conditions. Globalization hasn't arbitraged food prices (yet?).

https://commodity.com/blog/food-prices/

If you want page aligned memory for SIMD, you shouldn't be using malloc, you should be using mmap. Though other smaller alignments can be useful.

Holding the model needs constant, but the real limit is $$$, so it'll mean more model for the same money.

HahahahhahahajajjajahahahahahBNnNnbn. The consumer speaks. You'll get what you want if you're upset, so keep it up. :)

Nicotine is highly addictive.

> This is really weird. No known isotope of promethium has a half-life longer than 17.7 years, meaning that it must be produced by some continuous process if we are to see it in Przybylski's star. Further analysis showed it contains actinium, protactinium, neptunium, plutonium, americium, curium, berkelium, californium, and einsteinium. These are difficult to confirm because they do not occur in nature (except, it seems, in Przybylski's star).

They're searching for natural explanations to rule out alien life. Very very cool. Quite a variety. Lots to learn from this star.

Yeah, journaling is very rewarding. Sometimes you don't realize how much you change and grow. Sometimes you read back and laugh at how you've overcome, sometimes you cry.

Though I've gotta say, if my grandparents (or their parents) did have social media, they'd have loved it.

It's okay for a browser to download and use anything from any site, maybe, with mature cross origin policies and billions in security work, but the fact it's done without saying anything is just a bug that can be fixed. Fixing clarity is the real win.

What's really funny is it was found because it was crashing and the user was running another libc. If they're really concerned about 14MB of download, they should add a firewall or something, but they saw it crashing. Finally, all these versions of everything sitting around, nodeJS, glibc, etc, very UNIX, a recipe for small breakages. Though I guess that's just the problem we deal with.

Yup, this is why. It makes more money.

It would be really interesting if this could fundamentally damage bitcoin, but given the existing ASICs are specific to bitcoin, it may be a while. It's a happy and not so surprising thought if there is just a better and more profitable way to use power to compute than bitcoin.

The law determines to a huge extent the structure of our society. I'd be shocked if basketball players make more at the top level.

Android in China is different.

https://www.esper.io/blog/gms-vs-non-gms-for-android

Means 13x bigger models? I hear the data is the limit, but I don't believe it.

Good move, but removing self checkout in SF is annoying

It may also mean humanity is less likely to die a horrible death from aliens, so that's good

Not really using it much anymore. I want to get Steam integration setup. It's fun for movies, but only if you are watching yourself, and honestly, the comfort is not worth it. Still, really cool, pinching to control is magic, and I can't wait to see where this goes. Yeah - probably not worth it yet, if you dev, can be fun.

All of Reddit was freely and readily available just a few years ago. Just goes to show - archive and save what you love.

Who else thinks mxdys is an AI program gone rogue? Thank you sweet mxdys!