-
ix
edited
2 years ago
|
link
| on:
systemd developer asks tmux (and other programs) to add systemd specific code
I don’t like systemd, but it doesn’t seem like they’re wanting systemd to be a hard dependency; they want tmux to support systemd better. I don’t see the problem.
From the issue:
“In case it wasn’t clear, this dbus call should be compile time and run time optional, i.e. it should probably be only compiled in on Linux systems, and should be disableable with a switch (assuming that the default would be yes).”
-
-
-
They always seem trivial in isolation.
-
-
-
-
-
friendlysock
edited
2 years ago
|
link
| on:
9front Frequently Questioned Answers: An introduction to using a maintained Plan 9 distribution.
This is an unreasonably entertaining document.
From the section on various P9 forks:
9front — (that’s us) (we rule (we’re the tunnel snakes))
NIX — High performance cloud computing is NIX — imploded in a cloud of political acrimony and retarded bureaucratic infighting.
NxM — A kernel for manycore systems — never spotted in the wild.
Clive — A new operating system from Francisco J. Ballesteros, designed to generate grantwriting practice material and research projects for otherwise indolent students.
EDIT:
And apparently their mascot is no longer Glenda, but a touhou?
EDIT2:
Ahahahahaha the language support page.
-
-
Jesus christ it’s like the cartesian product of OpenBSD devs, Goonswarm, and Plan9.
I am in sheer awe.
-
-
-
-
Maybe just use
unix? Also maybe merging the 3 BSD tags into onebsdtag would be a good idea?-
-
-
-
-
I had not heard of it either. A google search for “nix plan 9” turned up http://lsub.org/ls/nix.html.
-
-
-
-
-
-
-
-
-
Depends. plan9 is more UNIX than UNIX, but c++ is rarely described as more c than c. That said, and jokes aside, as a categorical interest, plan9 is a good fit for UNIX. (At least imo). I’m curious who would filter one of (plan9, UNIX) but not both. However I’ve also argued that tags are good for searching and categorization, so I’m not actually objecting to a plan9 tag.
-
-
-
-
-
This seems like misuse of tools to me, though. A file system is not a VCS, no matter its snapshot capabilities.
Still really cool.
-
The Golang devs really want this, a smarter filesystem. They don’t want a VCS. They begrudgingly used Mercurial and when everyone kept whining they even more begrudgingly moved to git. They have intimated often that they want neither git nor hg, but are stuck with git.
They are not alone. Many, perhaps most devs hate babysitting a VCS. You want to be writing code, right? Not figuring out how to write commits, and commit messages, and rebase, and branching, and merging, and pulling, and updating, and pickaxing… It is not an unreasonable position that these things should be automated or abstracted away from the actual business of writing code.
-
The argument to be made here is probably that the complexity of Git, Mercurial, and the like is (largely) inherent to the problem being solved, and not incidental. That, essentially, it is not reasonable to expect that the difficulties of managing collaboration of multiple people on a single collection of code be abstracted away.
-
There is much improvement to what we can automate. For example, we could have regular automatic commits. Or, watch the filesystem and every save is an automatic commit. That would get some way towards what the Golang devs want. Branching could be “automatic”, as it was originally with bitkeeper, git, and Mercurial (i.e. branching by cloning, every time you copy the repo you already have a unique branch). Pushing and pulling could be a simultaneous “synch” operation, optionally automatically tied to some sort of CI to make sure the new synched state isn’t broken. Better merge algorithms and tools are possible, such as for example something like Semantic Merge which understands the syntax of what’s being merged (much better than line-by-line merging).
My point is, people hate VCSes, and rightfully so. There’s much improvement to be had. We shouldn’t take the current state of git or hg as inevitable complexity.
-
I always had the feeling that Darcs “it’s just patches” had a lot less complexity down the line, but still, it seemed to run into weird cases.
And that’s - IMHO - one of the big problems there. All VCSes are fine until 5 developers enter a room and don’t work quite in the pattern you expect.
-
-
-
-
Fix up your commits with squash or rebasing would be the norm in that case. I personally have run commit-on-save (and periodically) for projects that I had a lot of small performance improvements that I wanted to make sure didn’t introduce other bugs. Then with the magic of bisect you can find the bugs super fast (as long as you have good pre-commit hooks in place).
-
-
-
-
ZFS solves snapshotting state, but it does not handle telling a story. Commit histories are almost as important as the code its self – knowing why a hack exists is one Git blame away.
If nothing else, you’d need to pair a snapshotting filesystem with a code review system, then you’re back to needing to specify two revisions of a filesystem to diff.
Git’s model, while meta-filesystem, is superior IMO. I could imagine marrying Git with something like ZFS, but the portability of the .git directory is pretty excellent as opposed to being locked to a single filesystem.
-
ZFS solves snapshotting state, but it does not handle telling a story.
I understand, but the kind of person who hates a VCS is the kind of person who does not want to read or write stories. And that’s perfectly fine. If you don’t want the feature, you shouldn’t have to pay for it either. I see a good chunk of VCS users also really dislike it, writing commit messages like “fixed stuff” or “changes” and never really wanting to take the time to understand branches, merging, and all that.
It should be an option to be able to code without a VCS but with the ability to roll back to any version and to share your changes. That’s all that some people want: code, not commits.
-
-
-
-
-
Obviously. The analogy was only meant to better illustrate the features of ZFS. The author even says so explicitly:
Using ZFS as a replacement of Git for is probably not a good idea, but just to give you a sense of what ZFS supports at the file system level, let me go through a few typical git-like operations:
-
Counterpoint: this would make for fantastic bin file version control. Say maybe you had a repository filled with 3d models for a video game. the file sizes would be large and the text diffs would be useless. ZFS snapshots would be a slightly more space-saving way to handle versioning assets like that than simply making archives or full filesystem backups. Granted, it’d most likely require a knowledgeable dev-ops on the team to make and maintain those snapshots unless there was a nice frontend for the artists to use.
-
-
no more, no less, just a pager
-
Cool. What do you use to host your git projects?
-
That’s stagit: http://git.2f30.org/stagit/
-
-
-
People still use darcs?
-
-
-
To this day darcs still has possibly the most user friendly interface to a version control system that I have ever encountered. It’s biggest flaw was always it’s speed and how poorly it scales to larger codebases. But most users don’t have large codebases with years of history accumulated.
For those use cases it’s probably the safest easiest to use DVCS out there with Mercurial a close second.
-
-
-
-
-
-
OpenBSD’s
kshon OpenBSD,mkshon Linux.
-
Min is written entirely with CSS and JavaScript…
I’m mildly worried.
-
Congrats!
-
Why not sh rather than bash?
-
-
I don’t get the point of rootless.
It might be more secure and prevent breakage, but that kinda ends up at the point of “we’re too lazy to fix our problems just turn it off”. It could make sure the user isn’t an idiot, but it limits what the user can actually do; if you have root you should be granted everything, no questions asked. The only thing I see coming out of it is cases like this one.
-
Multimonitor utilities for use with window managers that don’t support them.
-
Doesn’t it use .xinitrc?
-
If your program has a need for privilege escalation, it might be worth examining how your life has ended up where it has.
-
-
I guess I think that programs that need uid 0 should be run as uid 0, and programs that don’t, oughtn’t. Too, a program that needs uid 0 is probably dealing with a configuration that can and should be changed. I don’t think that there are many programs that absolutely need uid 0.
-
-
-
Firefox has been a lot better on current than on 5.9 for me.
-
The problem is whether you should favor developer ease vs. the user’s wants/needs. In some cases, both are possible, but when the developer’s end becomes insanely complicated (aka, the curse of the incredibly specific bug), things have to change.
-
How did the author not know there is already a command named
vis(1)that is probably installed on every Unix-like OS?-
CLI-centric culture incentivizes a run on short names. We’re bound to run out soon.
-
-
-
-
-
-
Now to wait for the sidebar patch to be finished for 1.6…
-
-
Installed OpenBSD on my main machine. Also probably going to install it on my server.
Continuing learning Common Lisp.
-
trying to grasp functional programming after doing imperative for ~4 years, also learning haskell so i can do cool things with xmonad
I really enjoy Land of Lisp. There’s an on-going GSoC project to revive CLisp. I hope it succeeds.
I use SBCL nowadays as CLISP has segfaulted on me many times. Exciting.
I looked at Real World Ocaml on Amazon after seeing your list, and found ‘OCaml from the Very Beginning’ as a place to start in the reviews. It’s been really great so far. Not sure where you are at with Real World, but if you are looking for something more basic, I’d recommend it.