From 927c2a8cd137431d4a6226f0a51ed24c348b2cef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Viktor=20S=C3=B6derqvist?= Date: Wed, 28 Aug 2024 20:04:23 +0200 Subject: [PATCH] Delete files MANIFESTO, BUGS and INSTALL (#958) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The MANIFESTO is not Valkey's manifesto and it doesn't even mention open source. Let's write another one later, or some other document about our project principles. The other two files are one-line files with no relevant info. They're polluting the file listing at root level. It's the first thing you see when you start exploring the repo for the first time. Signed-off-by: Viktor Söderqvist --- BUGS | 1 - INSTALL | 1 - MANIFESTO | 106 ------------------------------------------------------ 3 files changed, 108 deletions(-) delete mode 100644 BUGS delete mode 100644 INSTALL delete mode 100644 MANIFESTO diff --git a/BUGS b/BUGS deleted file mode 100644 index 02d5070fe9..0000000000 --- a/BUGS +++ /dev/null @@ -1 +0,0 @@ -Please check https://github.com/valkey-io/valkey/issues diff --git a/INSTALL b/INSTALL deleted file mode 100644 index 3083f1afd5..0000000000 --- a/INSTALL +++ /dev/null @@ -1 +0,0 @@ -See README diff --git a/MANIFESTO b/MANIFESTO deleted file mode 100644 index 01f2f2f33b..0000000000 --- a/MANIFESTO +++ /dev/null @@ -1,106 +0,0 @@ -[Note: This was the manifesto of Redis. It does not represent the ideals of Valkey, but is - kept in remembrance for the ideals that Salvatore had for the project.] - -Redis Manifesto -=============== - -1 - A DSL for Abstract Data Types. Redis is a DSL (Domain Specific Language) - that manipulates abstract data types and implemented as a TCP daemon. - Commands manipulate a key space where keys are binary-safe strings and - values are different kinds of abstract data types. Every data type - represents an abstract version of a fundamental data structure. For instance - Redis Lists are an abstract representation of linked lists. In Redis, the - essence of a data type isn't just the kind of operations that the data types - support, but also the space and time complexity of the data type and the - operations performed upon it. - -2 - Memory storage is #1. The Redis data set, composed of defined key-value - pairs, is primarily stored in the computer's memory. The amount of memory in - all kinds of computers, including entry-level servers, is increasing - significantly each year. Memory is fast, and allows Redis to have very - predictable performance. Datasets composed of 10k or 40 millions keys will - perform similarly. Complex data types like Redis Sorted Sets are easy to - implement and manipulate in memory with good performance, making Redis very - simple. Redis will continue to explore alternative options (where data can - be optionally stored on disk, say) but the main goal of the project remains - the development of an in-memory database. - -3 - Fundamental data structures for a fundamental API. The Redis API is a direct - consequence of fundamental data structures. APIs can often be arbitrary but - not an API that resembles the nature of fundamental data structures. If we - ever meet intelligent life forms from another part of the universe, they'll - likely know, understand and recognize the same basic data structures we have - in our computer science books. Redis will avoid intermediate layers in API, - so that the complexity is obvious and more complex operations can be - performed as the sum of the basic operations. - -4 - We believe in code efficiency. Computers get faster and faster, yet we - believe that abusing computing capabilities is not wise: the amount of - operations you can do for a given amount of energy remains anyway a - significant parameter: it allows to do more with less computers and, at - the same time, having a smaller environmental impact. Similarly Redis is - able to "scale down" to smaller devices. It is perfectly usable in a - Raspberry Pi and other small ARM based computers. Faster code having - just the layers of abstractions that are really needed will also result, - often, in more predictable performances. We think likewise about memory - usage, one of the fundamental goals of the Redis project is to - incrementally build more and more memory efficient data structures, so that - problems that were not approachable in RAM in the past will be perfectly - fine to handle in the future. - -5 - Code is like a poem; it's not just something we write to reach some - practical result. Sometimes people that are far from the Redis philosophy - suggest using other code written by other authors (frequently in other - languages) in order to implement something Redis currently lacks. But to us - this is like if Shakespeare decided to end Enrico IV using the Paradiso from - the Divina Commedia. Is using any external code a bad idea? Not at all. Like - in "One Thousand and One Nights" smaller self contained stories are embedded - in a bigger story, we'll be happy to use beautiful self contained libraries - when needed. At the same time, when writing the Redis story we're trying to - write smaller stories that will fit in to other code. - -6 - We're against complexity. We believe designing systems is a fight against - complexity. We'll accept to fight the complexity when it's worthwhile but - we'll try hard to recognize when a small feature is not worth 1000s of lines - of code. Most of the time the best way to fight complexity is by not - creating it at all. Complexity is also a form of lock-in: code that is - very hard to understand cannot be modified by users in an independent way - regardless of the license. One of the main Redis goals is to remain - understandable, enough for a single programmer to have a clear idea of how - it works in detail just reading the source code for a couple of weeks. - -7 - Threading is not a silver bullet. Instead of making Redis threaded we - believe on the idea of an efficient (mostly) single threaded Redis core. - Multiple of such cores, that may run in the same computer or may run - in multiple computers, are abstracted away as a single big system by - higher order protocols and features: Redis Cluster and the upcoming - Redis Proxy are our main goals. A shared nothing approach is not just - much simpler (see the previous point in this document), is also optimal - in NUMA systems. In the specific case of Redis it allows for each instance - to have a more limited amount of data, making the Redis persist-by-fork - approach more sounding. In the future we may explore parallelism only for - I/O, which is the low hanging fruit: minimal complexity could provide an - improved single process experience. - -8 - Two levels of API. The Redis API has two levels: 1) a subset of the API fits - naturally into a distributed version of Redis and 2) a more complex API that - supports multi-key operations. Both are useful if used judiciously but - there's no way to make the more complex multi-keys API distributed in an - opaque way without violating our other principles. We don't want to provide - the illusion of something that will work magically when actually it can't in - all cases. Instead we'll provide commands to quickly migrate keys from one - instance to another to perform multi-key operations and expose the - trade-offs to the user. - -9 - We optimize for joy. We believe writing code is a lot of hard work, and the - only way it can be worth is by enjoying it. When there is no longer joy in - writing code, the best thing to do is stop. To prevent this, we'll avoid - taking paths that will make Redis less of a joy to develop. - -10 - All the above points are put together in what we call opportunistic - programming: trying to get the most for the user with minimal increases - in complexity (hanging fruits). Solve 95% of the problem with 5% of the - code when it is acceptable. Avoid a fixed schedule but follow the flow of - user requests, inspiration, Redis internal readiness for certain features - (sometimes many past changes reach a critical point making a previously - complex feature very easy to obtain).