In the article, mentioned Linux is mentioned as the underlying OS. Wonder what approach Ubicloud takes (if any) to have actual diversity in the software stack for the purpose of reliability and security. My assumption here being, that different OSes, while increasing the attack vector also make it more likely that the whole fleet is not susceptible to the same software problem or vulnerability at roughly the same time. Just something I started pondering about after seeing Hetzner, which is quite popular in the BSD land.
Because with schema-based sharding in Citus, the schemas are the sharding unit and the system can move them to new nodes being added to the cluster.
You can start with all your microservices sharing a single node, add nodes and have the storage layer distributed horizontally in a way transparent to the services themselves.
There no longer is an enterprise version, what runs on Azure is the exact same Citus that you can run yourself. We even invested in Patroni, to make it easier for the community to self-host Citus with HA setups.
While we obviously want people using Citus on Azure, having Citus as a viable open-source choice is our path to achieving that. I wasn't part of the company when the acquisition happened so can't speak to that, but I can imagine how that could have made sales at the transition time unclear.
Personally I would also like to add, that the team is full of long term open-source contributors. We contribute both to PostgreSQL and projects around it (like pgbouncer). I understand and respect your reservation, but wanted to share my perspective on it.
Schemas are groupings of tables and other entities that can be defined within a database. You can think of them like of a namespace in programming languages. You can have the same table definition, within the same database, defined multiple times (each in a different schema) and each holding different data.
By large and small we are referring to the amount of data each schema holds currently. They can grow over time and some of them may become very big while others will remain small (storage wise).
Hi Nathanba, I am a technical program manager for the Citus extension at Microsoft.
> Citus also exists for Postgres but their docs basically tell you that it's only recommended for analytics
Could you point me at the docs that made you think that? We find Citus very good at multi-tenant SaaS apps (OLTP), IoT (HTAP) workloads and analytics (OLAP).
> And it sounds like all it's doing is a basic master-slave postgres setup with quite a few manual things you have to do to even benefit (manually altering tables to make them sharded/partitioned)
This is true for now. We are looking into ways to make onboarding easier. That said, the time spent on defining a good sharding model for your data often leads to very good perf characteristics. Regarding the architecture, I personally find Citus closer in spirit/design to what Vitess is doing. Additionally, every node in the cluster is able to take both writes and reads, so I don't see the parallel to a basic primary/secondary setup.
> But with all that, as Joe Armstrong once jeered, no amount of type checking would catch the following bogus code:
It is worth to note that the stated problem, of accessing a file after it is closed was addressed in the Phd thesis by [1] Joe Armstrong in which he suggested a solution for exactly this problem by introducing a new testing & development methodology he named "protocol checkers" (9.1 Protocols, page 195). Relevant quote from the thesis:
> Given a protocol which is specified in a manner similar to the above
it is possible to write a simple “protocol checking” program which can be
placed between any pair of processes.
The protocol is a state machine, which would detect the attempt to write to a file after it was closed.
Developers are categorized as people with commit access to the project. So contributing patches itself is not enough to add entries to this specific file.
- Meetings are remote first. If at least one person is remote then the whole team video calls in. There is nothing worse than being a person on the virtual end trying to understand a mic grabbing voice from a room full of people.
- Schedule peer programming sessions, especially with less senior staff. Without the office environment they have less opportunities to grow.
- All meetings should have a note listing all decisions made.
- Promote async communication. Have people describe a problem instead of saying hi and waiting for a reply.
I stopped using multiple browser for exactly that purpose. It actually increases your attack surface. While compartmentalization of browsers helps somewhat against tracking you now have to keep all of them updated. RCE bug in one of them already compromises everything you have on your machine, so having multiple browsers just means the attacker can pick from a wider array of targets.
History is funny. KHTML (a KDE project) was repurposed to WebKit by Apple and integrated with Safari. Which in turn was taken by Google that built Chrome on it. They later diverged more and now other browser are being built on repurposed Chrome. It would be funny if Safari was really replaced by Chromium as that would mean the offspring has eaten the parent.
It used to have actual Windows specific crypto code[1] which has been removed in the linked commit.
I assume this has been ported from Windows and later never implemented the ripped out components. That said, I don't know the windows API so apart from confirming that they exist in Windows docs[2] I can't assess how valid their usage was.
Cool project. Have you known that PostgreSQL was initially written in Lisp?
> By a process of elimination, we decided to try writing POSTGRES in LISP. We expected that it
would be especially easy to write the optimizer and inference engine in LISP, since both are mostly tree processing modules. Moreover, we were seduced by AI claims of high programmer productivity for applications written in LISP.
> We soon realized that parts of the system were more easily coded in C, for example the buffer
manager which moves 8K pages back and forth to the disk and uses a modified LRU algorithm to control
what pages are resident. Hence, we adopted the policy that we would use both C and LISP and code
modules of POSTGRES in whichever language was most appropriate. By the time Version 1 was operational, it contained about 17000 lines of LISP and about 63000 lines of C.
> Lastly, POSTGRES supports the notion of time travel. This feature allows a user to run historical
queries. For example to find the salary of Sam at time T one would query:
retrieve (EMP.salary)
using EMP [T]
where EMP.name = "Sam"
> POSTGRES will automatically find the version of Sam’s record valid at the correct time and get the
appropriate salary.
Regarding your project:
> Databases are implemented as directories containing one file per table.
PostgreSQL splits tables into 1 GB segments (1 segment is one file). This is done for filesystems that can't have large files. Isn't one file per DB too limiting in that regard?
Are you aiming to be ACID compliant? Can you expand on 'versioned'? PostgreSQL achieves that with copy-on-write, did you take the same approach? I quickly looked over the code, it's been a while since I read some lisp. The on-disk representation seems to be just key value records where each record can be a sexp(?). Where is the relational part and do you plan to implement a query language?
He assumed I was not working or doing work for a different manager (they implemented matrix management and he was at HQ 70 km away from the town I worked at). I made a judgement call as that migration was a $20 mln project. That corporation had time budgeting. I was supposed to account in a production tracking system every task I did in 15 minute granularity. I have a ton of crazy stories like that out of that place.
In essence, the guy was a micromanager with trust issues. They later replaced him, with someone that was actually worse.
It is impossible to measure someones productivity using metrics like commit counts and SLOC. There are times where I don't commit for weeks and provide actual business value by solving direct client issues without even a ticket being present.
At one time at my second IT job, I had a manager reprimand me (yelling over the phone) that I was away from my desk. I was remotely supporting a bank fixing consortium credit contracts (substantial amounts) after a migration. I was told to stop doing that. So, I told the support tech that my 1-up blocked this. He told the people at the bank; this went up the chain at the bank to the main accountants which resulted in a nasty call from the client to the skip manager of my manager. He called me back and asked me to resume what I did almost crying on the phone. Later that year I was selected employee of the year mostly because of that client constantly sending positive feedback on my help.
I would say that "source code is the blueprint of a computer program". If you look at the wikipedia entry:
> A blueprint is a reproduction of a technical drawing or engineering drawing [...] allowed rapid and accurate production of an unlimited number of copies.
and even if no-one reads the definition, the term is in common use. Spies stealing blueprints of weapons in movies / real-life being an immediate example.
Well, I would expect them to address this issue specifically as that is one of the selling points of fastmail. You can get banned on Google for nothing and not being able to reach a person with your data held hostage. Now, this is a comparable situation where data is held hostage unless the customers in Russia have a way to access and retrieve whatever is stored on their accounts.
On top of that there is a question of billing and refunds in the case of long-term plans being paid up front (eg. one year subscription).
The article touches on new signups being blocked, what happens to the current paying users in the region? Are they also blocked? How is fastmail helping them move/supporting them in this situation?
I am a fastmail customer in a different region (Poland). I am however looking closely at this as who knows, maybe I will be on the receiving end in the future?
> The problem the cartels will face is that there is no other business that makes as much money
This is not true. See this article[1] and HN thread[2]:
> “It’s good business,” El Polkas says with a shrug. “It makes a lot of money.” When I ask how gasoline compares to narcotics, in terms of overall revenue to Los Zetas, he rubs his index fingers together. “Fifty-fifty,” he says. “It’s approximately as profitable as drugs.”