It is crazy because in India political parties can indirectly accept foreign funding through a recent change in constitution by ruling party.
Foreign funding of political parties is equally if not more dangerous than foreign funding of news media.
411 karma · joined May 12, 2019
Foreign funding of political parties is equally if not more dangerous than foreign funding of news media.
To provide some contrast, the same govt amended a law originally designed to prohibit foreign funding of political parties and changed it to allow funding from local companies which have more than 50% foreign ownership.
So basically political parties can indirectly accept foreign funds through above loophole which the ruling party itself created but news organizations cannot.
“ the controlling Bharatiya Janata Party government passed a retroactive amendment through a 2016 Finance Bill that excludes from the definition of “foreign sourced” contributions from local companies even though a foreign company owns more than half their shares, provided certain direct investment requirements are met”
Source: https://www.loc.gov/law/help/elections/foreign-involvement/i...
So it’s curious to see the selective retaliation. At what point a company is Chinese?
PayTM raked in immense profit following demonetization in India(overnight invalidation of several currency notes). And it continues to handle large amounts of financial transactions on daily basis.
I initially evaluated InfluxDB and was impressed by it, but I was introduced to Prometheus I did not find any reason to go back to InfluxDB.
1. Prometheus has pull based of consuming metrics vs push based mechanism of InfluxDB. I see it as a plus point in terms of scalability especially if you have high traffic application.
2. If you are interested in zooming into a single event e.g. "error thrown at 11:01am" then Prometheus isn't for you. In that case you should evaluate timeseries databases like InfluxDB, TimescaleDB and others. Prometheus will only give you aggregated stats i.e. "errors thrown between 11.00am and 11.05am". You can label the events in Prometheus and group by those labels to draw some insights & define alerts.
3. The PromQL query language used to query metrics in Prometheus seemed much more powerful than InfluxDB to me. I find it much more advanced and flexible compared to any other solutions. e.g. you can compare current metrics value e.g. errors thrown per 15 seconds to the same value exactly a week ago which I find very cool. However PromQL has some learning curve. Luckily people have published common PromQL queries, so it's not that bad.
4. InfluxDB is a commercial product, which means some advanced options like distributed setup are available in paid version. This isn't a negative point, but just putting it out there. In contrast, Prometheus is open source.
5. I liked the deduplication and grouping feature in AlertManager(prometheus).
6. InfluxDB needs some serious hardware. This is understandable, because it stores each and every event. I was testing on a low spec machine, so InfluxDB used to crash after running for few hours and it consumed insane amounts of RAM(15-16 GB at times). I used the same hardware for Prometheus, published the same metrics under same load and I did not see any query performance issues. The RAM & CPU usage was very low(1 GB at max) in comparison This is mostly because Prometheus stores the aggregated values i.e. number of errors in 15 second windows as opposed to all the errors(which could be hundreads or thousands). So number of events do not affect performance in Promethues, only number of metrics do.
7. In comparison of setting up InfluxDB and other supporting components, I find Prometheus pretty straightforward to maintain.
8. The federation feature in Prometheus was very important for us. Basically you can pull data from one Prometheus instance into other Prometheus instance at lower resolution. This way I could monitor a fleet a 1000 nodes without any complicated setup or high spec nodes. e.g. you can configure a prometheus instance to pull metrics from 10 nodes at 15 second resolution. Then another prometheus instance would pull metrics from 10 such leaf level promertheus nodes at 1 minute interval. But since you are pulling lower resolution data, you can use the same hardware spec for leaf level prometheus instance and it's parent instance. When you are looking into Grafana, you can first look at higher level prometheus instance data then zoom into a subset as necessary. This is something I find easy to configure and manage.
This is what I can gather from top of my head, there could of course be other pros and cons in both solutions.
Official comparison by Prometheus team - https://prometheus.io/docs/introduction/comparison/#promethe...
1. According to article some government organizations deducted percentage of salary towards this fund by default. After some protests this default was reversed.
2. This fund is exempt from audit because it’s not a “public fund”. Can someone throw some light on what this actually means? I’m referencing “Accountability and transparency” part of the article.
3. Part of this fund was used to buy ventilators manufactured by a local(Indian) company. Some hospitals returned these ventilators because of quality issues. Source - https://m.huffingtonpost.in/entry/agva-ventilators-pmcares-c...
You have a source for this, especially regarding deep packet analysis? Just curious.