There are certainly traits and tactics that can enhance your chances for a good outcome, but nothing is guaranteed. Every story of success or failure is just another anecdote.
2,060 karma · joined February 24, 2022
There are certainly traits and tactics that can enhance your chances for a good outcome, but nothing is guaranteed. Every story of success or failure is just another anecdote.
We could even cut out a ton of middle-men and return congress to a part-time job. One can only dream, right?
While just about every LLM is trained on data that far surpasses the output of just one person, or even a decent sized group; it will still reflect the average sentiment of the corpus of data fed into it.
If the bulk of the training data was scraped from websites created in 'WEIRD' countries, then it's responses will largely mimic their culture.
I decided to build it using Qt (Qt Widgets in c++) mainly because my whole data engine is also in c++. Since it just uses standard windows and dialog boxes; I haven't felt the need to keep up with the latest Qt version. I am still using Qt 5 (I think revision 13 or 15).
I have been contemplating moving to Qt 6. Have users noticed a big difference (e.g. performance) between Qt 5 and Qt 6?
I have written articles about it and made the binaries freely available on my website under an 'open beta'. People keep telling me that if I really want it to take off, I should open source it.
So far, I have resisted doing that, for many of the reasons that you cited.
There are words you don't know or know how to use them properly. It will help you learn the second language better, while also helping you to not gloss over whole passages.
However; a different query (e.g. SELECT name, phone_number FROM table) might result in fewer seeks if the data is stored by column instead of by row.
The article only seems to address data structures with respect to indexes, and not for the actual table data itself.
While crime is definitely a major problem, especially in big cities; it only takes a few news stories to convince some people that almost everyone is out to get them.
There are rich, healthy, popular people who feel awful. They might feel like a failure because they are constantly comparing themselves with more successful people (or at least believe all the wonderful posts on social media). They might immerse themselves in negative thoughts about the world and their own immediate surroundings.
But if you are always counting your blessings and trying to serve people who are less fortunate; you might realize that 'It's a Wonderful Life'.
Tax compliance. Defending against frivolous lawsuits. Chasing permits. Settling labor disputes. Sensitivity training. Wading through government red tape.
Each of these and dozens of others drain resources (time and money), but contribute little to productivity.
Hard to tell if anyone was 'comfortable' with that.
I don't know if there is, but I wouldn't be surprised if there is a license available that restricts you from porting the code to MS Windows or any other proprietary OS.
My project Didgets (short for Data Widgets), started out as a file system replacement. I wanted to create an object store that would store traditional file data, but also make file searches much faster and more powerful than other file systems allow; especially on systems with hundreds of millions of files on them. To enhance this, I wanted to be able to attach contextual tags to each Didget that would make searches much more meaningful without needing to analyze file content during the search.
To facilitate the file operations, I needed data structures to support them. I decided that these data structures (used/free bitmaps, file records, tags, etc.) should be stored and managed within other Didgets that had special handling. Each tag was basically a key-value pair that mapped the Didget ID (key) to a string, number, or other data type (value).
Rather than rely on some external process like Redis to handle tags, I decided to build my own. Each defined tag has a data type and all values for that tag are stored together (like column values in a columnar store). I split the tag handling into two distinct pieces. All the values are deduplicated and reference counted and stored within a 'Values Didget'. The keys (along with pointers to the values) are stored within a "Links Didget'.
This makes analytic functions fast (each unique value is stored only once) and allows for various mapping strategies (one-to-one, one-to-many, many-to-one, or many-to-many). The values and the links are stored within individual blocks that are arranged using hashes and other meta-data constraints. For any given query, usually only a small number of blocks need to be inspected.
I expected analytic operations to be very fast, like with other OLAP systems; but I was pleasantly surprised at how fast I could make traditional OLTP operations run on it.
I have some short demo videos that show not only what it can do, but also benchmark many operations against other databases. Links to the videos are in my user profile.
Could you clarify what you mean by 'this limits your write capabilities'?
My system does analytics well, but it is also very fast with changing data.
I also think that some of those systems (e.g. Duckdb) also use indexes.
It is conventional wisdom that indexes are absolutely essential for any relational table of at least reasonable size (e.g. thousands of rows) and is accessed more often than daily. Indexes can be a pain to create and maintain; but can greatly speed up queries and primary key validations. The pain mostly comes from having to figure out what indexes to create and how often to maintain them, rather than doing the actual thing.
Indexes also have a performance penalty for any table updates. Creating new rows, updating existing rows, or deleting rows all require updates to each index.
But are indexes really required? I am creating a new kind of general purpose data management system (a kind of object store) called Didgets. The tagging mechanism that I invented to allow tags to be attached to each data object, are key-value stores that essentially form a set of columnar stores.
I found that these columnar stores could also be used to create regular relational database tables. The data is structured such that indexes are not needed. All the tests that I have run (up to a thousand columns with over 100 million rows), show that query speeds are equal to, or better than other database systems that are well indexed.
The system is still under development, so it is still missing some key features that would make it a drop-in replacement for other databases; but it proves that it is possible to structure relational data such that query speeds can be optimal without needing separate indexing structures that have to be maintained.
I do care when other people in tech insist that I should care, and that I should make decisions based on the identity of certain individuals.
I am reminded of an early cartoon of a dog sitting at a computer saying 'On the Internet, no one knows you are a dog!'
I don't know that there are more or less of them in tech, than in other fields.
I was originally going to just get 64GB of DDR5-6000, with the option of adding another 64GB later, thinking the price might drop even further. At the last minute, I decided to get the whole 128GB instead. Glad I did.
Job offers passed on because it wasn't the perfect fit. Marriage chances missed because the perfect soul mate must still be around the corner. Good schools rejected because it wasn't their dream school.
Luck often accompanies those willing to accept less than perfect in many cases.
Also, does anyone know how long communication with the probe is disrupted when the sun is directly between them?