It's not so much the proprietary blobs, as the complete lack of documentation and debuggability for the peripherals. The PC platform, and several other SBCs, are either well documented, or at least give you the possibility of obtaining hardware with documentation.
That, combined with general flakiness (eg, power delivery issues for peripherals on older pis), and you end up with users blaming the software for hardware issues.
Klyo | NYC, In Person | Full Time | Full Stack Engineer | 100-150k, 1-2% Equity
At Klyo AI, we’re building the AI-powered data and marketing assistant for small businesses, starting with the med spa space. Forget dashboards, charts, and data tools—our AI seamlessly connects fragmented data to provide actionable insights, next steps, and clear answers, delivered in real time through text or email.
We’re pre-seed, growing fast (with paid clients who love us), and ready to scale. As our Founding Engineer, you’ll be at the core of building, improving, and scaling our technical foundation and direction, helping us bring this vision to life.
We are looking for product-minded full stack engineers who:
- Have had 5+ years of hands-on software engineer experience, especially at earlier stage startups
- Have experience leading projects end-to-end and taking ideas from conception to execution and iteration independently
- Are technically versatile:
- Experience building in AI/ML or NLP agents (OpenAI, LLMs, data pipelines, etc.).
- Strong backend experience with any programming language (we use python)
- Has worked with AWS infrastructure and PostgreSQL
- Familiar with React, Next.js or something similar for small/medium sized applications
- Customer-Focused: You care about solving real problems for users and can balance technical decisions with customer impact.
- Resourceful & Scrappy: You love taking ownership, moving quickly, and figuring things out with limited resources.
What We Offer
- Meaningful Equity (1-2%) in a fast-growing pre-seed startup.
- Competitive starting salary: $100K–$150K (with room for growth)
- A chance to be a foundational part of Klyo AI and shape the technical future of a product solving real customer pain points.
- A collaborative, product-focused environment with a mission to change how small businesses use their data.
How to Apply
Email your resume and a few sentences about why you’re excited to join Klyo
AI to founders@klyo.ai.
You can end up with events on file descriptors that you don't even have open -- they leak across process boundaries. And that means that if the file descriptor gets reused, you can end up with events on the wrong file descriptor.
From looking at the man page, it look like epoll does not return the file descriptor of the event; it returns a union containing user-defined data, although one of the union's fields is called "fd" because it is presumably intended to be used as the file descriptor.
However, this is still subject to the problems you mention, as well as that you presumably can no longer control events for a file descriptor if you do longer have it, so it is still seems a problem.
Putting the file descriptor in the "struct epoll_event" instead of "epoll_data_t" would have avoided the problem of events on the wrong file descriptor, but that still might not be good enough. (It could specify -1 as the file descriptor for events of file descriptors that you do not have access to.)
Some of this is just the problem with POSIX in general. I did consider such problems (of file descriptors and of event handling) in my own ideas of operating system design, which uses capabilities. I would want to avoid the mess that other systems is doing, too. A capability in this case is fundamentally a different data type than numbers (and IPC treats them differently), although I am not sure yet how to handle this in a suitable way within a process (tagged memory might do, although not all computers use tagged memory). (Note that most I/O is done using IPC and not by system calls; the number of system calls is limited and is usually only used for managing the capabilities and event handling. This would also improve security as well as other things.)
> From looking at the man page, it look like epoll does not return the file descriptor of the event; it returns a union containing user-defined data, although one of the union's fields is called "fd" because it is presumably intended to be used as the file descriptor.
Yes -- so how do you unregister an event after you close the file, or dup the file descriptor? You have no way to do that, you just keep getting events for a resource you no longer have open, so long as the parent or child still has it open!
It's incredible that you can set things up in a way that you get events on a resource you can no longer refer to in any way.
> so how do you unregister an event after you close the file ... You have no way to do that, you just keep getting events for a resource you no longer have open ... It's incredible that you can set things up in a way that you get events on a resource you can no longer refer to in any way.
Yes, I thought that too, it does not make much sense to me either. (I would suppose that you could close the epoll file descriptor, but then that would cancel all events, and not only that one.)
It's you again! Hi. We talked about capabilities a while back.
> I am not sure yet how to handle this in a suitable way within a process
If this is about implementing capabilities, I think partitioned capabilities should be the default.
> Some of this is just the problem with POSIX in general. I did consider such problems (of file descriptors and of event handling)
Yes, I think the kernel is trying to do too much. The more micro/exokernel it is, the better, IMO. Doesn't reduce (essential) complexity, but gives programmers the flexibility to tackle it how they want.
I'm also curious how you're thinking of doing event handling in general, like D-Bus or something. I think IPC is best left as a point-to-point bare bones communication channel, but even then it's pretty complex as the central load-bearing construct. For events, I expect there would be a lot of shared memory usage. It would use centralized services and/or userspace-defined capabilities to restrict who can receive certain events. I'm not too concerned since it's more of a userspace concern, unlike IPC.
> If this is about implementing capabilities, I think partitioned capabilities should be the default.
I am not entirely sure, but probably.
> I'm also curious how you're thinking of doing event handling in general, like D-Bus or something. I think IPC is best left as a point-to-point bare bones communication channel, but even then it's pretty complex as the central load-bearing construct.
I dislike D-Bus. My idea does not use any kind of shared message bus.
IPC would be done as messages; any process that has a reference to a capability can send messages to that capability and can request to receive messages from that capability; so these received messages can be events. The message can contain any bytes and also capabilities. The system calls would be used to request and send such events, with parameters for blocking/non-blocking, for multiple objects at once, and for atomic wait-and-send or wait-and-receive (in order to avoid some types of race conditions).
> For events, I expect there would be a lot of shared memory usage.
I had also thought of shared memory, although my intention is to allow network transparency and proxy capabilities (although network transparency would be implemented by using proxy capabilities), so I had thought to not use shared memory.
However, shared memory may be useful, but there may be ways to allow it to work transparently without otherwise affecting the protocol, e.g. with read-only mapping and copy-on-write mapping, or for a mapping to only be accessible by receiving events. A pass-through function would also be possible, to make some proxies more efficient. These features are essentially optimizations which can be optional to implement, so if you implement a proxy that does not use them, the programs will still work even if they are unaware that it uses a proxy that is unable to share memory.
There is then also other considerations such as audio/video/input synchronization; if you display a movie (or a game, which will involve input as well) then the audio/video would be synchronized, even if one or both are being redirected (e.g. you might redirect the audio output to a EQ filter or to a remote computer, or you might redirect both together to a remote computer or recorder, or to a program that expects input from a camera).
> It would use centralized services and/or userspace-defined capabilities to restrict who can receive certain events. I'm not too concerned since it's more of a userspace concern, unlike IPC.
Who can receive certain events would be a feature of the userspace-defined capabilities. Some services can be centralized, that many programs will be capable of using, either directly or through proxies; these proxies would be used for handling security and many other features.
Some of my ideas are similar (but different in many ways) like some other designs, including a few things listed in http://www.divergent-desktop.org/blog/2020/08/10/principles-... Proxy capabilities, and the Command, Automation, and Query Language, and the common data format used for most data, and other features of the system that I intended to have, will be able to help with some of the things listed there, as well as other benefits. (My ideas are actually mostly independent of that and other documents, but some of them end up being similar to those, and sometimes my ideas can then be refined when I learn more from such documents, too.)
If an AGI can outclass a human when it comes to economic forecasting, deciding where to invest, and managing a labor force (human or machine), I think it would be smart enough to employ a human front to act as an interface to the legal system. Put another way, could the human tail in such a relationship wag the machine dog? Which party is more replaceable?
I guess this could be a facet of whether you see economic advantage as a legal conceit or a difference in productivity/capability.
This reminds me of a character in Cyberpunk 2077 (which overall i find to have a rather naive outlook on the whole "cyberpunk" thing but i attribute it to being based on a tabletop RPG from the 80s) who is an AGI that has its own business of a fleet of self-driving Taxis. It is supposedly illegal (in-universe) but it remains in business by a combination of staying (relatively) low profile, providing high quality service to VIPs and paying bribes :-P.
I don't know that "legally" has much to do in here. The bars to "open an account", "move money around", "hire and fire people", "create and participate in contracts" go from stupid minimal to pretty low.
"Legally" will have to mop up now and then, but for now the basics are already in place.
Opening accounts, moving money, hiring, and firing is labor. You're confusing capital with money management; the wealthy already pay people to do the work of growing their wealth.
I was responding to this. Yes an AGI could hire someone to do the stuff - but she needs money, hiring and contract kinds of thing - for that. And once she can do that, she probably doesn't need to hire someone to do it since she is already doing it. This is not about capital versus labor or money management. This is about agency, ownership and AGI.
How so? This is about how errors are defined, not how they're propagated through the application. Feels like you didn't actually read what was being done by the OP.
Exceptions have a hierarchical nature to them in most languages, or at least have some sort of identity to them. Your correct that the author doesn't try to change the way errors are propagated, but you can see similarities between what the author is creating themselves, and what already exists in languages with exceptions.
reply