Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
musicmatze
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
13 ms
·
31.
▲
by
musicmatze
5y ago
Cannot say too much about that since I only tried alacritty once, and from what I see it is mainly speed. And yes, that's actually noticable, at least on my machine.
32.
▲
Butido – A Linux Package Building Tool in Rust
(beyermatthias.de)
4 points
by
musicmatze
5y ago
|
0 comments
33.
▲
by
musicmatze
6y ago
Author here. I started learning prometheus and grafana and decided to write an exporter for the music player daemon. Here's my writeup on the journey.
34.
▲
Writing a prometheus MPD exporter (in Rust)
(beyermatthias.de)
1 points
by
musicmatze
6y ago
|
1 comments
35.
▲
by
musicmatze
6y ago
The No.1 reason for me is that it makes you use git like it is supposed to be used: Via email and your MUA. The "pull-request-model" invented by github is an abomination of a workflow. Communities stop scaling because of it (see n
36.
▲
by
musicmatze
6y ago
Rails was released 16 years ago (according to wikipedia). Rocket just got the first release that builds on stable rust. Thus: Give it 15 years, we'll be there!
37.
▲
by
musicmatze
6y ago
I use systemd mainly as a user, only on one of my instances I do some more "admin" like stuff. It works and is absolutely reliable for what I do and did by now. I couldn't imagine going to something else and would also see no
38.
▲
by
musicmatze
8y ago
1 401 16.04% git 2 337 13.48% fg 3 241 9.64% cargo 4 234 9.36% cd 5 197 7.88% ls 6 195 7.8% tig 7 165 6.6% task 8 81 3.24% vim 9 38 1.52% imag 10 31
39.
▲
Brig – A file synchronization tool on top of ipfs
(github.com)
2 points
by
musicmatze
8y ago
|
0 comments
40.
▲
NixOS 18.03 released
(groups.google.com)
3 points
by
musicmatze
9y ago
|
0 comments
41.
▲
by
musicmatze
9y ago
Would love it! OP please open-source it!
42.
▲
by
musicmatze
9y ago
Reposting this ( https://news.ycombinator.com/item?id=16124702 ) as top-level comment, because I think it is worth it: The git-dit project ( https://github.com/neithernut/git-dit ) provides a distributed i
43.
▲
by
musicmatze
9y ago
https://github.com/neithernut/git-dit provides a distributed issue tracker inside git, without cluttering the repository with unneeded files and also gives the possibility for having tree-like conversation, referencing
44.
▲
Blueprint of a distributed social network on IPFS
(beyermatthias.de)
7 points
by
musicmatze
9y ago
|
0 comments
45.
▲
by
musicmatze
10y ago
Awesome, thanks for your feedback! Yes, we did consider C++ as well, but IMHO the tooling is better with Rust and we are both familiar with it, so that seems to be the better choice.
46.
▲
by
musicmatze
10y ago
Hi. Awesome you want to contribute! Well, take part in discussions in the github issues (which should be transferable at some point and therefor also show up in git-dit), would be the first step. We now have to sort out what our next steps
47.
▲
by
musicmatze
10y ago
Hi. As angrow has written, yes, patches/patchmails would be an option. We did this explicitly leaving out the access-control problem, which is a hard problem by itself. Currently we would think of emails as first step, which clearly wo
48.
▲
by
musicmatze
10y ago
Hi. Due to the nature of git, this is not possible after the issue is distributed to the network, hence there is no possibility to implement such a thing.
49.
▲
by
musicmatze
10y ago
Hi. Thanks for your reply. We already thought of that, and we concluded that it would be a great idea to make it configurable whether the current repository (the `pwd`) should be used for issue storage or another git repository. So one can
50.
▲
by
musicmatze
10y ago
Co-Author here. git-dit is a distributed issue tracker in/for git, currently implemented as proof-of-concept in Bash. If you want to play with it, make sure you use current git versions. It differs from things like bugseverywhere and f
51.
▲
Show HN: Git-dit – a distributed issue tracker for git
(github.com)
129 points
by
musicmatze
10y ago
|
37 comments
52.
▲
by
musicmatze
10y ago
Well, from what we've experienced during the implementation and while using our tool, it works _really_ well!
53.
▲
by
musicmatze
10y ago
I just checked git-appraise and while it looks rather mature, it uses (as far as I can see by now) an approach which is not that nice if you have multiple public remotes. Also, as far as I can see, each submitter must be able to push to tha
54.
▲
by
musicmatze
10y ago
They say that git data (repos and wikis) are not affected... well ... if they would have had their PRs and Issues in git repositories, too... Disclaimer: Worked on a POC for exactly this last semester and going to publish my results in the
55.
▲
by
musicmatze
10y ago
I am developing a CLI-PIM suite (commandline personal information management suite) called imag[1]. The goal of the tool is to use known commandline tools (for example taskwarrior (todo), khal (icalendar), khard (vcard), beancount (financia
56.
▲
by
musicmatze
10y ago
What I really wonder right now: When reviewing my own PR on my own repo, I cannot select that the things I proposed must be resolved before the PR can be merged - why is that? Am I not allowed to keep myself from merging things I considered
57.
▲
by
musicmatze
10y ago
Is there a way to make this work with `set -o vi`? So I can use j/k to browse the history this way?
58.
▲
by
musicmatze
10y ago
Absolutely. I'm using it for two or years or something by now and the very first thing I do when having a new host: install the mosh server.
59.
▲
by
musicmatze
10y ago
This looks really interesting. I've been thinking about the problem of distributed issue tracking lately... and the set of sub-problems it has (authorization and authentification, synchronization and so on) ... I'm not sure all th