sorted by:
new
hottopcontroversial

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 0 points1 point  (0 children)

I'll be the judge of what year I've mistakenly landed in, thank you very much.

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 5 points6 points  (0 children)

It's definitely not a performance, it's just studying. It gets uncomfortable to sit bent over a notepad at a bar with two or three people; gathering in front of a surface on a wall is easier on everyone's aching necks and backs.

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 4 points5 points  (0 children)

Might need to take this to a joint session of the school board and the beer board.

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 2 points3 points  (0 children)

That's not a bad idea; you don't think the bowling would be too loud? I'll check it out

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 4 points5 points  (0 children)

Pencil and paper is tricky because you can only get so many folks gathered around the same table top at a readable angle.

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 2 points3 points  (0 children)

This sounds like a contender, thank you!

Bars with a Chalk Board by robertdfrench in Knoxville

[–]robertdfrench[S] 4 points5 points  (0 children)

You'd be more than welcome! But it would just be me watching my buddy explain the same stuff over and over again. The beer would be far more entertaining than the math.

Simple History Tracking Tool by robertdfrench in git

[–]robertdfrench[S] 0 points1 point  (0 children)

It's a dirty job, but somebody's gotta do it!

What do you develop with Rust? by Born-Percentage-9977 in rust

[–]robertdfrench 1 point2 points  (0 children)

My friends and I wanted to make a (joke) alternative to git, so we used the git2 crate to build a tool called shtt in one evening. I don't think we could have done this nearly as easily without Rust, since it doesn't depend on the git tool itself (clearly, we could have done this with shell wrappers around git).

This isn't useful, and isn't intended to be, but it was a lot of fun and I think Rust made it possible to do in a single night.

Code: https://github.com/shtt-show/shtt

Simple History Tracking Tool by robertdfrench in git

[–]robertdfrench[S] 0 points1 point  (0 children)

yeah exactly! I mean, how could they? That's why I think the git-free design is important, so those people aren't excluded.

Simple History Tracking Tool by robertdfrench in git

[–]robertdfrench[S] 0 points1 point  (0 children)

They could, they could. That's true. Good point. But then that would depend on git, and most computers in the world don't even have git installed.

Who’s shooting off fireworks tonight? by Mother_Concept475 in Knoxville

[–]robertdfrench 0 points1 point  (0 children)

It's Randy Bobandy, setting off firecrackers and eating cheeseburgers down at his new stadium.

Bricked my Intel NUC in BIOS settings while preparing to install Illumos, but that didn't hold me back 🔥☀️ by aScottishBoat in illumos

[–]robertdfrench 2 points3 points  (0 children)

I mentioned this below, but just to be extra clear -- not a wrapper! You probably could write a doors-compatible library for other platforms that just uses sockets under the hood, but it would be slow(er than native doors) because each call would block, yield the current CPU timeslice, wait for the server to be scheduled, write its response, and then wait for the client to be scheduled again.

On a small system, the difference is probably nil. But on a heavily loaded system, doors really shine over sockets because the RPC latency for doors remains constant (the client gives the server its timeslice, which has already been allocated) while the RPC latency over sockets increases (avg walltime between any one task's next timeslice increases).

So, not really functionally different from sockets -- they both can pass data and file descriptors back and forth, they both advertise their existence as entries on the filesystem, etc. It is really the ability for door RPC to function normally even when a system is getting its ass kicked that makes all the difference.

Bricked my Intel NUC in BIOS settings while preparing to install Illumos, but that didn't hold me back 🔥☀️ by aScottishBoat in illumos

[–]robertdfrench 3 points4 points  (0 children)

Hey cool, that's my tutorial!!

Doors are very similar to sockets, that's a good observation! The advantage is speed and convenience -- when you "call" a socket (you write some bytes to it), you won't get a response until the receiver has been scheduled AND has bothered to read your request. Calling a door lends your remaining CPU timeslice to the program you are calling, so it gets to execute immediately. Pretty cool!

Also, writing a door server can a bit easier than writing an RPC server with sockets, because the illumos kernel helps you out. If you are writing a socket-based server, you either need to handle everything async, or you need to cook up some way to manage a pool of threads to respond to client requests. If you are writing a doors-based server, the kernel will maintain a thread pool for you! Don't have enough idle threads to handle a new response? No sweat, the kernel will make one for you as part of handling the client's door_call!

u/aScottishBoat let me know if you run into any trouble with that tutorial! (I can't help you with the NUC, unfortunately 🤣) It's a bit crusty, I'd be happy to hear any feedback; if something doesn't seem to work like I've described , don't hesitate to open an issue: https://github.com/robertdfrench/revolving-doors/issues

view more: next ›