Since I linked to a repo on code.driusan.net I finally got around to writing a blog post about my distributed bug tracker / source code manager that it's based on.
I was going to write it after I got my rust port up to parity with the original #plan9 version, but I screwed up my laptop's hard drive and lost the rust port (it turns out refusing to put it offsite with git because I wanted to be sure I was dogfooding my scm wasn't a great idea.) so I'm just writing the post now.
I almost hacked up my webfs enough to open a websocket connection to ws://echo.websocket.org but I don't know if I'll be able to finish it because webfs isn't really intended to be full duplex and I don't know how to write to the connection after opening it. #plan9
Video of the interview with #guix founder @civodul is available. A great chat about the #nix deployment model, his interested in #guile and #free software. Lots of interesting chat about motivation in #freesoftware, #gnu and #linux - as well as the Plan9-ification of Guix!!
At work (zoo.dev) we use a lot of rust :ferris: and specifically tokio for our servers -- I've been spending some time trying to develop style with it. I figured i'd be good chance to finish a DECADE OLD hack I wanted to implement. It's been a few weeks of nights/weekends hacking on it, and I just wrote it up after getting my old blog back online at https://notes.pault.ag/debugfs/
Running #plan9front in my #thinkpad x280 for this entire year is going to be distractionless and super productive workstation. I dinnae miss the browser at all. Also I'm learning tons of new #computing things. There is no way back. Thank you to every single person and to the developers for this amazing experience. #plan9
@sirjofri I do the same, for quick searches I'm using the mobile browser. Also I am a #geminiprotocol user so it makes sense to use it under #plan9 as is more convenient.
@mattl Well, #NixOS is, both, a rather old distribution but also the latest hyped distro many #Linux geeks are switching to.
Beneath #Plan9, this would be one of the more "different" operating systems you could cover. Requires a bit of a learning curve since there are many new concepts and many common concepts are removed.
In the spirit of #plan9, I wish that I could simply install gcc-aarch64 and cross build easily. I guess I'd also need all the dependencies in their aarch64 version, and the filesystem hierarchy should have a "correct place" for libraries for other architectures.
"Plan 9 was in some way a second implementation of the core concepts of Unix and C, but reconsidered for a world of networked graphical workstations. It took many of the trendy ideas of late-1980s computing, both of academic theories and of the computer industry of the time, and it reinterpreted them through the jaded eyes of two great gurus, Kenneth Thompson and Dennis Ritchie (and their students)"
Does anyone else spend a lot of time thinking about what the developer experience of a pure #CSP could be? I think the immediate issue is the language itself needs to have CSP primitives baked in and not layered on (no matter how cool the party trick). I say this because the debugging experience can’t be wading through state machines you did not write yourself. Exene (written in concurrent ML) is only prior art I am aware of. Maybe #plan9 stuff?
Using 9front for the first time and I really like it. There has certainly been a learning curve coming from Linux and BSD, but I'm getting there. Just need to set up Mail, Faces and an IRC client next.
So far I've just edited the theme, set up a couple functions, customised my riostart, edited the winwatch source code to reduce the padding etc. Everything I've done is pretty much in the acme window.
I'm starting to get curious about Plan 9 from Bell Labs. Beyond its wonderful name, just scratching the surface i can see it had some really interesting ideas and concepts.
Did anyone here ever use it? What was it like? I'd like to understand if some of its ideas made their way to other pieces of free and open source software we use today?
what problems do you run into with git's staging area? right now I'm feeling like the staging area is one of the least confusing parts of git (merging, branches, and remotes seem to cause people a lot more problems) but I'm very open to writing about it if there are problems
@b0rk in our #plan9#9front git implementation there was a decision to not have a staging area, because there might be better alternatives, iirc, but I don't know the details. Maybe someone from our bubble can tell more?