I don’t really agree with the rationale, because it is missing the most important part of aliases (and functions for that matter), that they are easily discoverable.
Re “Easier to bypass”: You can easily create a small script that adjusts the path (removes your alias-path) and exec to the original command.
It is a cool challenge, but why focus on the language rather than the method? It is not like Rust has some special jigsaw solving capabilities that make it more useful than other languages.
Seems like they’re only focusing on the method. Rust is only in the title in the first article, and the second one references the rayon library. There is practically nothing about Rust the language in any of this.
What I’d like to see most is support for efficient pagination. If you have a few billion rows, it should be as fast to scroll to the last page as the second page. Maybe a new table type is needed to enable this. FoxPro and Clipper were able to do this decades ago.
How did pagination work for FoxPro and Clipper? I can’t imagine how a database table could support O(1) insertions and deletions + O(1) access to the nth element + concurrent transactional reads and writes. So they must have been compromising on one or more of these properties. Depending on what exactly they compromise, I’m wondering whether it would be possible to implement the same kind of access pattern in Postgres as a set of tables, indexes and triggers.
The big challenge would be cache management, since you’d basically be materializing the results of every query that needed to support fast pagination, and you’d need to know when it was safe to discard those cached results. “When is the user done looking at this?” is always a tricky question in a stateless web app.
If you were willing to pin user sessions to database connections, you could probably get pretty far with temporary tables or with keeping cursors open across user interactions. That’s how database-backed desktop apps worked back in the day when I was writing them.
My hunch is that to the extent fast pagination is harder in PostgreSQL than it used to be in old-school database systems, it’s more because the client side is radically different than because the database is less capable.
That is good news. For the type of CRUD applications I’m thinking of, thousands of users is more than enough. If more users are needed, fast scrolling of tables with billions of records will need to be rethought, maybe eliminated from the design.
Doesn’t postgres have O(log N) insertion/deletion/access because it’s a b-tree underneath? You could augment the b-tree with order statistics (a la an order statistic tree), but that would come at a cost for a feature many users wouldn’t benefit from. I don’t know enough about postgres internals to know if there would be a way to enable it as an optional table feature in a low cost way.
Clipper and FoxPro are from the days before networking; there was no concurrency. Also, FoxPro wasn’t O(1), but it was very very fast at what it did. A little language that made noSQL databases and tables super easy to work with for making CRUD applications.
I used Clipper and then FoxPro as part of two technical support call center jobs for case management. Maybe the application didn’t handle networking directly but it was definitely used in a networking environment. In our case this was provided by Novell NetWare under MS-DOS. It was fast and when customers called in we would always have to ask for a “customer number” (which allowed us to probably get O(1) back then). When customers didn’t know that we had ways to look it up by first name and last name (which was also pretty quick). Now we never had a billion customers but I’m pretty sure we had thousands of customers and the same application was able to lookup invoices as well. It’s funny to think about how fast this solution was back then compared to how slow Salesforce is now with their own case management solutions.
Using cursors is an option that works pretty well. Also it’s possible with the right indices, not supporting arbritary pagination, to query without LIMIT and OFFSET but with WHERE order_col(id) > order_col(last_id_of_prev_pagination).
More O(your where clause), it’s difficult to extricate that, but yes this technique (“keyset pagination”) has roughly constant performance compared to offset pagination’s proportional increase with page distance.
I wonder if cgo with -flto would have a massive impact on the size too. Since the discovery should use just a tiny fragment of the AWS/azure/gcloud packages, maybe it could strip them too?
AFAIK the problem is reflection in the go packages: As soon as reflection is used lto does not strip unused parts because it does not know it’s unused.
The last thing on the JMAP news feed is almost two years ago, announcing Cyrus now supports it. Dovecot doesn’t and Thunderbird doesn’t. There are at least some folks slowly working on Thunderbird but I’ve not seen anything from Dovecot for a few years. It looks as if the attitude from Thunderbird is roughly ‘this is cool, we should support it as soon as Dovecot does!’ and the attitude from Dovecot is ‘this looks interesting, we should support it as soon as Thunderbird does’.
At the moment, it’s basically a Fastmail-only protocol. That’s a shame because it does look like a much better protocol than the combination of SMTP + IMAP + CalDAV + CardDAV + ManageSieve that you need to provide a MAPI/RPC equivalent with open protocols.
The big concern I have with neovim 0.5 is that something akin to spacemacs’ master-develop split will occur. 0.5 has been looming on the horizon for a long time now, and I hope that they can reconcile the fracturing landscape between 0.4 and 0.5 plugins by releasing soon.
but does Neovim or any other lsp-enabled modern vi-inspired editor provide Emacs key binding ?
reason I am asking is because I am not a ‘elisp’ user and do not extend or configure emacs that much – but emacs key bindings is the only thing I know.
For my ‘quick shell tasks’ I use joe (that has the jmacs command that enables emacs keybinding) – so I was thinking that may vi-inspired editors can do the same.
Learning vi keybindings pays off in multiples. There are so many applications (especially in terminal) that default to vi binds that you will often be pleasantly surprised how things “just work” if you try them.
i’m not convinced that this is a good argument as to the benefit of vi binds. there are advantages to vi binds. that other things use them by default doesn’t seem up there at all.
you can get *some* emacs-style bindings in vim, i know because i’ve tried. but emacs or an emacs clone works better for that, and vim works better for vimmish modal editing.
sure. but saying it pays off in multiples to learn a confusing keybinding system purely for that reason seems like a cyclic argument.
the original commenter wants to make neovim work like emacs. i agree that they are better off learning the vi binds if they want to use a vi-family editor. i think that there are much better justifications for doing that then “other tui applications are likely to support them”.
I live in the terminal and I’m struggling to think of many examples of other apps that use vi bindings. Meanwhile I also use neovim nearly all the time and I, like most regular vim users, change the (historic but awkward) default bindings. And I use Emacs-style shortcuts in the line editor.
To be honest, I suspect there’s a surprising amount of Vim users that use arrow keys. I’m one, and it’s not like I’m hunt-and-peck, only use arrow keys. I use them in addition to motions, because I could never develop the muscle memory for hjkl. It just doesn’t feel right to me, and the last thing I want to do is get used to it and start spraying hjkl into every non-vi editor I see.
I did develop the muscle memory at one point, and regretted it. I think hjkl is the most obsolete part of vim, they’re some good keys being taken up with commands that don’t need to be used that often, if you’re using vim effectively.
As someone using a 60% keyboard without cursor keys I have found rebinding the default cursor mappings to hjkl to work rather well since these keys are much more convenient to reach than where cursor keys usually are. So maybe one doesn’t need hjkl in vim but the mapping is surprisingly useful outside of it.
(I also accidentally discovered these vim bindings in Evince by forgetting to use modifier keys and just spamming j/k into the PDF reader)
You should be able to rebind them to your preference, though I don’t know if external scripts would break.
I always disliked moving my hand to the cursors, and now that I’ve been on a Kinesis Advantage since forever - whose cursors are crazy awkward - I would hate to have to use them.
Also someone said he /she uses hjkl on Dvorak!
Definitely YMMV based on the keyboard and its layout as well. FWIW I do kinda suck at using anything without a Vi mode anyway, beyond just the navigation.
I do you use hjkl on Dvorak. Not as much in Neovim, because I don’t need these motions, but in firefox (Vimium C), in evince, in tmux (remapped). It works just fine. Of course they are not next to each other (except awkwardly placed jk), but I don’t think about it and it works fine anyway.
I don’t know whether most regular vim users use hjkl in particular (I don’t. It could be interesting to survey vim users on questions like this!), but I was talking more generally. I think it’s very common to either remap Esc or bind something else to leave Insert mode, since reaching for Esc is widely thought to be awkward. I’ve also seen many example vimrcs that map ; (or something else) to : to avoid having to shift for it. I think it’s common to remap the leader too.
But I do use hjkl to navigate (in lieu of arrow keys anyway, when I’m not using other types of motions). That’s the part that I was surprised by. Not in a bad way or anything. Just one of those things where I thought basically every Vim user used hjkl. But I guess it’s just anecdotal.
quite a few programs have vi binds - cmus, ranger, either mutt or newsboat, but i don’t think both. i’m not a vim user anymore so i couldn’t comment on how modern regular vim users work, but i do see little benefit to not changing any of the keybindings.
theres often the “what if im on a server without my dots?” argument, i guess.
Kinda sorta not really. Neovim (and Vim) are built from the ground up in the vi-style modal paradigm, and they aren’t a fully configurable environment like Emacs where you could swap out the whole concept of modes for something else (aka, Emacs-style modes/bindings). The closest you can get is rebinding keymaps in insert mode to be closer to Emacs, like Tim Pope’s readline plugin does.
I prefer to code without touching a mouse. As my shoulder and neck hurt (I switch hands for the mouse, periodically as I am used to operate it ambidextrously, but it still hurts after a month – when I do 7-8K lines per month, or lots of debugging).
Which is why I prefer Emacs.
Big problems with Emacs however for me are as follows:
a) JS type validation using FB Flow across all of my mono repo subprojects - does not work
b) Gradle based projects (Android apps and my Java backends) – do not work
c) Java refactoring capabilities are not in the same league to Android Studio / IntelliJ
So I thought VI-based ecosystem might be more developed in those areas.
At the moment I just use Emacs key bindings in VS Code (for JS/Flow) and intelliJ (Java/Android) – but i seem to be grabbing mouse there too often.
When I work my Ansible side of things (Yaml configs) – I use emacs almost exclusively and in a Terminal window (even though I can run a GUI session, I prefer just a terminal or a login console).
I love vim-rsi! @lollipopman also made a similar thing for bash, in case you share terminals with people (pairing, debugging, etc). and can’t stand emacs mode and they can’t stand vim mode: https://github.com/lollipopman/bash-rsi
I really like mine as well. I got the box whites with blank keys. I’ll be honest, though, I find it really hard to find resources about how to actually use the thing for something besides typing on the default key map. I managed to get Chrysalis up and running, but once I make a new map, I honestly have no idea how to switch to it.
At first I used Chrysalis to change my keymap to something dvorakish. You can load premade keymaps from Chrysalis. If you did (or changed anything else) it will tell you it needs flashing. That worked great with my keyboard.
I would recommend anybody looking for bast testing and not already using bats (or bats-core) to have a serious look at https://github.com/chriscool/sharness
I just learned about insults, and that makes me extremely uncomfortable. Not because the insults themselves, but because supporting them is several lines too many, adding to the whole complexity of the tool, which should have only one purpose.
That means sudo supports plugins, which is again more lines of code than needed :)
I’m wondering which plugins are out there and do people genuinely need them?
I’ve been using the doas port for Linux for a few monthes now, and it works like a charm.
I don’t have sudo installed anymore (I still need a sudo symlink to doas though on Debian 9).
loki doesn’t do indexing. Here we do indexing. When it comes to design, it just append only log like Kafka. The main reason to write in rust for the memory handling. In go-lang, folks already facing lot memory-related issues. Personally, I haven’t benchmarked Loki in big deployment. I hope, there is lot of rooms in Pathivu for optimization, I released it in MVP state to get feedback from the community, whether folks would love Pathipu or not. So far, I heard good about pathipu. Got a lot of motivation to build further. <3
How does it do compacting? And are there already ideas regarding HA? Does it index after simple word splitting or is it doing anything fancy?
It is great having a different tool. Loki in HA is pretty involved and all the elasticsearch options are an operational nightmare. It was most unfortunate that oklog died. It’s great having something simpler and written with efficiency in mind.
Thank you for answering. Have you looked at the loki-grafana protocol? It would be great to use grafana for looking at the logs. That way, one does not have to train users to use a different tool.
Thanks - I wouldn’t have seen that. Interesting that they decided to keep their implementation independent, but I don’t think I’m quite as pessimistic as Jason about that. I think there’s value to the Wireguard ecosystem to have truly independent implementations, it keeps everyone true to the spec rather than letting the protocol drift to implementation defined.
Maybe? Or cloudflare could implement something that looks/smells like wireguard but is less secure, or includes cloudflare-specific features that are not in the spec, causing incompatibilities/confusion for users. I could see this easily going both ways. Only time will tell.
For sure, I hear you and I do think the concern you and Jason have is valid. I’m trying to be a bit less skeptical in this case if for no other reason than to be consistent with my view on web (HTML/CSS) implementations. I’d be the first to jump to advocate for Firefox as our defense against a monopolistic implementation of the Web as defined by Chromium/Google. Here certainly Jason is the smaller player so the power dynamics are different but I still think there’s positive opportunities from having two independent implementations in the ecosystem.
Where’d we get this trend of libraries self-described as “minimal”? Is there even a definition of what that means? If a library exposes 100 functions, but they’re all used, is that “minimal”? Wouldn’t it be better to have a library described as “Everything you need to solve X without filling in the gaps yourself”? Reminds me of “light” food… after all of human history desperately looking for calories, suddenly having *less” calories is the main selling point – “fat free half and half” being the worst example.
There is also an explanation in the email on why it is useful to have a minimal crypto library in the kernel. In short, you mostly don’t need flexible APIs when in kernel. That might be different in userland.
I don’t really agree with the rationale, because it is missing the most important part of aliases (and functions for that matter), that they are easily discoverable.
Re “Easier to bypass”: You can easily create a small script that adjusts the path (removes your alias-path) and
execto the original command.I’d like to have a comparison to stern. Has anyone tried both?
It is a cool challenge, but why focus on the language rather than the method? It is not like Rust has some special jigsaw solving capabilities that make it more useful than other languages.
For me the emphasis is on “bare”, in that the post does not use sophisticated libraries.
Seems like they’re only focusing on the method. Rust is only in the title in the first article, and the second one references the rayon library. There is practically nothing about Rust the language in any of this.
What I’d like to see most is support for efficient pagination. If you have a few billion rows, it should be as fast to scroll to the last page as the second page. Maybe a new table type is needed to enable this. FoxPro and Clipper were able to do this decades ago.
How did pagination work for FoxPro and Clipper? I can’t imagine how a database table could support O(1) insertions and deletions + O(1) access to the nth element + concurrent transactional reads and writes. So they must have been compromising on one or more of these properties. Depending on what exactly they compromise, I’m wondering whether it would be possible to implement the same kind of access pattern in Postgres as a set of tables, indexes and triggers.
The big challenge would be cache management, since you’d basically be materializing the results of every query that needed to support fast pagination, and you’d need to know when it was safe to discard those cached results. “When is the user done looking at this?” is always a tricky question in a stateless web app.
If you were willing to pin user sessions to database connections, you could probably get pretty far with temporary tables or with keeping cursors open across user interactions. That’s how database-backed desktop apps worked back in the day when I was writing them.
My hunch is that to the extent fast pagination is harder in PostgreSQL than it used to be in old-school database systems, it’s more because the client side is radically different than because the database is less capable.
You’re not wrong, but unfortunately Postgres has a limit on the number of simultaneous connections, usually on the order of hundreds or thousands.
The solution would be to materialize the results to either another store or unclogged tables that are periodically cleaned up.
That is good news. For the type of CRUD applications I’m thinking of, thousands of users is more than enough. If more users are needed, fast scrolling of tables with billions of records will need to be rethought, maybe eliminated from the design.
Doesn’t postgres have O(log N) insertion/deletion/access because it’s a b-tree underneath? You could augment the b-tree with order statistics (a la an order statistic tree), but that would come at a cost for a feature many users wouldn’t benefit from. I don’t know enough about postgres internals to know if there would be a way to enable it as an optional table feature in a low cost way.
Clipper and FoxPro are from the days before networking; there was no concurrency. Also, FoxPro wasn’t O(1), but it was very very fast at what it did. A little language that made noSQL databases and tables super easy to work with for making CRUD applications.
I used Clipper and then FoxPro as part of two technical support call center jobs for case management. Maybe the application didn’t handle networking directly but it was definitely used in a networking environment. In our case this was provided by Novell NetWare under MS-DOS. It was fast and when customers called in we would always have to ask for a “customer number” (which allowed us to probably get O(1) back then). When customers didn’t know that we had ways to look it up by first name and last name (which was also pretty quick). Now we never had a billion customers but I’m pretty sure we had thousands of customers and the same application was able to lookup invoices as well. It’s funny to think about how fast this solution was back then compared to how slow Salesforce is now with their own case management solutions.
Yeah. With the database backend secured, I’d like to make a lisp package to do all the Foxpro convenience functions.
Using cursors is an option that works pretty well. Also it’s possible with the right indices, not supporting arbritary pagination, to query without
LIMITandOFFSETbut withWHERE order_col(id) > order_col(last_id_of_prev_pagination).Thank you, that is O(1)?
More O(your
whereclause), it’s difficult to extricate that, but yes this technique (“keyset pagination”) has roughly constant performance compared to offset pagination’s proportional increase with page distance.I’ll give it a whirl, thanks
I wonder if cgo with -flto would have a massive impact on the size too. Since the discovery should use just a tiny fragment of the AWS/azure/gcloud packages, maybe it could strip them too?
AFAIK the problem is reflection in the go packages: As soon as reflection is used lto does not strip unused parts because it does not know it’s unused.
Amazing. I wonder if there is already a linter that works as both, standalone and as a native neovim plugin (only using the treesitter queries).
Is there any news re JMAP? It’s a nice idea but the goal of finalizing end of 2020 did not work out at all.
The last thing on the JMAP news feed is almost two years ago, announcing Cyrus now supports it. Dovecot doesn’t and Thunderbird doesn’t. There are at least some folks slowly working on Thunderbird but I’ve not seen anything from Dovecot for a few years. It looks as if the attitude from Thunderbird is roughly ‘this is cool, we should support it as soon as Dovecot does!’ and the attitude from Dovecot is ‘this looks interesting, we should support it as soon as Thunderbird does’.
At the moment, it’s basically a Fastmail-only protocol. That’s a shame because it does look like a much better protocol than the combination of SMTP + IMAP + CalDAV + CardDAV + ManageSieve that you need to provide a MAPI/RPC equivalent with open protocols.
The big concern I have with neovim 0.5 is that something akin to spacemacs’ master-develop split will occur. 0.5 has been looming on the horizon for a long time now, and I hope that they can reconcile the fracturing landscape between 0.4 and 0.5 plugins by releasing soon.
AFAICT all (or the overwhelming majority of the) plugins for 0.4 will work with 0.5.
sorry if the question is naïve,
but does Neovim or any other lsp-enabled modern vi-inspired editor provide Emacs key binding ?
reason I am asking is because I am not a ‘elisp’ user and do not extend or configure emacs that much – but emacs key bindings is the only thing I know.
For my ‘quick shell tasks’ I use joe (that has the jmacs command that enables emacs keybinding) – so I was thinking that may vi-inspired editors can do the same.
Learning vi keybindings pays off in multiples. There are so many applications (especially in terminal) that default to vi binds that you will often be pleasantly surprised how things “just work” if you try them.
i’m not convinced that this is a good argument as to the benefit of vi binds. there are advantages to vi binds. that other things use them by default doesn’t seem up there at all.
you can get *some* emacs-style bindings in vim, i know because i’ve tried. but emacs or an emacs clone works better for that, and vim works better for vimmish modal editing.
Having a ‘standard’ keybinding across multiple applications out of the box is quite useful.
sure. but saying it pays off in multiples to learn a confusing keybinding system purely for that reason seems like a cyclic argument.
the original commenter wants to make neovim work like emacs. i agree that they are better off learning the vi binds if they want to use a vi-family editor. i think that there are much better justifications for doing that then “other tui applications are likely to support them”.
I live in the terminal and I’m struggling to think of many examples of other apps that use vi bindings. Meanwhile I also use neovim nearly all the time and I, like most regular vim users, change the (historic but awkward) default bindings. And I use Emacs-style shortcuts in the line editor.
Wait really? Aye you saying most vim users don’t use hjkl to navigate? Or are you referring to something else?
To be honest, I suspect there’s a surprising amount of Vim users that use arrow keys. I’m one, and it’s not like I’m hunt-and-peck, only use arrow keys. I use them in addition to motions, because I could never develop the muscle memory for hjkl. It just doesn’t feel right to me, and the last thing I want to do is get used to it and start spraying hjkl into every non-vi editor I see.
I did develop the muscle memory at one point, and regretted it. I think hjkl is the most obsolete part of vim, they’re some good keys being taken up with commands that don’t need to be used that often, if you’re using vim effectively.
As someone using a 60% keyboard without cursor keys I have found rebinding the default cursor mappings to hjkl to work rather well since these keys are much more convenient to reach than where cursor keys usually are. So maybe one doesn’t need hjkl in vim but the mapping is surprisingly useful outside of it.
(I also accidentally discovered these vim bindings in Evince by forgetting to use modifier keys and just spamming j/k into the PDF reader)
You should be able to rebind them to your preference, though I don’t know if external scripts would break.
I always disliked moving my hand to the cursors, and now that I’ve been on a Kinesis Advantage since forever - whose cursors are crazy awkward - I would hate to have to use them.
Also someone said he /she uses hjkl on Dvorak!
Definitely YMMV based on the keyboard and its layout as well. FWIW I do kinda suck at using anything without a Vi mode anyway, beyond just the navigation.
I do you use hjkl on Dvorak. Not as much in Neovim, because I don’t need these motions, but in firefox (Vimium C), in evince, in tmux (remapped). It works just fine. Of course they are not next to each other (except awkwardly placed jk), but I don’t think about it and it works fine anyway.
I don’t know whether most regular vim users use hjkl in particular (I don’t. It could be interesting to survey vim users on questions like this!), but I was talking more generally. I think it’s very common to either remap Esc or bind something else to leave Insert mode, since reaching for Esc is widely thought to be awkward. I’ve also seen many example vimrcs that map ; (or something else) to : to avoid having to shift for it. I think it’s common to remap the leader too.
Yeah I remap Esc to caps lock.
But I do use hjkl to navigate (in lieu of arrow keys anyway, when I’m not using other types of motions). That’s the part that I was surprised by. Not in a bad way or anything. Just one of those things where I thought basically every Vim user used hjkl. But I guess it’s just anecdotal.
I also use hjkl to navigate, and I would remap Esc if I didn’t remap my keyboard to making pressing Esc easier.
quite a few programs have vi binds - cmus, ranger, either mutt or newsboat, but i don’t think both. i’m not a vim user anymore so i couldn’t comment on how modern regular vim users work, but i do see little benefit to not changing any of the keybindings.
theres often the “what if im on a server without my dots?” argument, i guess.
Kinda sorta not really. Neovim (and Vim) are built from the ground up in the vi-style modal paradigm, and they aren’t a fully configurable environment like Emacs where you could swap out the whole concept of modes for something else (aka, Emacs-style modes/bindings). The closest you can get is rebinding keymaps in insert mode to be closer to Emacs, like Tim Pope’s readline plugin does.
Thank you. I will look into this.
I prefer to code without touching a mouse. As my shoulder and neck hurt (I switch hands for the mouse, periodically as I am used to operate it ambidextrously, but it still hurts after a month – when I do 7-8K lines per month, or lots of debugging).
Which is why I prefer Emacs. Big problems with Emacs however for me are as follows:
a) JS type validation using FB Flow across all of my mono repo subprojects - does not work
b) Gradle based projects (Android apps and my Java backends) – do not work
c) Java refactoring capabilities are not in the same league to Android Studio / IntelliJ
So I thought VI-based ecosystem might be more developed in those areas. At the moment I just use Emacs key bindings in VS Code (for JS/Flow) and intelliJ (Java/Android) – but i seem to be grabbing mouse there too often.
When I work my Ansible side of things (Yaml configs) – I use emacs almost exclusively and in a Terminal window (even though I can run a GUI session, I prefer just a terminal or a login console).
What a great name for that plugin! https://en.wikipedia.org/wiki/Repetitive_strain_injury
I love vim-rsi! @lollipopman also made a similar thing for bash, in case you share terminals with people (pairing, debugging, etc). and can’t stand emacs mode and they can’t stand vim mode: https://github.com/lollipopman/bash-rsi
Not that I know of, but Emacs has LSP plug-ins so if LSP is what you’re after and you’re comfortable using Emacs I see no reason to switch.
Is there a comparison with bats or sharness?
I really like mine as well. I got the box whites with blank keys. I’ll be honest, though, I find it really hard to find resources about how to actually use the thing for something besides typing on the default key map. I managed to get Chrysalis up and running, but once I make a new map, I honestly have no idea how to switch to it.
Great little keyboard though.
At first I used Chrysalis to change my keymap to something dvorakish. You can load premade keymaps from Chrysalis. If you did (or changed anything else) it will tell you it needs flashing. That worked great with my keyboard.
I would recommend anybody looking for bast testing and not already using bats (or bats-core) to have a serious look at https://github.com/chriscool/sharness
See https://www.reddit.com/r/rust/comments/g917ad/smol_stjepang_a_small_and_fast_async_runtime_for/ for some information
I just learned about insults, and that makes me extremely uncomfortable. Not because the insults themselves, but because supporting them is several lines too many, adding to the whole complexity of the tool, which should have only one purpose.
Agreed. They are definitely an artifact of a more innocent age.
I assume it’s (soon to be) a sudo plugin and not in the core.
That means sudo supports plugins, which is again more lines of code than needed :) I’m wondering which plugins are out there and do people genuinely need them?
I’ve been using the doas port for Linux for a few monthes now, and it works like a charm. I don’t have
sudoinstalled anymore (I still need asudosymlink todoasthough on Debian 9).Great!
Is there a design overview or a comparison with, say, loki?
loki doesn’t do indexing. Here we do indexing. When it comes to design, it just append only log like Kafka. The main reason to write in rust for the memory handling. In go-lang, folks already facing lot memory-related issues. Personally, I haven’t benchmarked Loki in big deployment. I hope, there is lot of rooms in Pathivu for optimization, I released it in MVP state to get feedback from the community, whether folks would love Pathipu or not. So far, I heard good about pathipu. Got a lot of motivation to build further. <3
How does it do compacting? And are there already ideas regarding HA? Does it index after simple word splitting or is it doing anything fancy?
It is great having a different tool. Loki in HA is pretty involved and all the elasticsearch options are an operational nightmare. It was most unfortunate that oklog died. It’s great having something simpler and written with efficiency in mind.
Now, it won’t do any compaction. Regarding HA, planning to make it multi-node. currently, it’s a single node.
Indexing is simple splitting and stop word cleaning. If the user demands something fancy, I will implement.
The main idea for me to build this is to efficient and cost-saving.
In my previous company, there was a saying “Reducing AWS cost itself a buissness”
Thank you for answering. Have you looked at the loki-grafana protocol? It would be great to use grafana for looking at the logs. That way, one does not have to train users to use a different tool.
grafana plugin is in the pipeline. Folks can see in a week.
See https://lists.zx2c4.com/pipermail/wireguard/2019-March/004048.html for Jason Donenfeld’s response.
Thanks - I wouldn’t have seen that. Interesting that they decided to keep their implementation independent, but I don’t think I’m quite as pessimistic as Jason about that. I think there’s value to the Wireguard ecosystem to have truly independent implementations, it keeps everyone true to the spec rather than letting the protocol drift to implementation defined.
Maybe? Or cloudflare could implement something that looks/smells like wireguard but is less secure, or includes cloudflare-specific features that are not in the spec, causing incompatibilities/confusion for users. I could see this easily going both ways. Only time will tell.
For sure, I hear you and I do think the concern you and Jason have is valid. I’m trying to be a bit less skeptical in this case if for no other reason than to be consistent with my view on web (HTML/CSS) implementations. I’d be the first to jump to advocate for Firefox as our defense against a monopolistic implementation of the Web as defined by Chromium/Google. Here certainly Jason is the smaller player so the power dynamics are different but I still think there’s positive opportunities from having two independent implementations in the ecosystem.
Slides can be found on https://www.nycbug.org/index?action=view&id=10665
Just a minor nit: It’s
verbotenand notverbotten.Thank you for your careful feedback. I have fixed that now.
Where’d we get this trend of libraries self-described as “minimal”? Is there even a definition of what that means? If a library exposes 100 functions, but they’re all used, is that “minimal”? Wouldn’t it be better to have a library described as “Everything you need to solve X without filling in the gaps yourself”? Reminds me of “light” food… after all of human history desperately looking for calories, suddenly having *less” calories is the main selling point – “fat free half and half” being the worst example.
Code is different from food. Code is liability.
There is also an explanation in the email on why it is useful to have a minimal crypto library in the kernel. In short, you mostly don’t need flexible APIs when in kernel. That might be different in userland.
Maybe that should be merged with https://lobste.rs/s/tsfnqd/abc_conjecture_has_not_been_proved