271–280 of 311 posts
Earlier quoted context omitted.
The new kid just learned to walk(1). http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd... 329 lines of code.
For nix: https://github.com/google/walk You can also use dmenu's stest to do the equivalent to find's -type f, { walk $PWD | stest -f }
Earlier quoted context omitted.
Isn't the kernel API banned from usage by userspace applications that aren't kernel32.dll (plus deliberately breaks ABI all the time) ? I can appreciate the strengths of the NT kernel, but if nobody is allowed to use it... (I suppose kernel drivers can, but that's still a very narrow range of applications) Also, while IOCP has the advantage of being older w.r.t. availability, I wonder how io_uring competes - I haven'…
There's a quote that goes something like "the last piece of software ever written for a novel OS is the UNIX compatibility layer". kernel32.dll is essentially that, except it isn't even UNIX compatible!
To be fair, even the namespace design of Plan 9 isn't very elegant, because file-base API hits its own limit pretty quickly. Linux had to abuse `ioctl` to avoid that. The best namespace design should come from the microkernel world, where isolation can be achieved by simply rerouting outgoing API calls to alternate servers. This will also allow injecting all kinds of crazy/complicated policies in the middle.
That's... More or less how it works in plan 9? http://man.9front.org/3/mnt
Earlier quoted context omitted.
I always feel guilty that find . | grep is easier for me than remembering how find's flags work. But I think it's really a case of my brain rejecting exactly the redundant baggage you're speaking of here.
What's hard about "find . -regex -exec /;" Hardest thing that comes to mind is there's some slight portability differences to look out for between GNU find and BSD find that may require a quick man dive with relation to the max depth handling, but that's about it.
I've used find extensively in the past two decades and even read the man page (gasp) on occasion, but it's one coreutils command that I have always found cumbersome. I recently discovered fd and I have a feeling that I will be switching to that where I can, muscle memory be damned.
The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interf…
Wait until you realize you need asynchronous I/O operations, and then you also need to manage caching on I/O operations, and you also need to distinguish appends from over-writes, and that you also need to care about who allocates memory for the buffer being written to / read from... And then comes concurrency and exceptions... UNIX "design" anticipated none of the above. And it's not like these things were somehow u…
Earlier quoted context omitted.
Unix being stringly-typed is a huge problem. For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output https://github.com/hakandundar34coding/system-monitoring-cen... the author literally doesn't care since it works with coreutils `ps` it's a culture problem
Doesn't ps just parse /proc entries these days? Seems like an odd hill for that dev to die on.
Earlier quoted context omitted.
DCOM is built on top of MS-RPC which is originally a DCE-RPC variant yes, but DCE-RPC isn't object oriented and all the interfaces inside Windows are. You can't just open a local socket and speak DCE-RPC to Windows services, you have to use COM.
The RPC protocol used by Windows between machines (e.g. for registry access, file sharing, setting permissions, etc.) isn't COM-based. Similarly, the RPC used internally (e.g. to talk to win32k) isn't COM-based. My Windows knowledge is quite stale but when I was developing for it COM was used for APIs but it wasn't much used for RPC.
COM is used both to expose in-process APIs that you invoke and also to do RPCs between services, but that's an implementation detail that only sometimes matters. Historically most stuff ran in the kernel (not any more) so there wasn't a big need for inter-process COM. These days there's more microkernel design but the underlying APIs were all 1980s era flat C APIs so indeed COM is of less relevance for remoting them.
Earlier quoted context omitted.
io_uring is a more modern API to file access. Actually I think it would be great if everything was a file and the communication with the kernel was only with io_uring.
> it would be great if everything was a file This is a bad design. Process is not a file because you cannot send signals to a file, or cannot debug a file. Network socket is not a file because you cannot get file's peer address. Shared memory is not a file. And so on.
https://man7.org/linux/man-pages/man2/pidfd_send_signal.2.ht...
Also sockets have the concept of ancillary channels used to deliver out of band data (see recvmsg). If every system resource had such channel, it could be used for control similar to how sockets do it.
Earlier quoted context omitted.
When everything is a file, what is a "file" becomes flexible. In Plan 9, you send signals and messages to a file by writing to it. And read messages by reading from it. It's in essence no different than OOP or actor model or what have you.
An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does en…
Yes? All interfaces do that, especially system interfaces. It's the whole purpose of interface - to provide implementation logic in a usable form. Try to call the kernel by hand and see the difference.
Earlier quoted context omitted.
« To name one egregious example, omitting find(1) in favor of piping du(1) [...] to grep(1) is not an improvement » I agree, but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions. I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences w…
> No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned. That seems like an insane concept. I honestly can't see how it can be justified in a world where pretty much every compiler since the 90s has support for `#pragma once` and detects include guards automatically without re-reading the header.
Can you illustrate this with examples? Ones that are from outside of the Unix and C family, just to make it clear that we aren't talking about tweaks to old tools?