Yes; but that is only "Purusha" aka "Witness-Consciousness" as wikipedia so nicely labels it. But it is in the elaboration of "Thoughts/Emotions/Feelings/Perceptions/Everything Mental/Psychological" + "All Physical Matter" which is labeled under "Prakriti" aka "The Original Primary Substance" where the beauty and logic of this philosophy shines.
All "mental stuff" is mediated by three aspects i.e. 1) Intellect (aka Buddhi), 2) Ego/Self-Identity (aka Ahamkara) and 3) Sensory Mind (aka Manas). It is in the teasing out of all mental stuff into these aspects as being completely independent of "Consciousness" (aka Purusha) that is to be understood and practiced. In "normal life" Consciousness is bound to the above three aspects of "mind" and hence "suffers bondage". Patanjali Raja Yoga follows on Samkhya by giving a eight-part framework/discipline (aka Ashtanga Yoga) to literally "stop all mental/thought stuff creation/expansion". Then Consciousness is no longer bound to externalities (including its own "mind") but becomes settled within itself which is called Liberation (aka Moksha).
The Samkhya is Atheistic and Dualistic Realism and quite compatible with Modern Science where the former gives a "inside out" experiential and subjective model while the latter details a "outside in" material model.
This is not true. There are both theistic and atheistic branches in the Sāṁkhya school. It is a myth that Sāṁkhya is atheistic. In fact, Patanjali himself is in the theistic school of Sāṁkhya as he talks about: "īśvara praṇidhāna" in the sūtras and even defines īśvara.
The Original "Classical Samkhya" is Atheistic and Dualistic Realism. It is only in later modifications/extensions that the concept of "God" was added in, which is strictly speaking not necessary. Wikipedia gives the debate - https://en.wikipedia.org/wiki/Samkhya#Views_on_God See the texts Samkhya Karika/Panchasikha Sutram/Kapila Sutras in the magnum opus by Nandalal Sinha titled The Samkhya Philosophy (contains a translation of all extant Samkhya texts in over 700 pages!). Also see the books of Gerald Larson (one of the foremost western scholars on Samkhya) to get an idea of the evolution of the entire Samkhya School.
In Patanjali Yoga Sutras the concept of "God" is merely used as an entity and technique to help you in your practice to break out of your self-identity (i.e. Ahamkara). It is just one among a set of techniques. There is only half a dozen sutras which even mention god in the entire text (see this succinct translation by Bon Giovanni - https://sacred-texts.com/hin/yogasutr.htm). It is in the later commentaries on the text that you find an elaboration according to the pre-existing beliefs of the author.
> It is only in later modifications/extensions that the concept of "God" was added in, which is strictly speaking not necessary.
You can turn it the other way round and the claim would be even more valid: Atheism came later in the Sāṁkhya schools. The scholars have a bias towards atheism so it's not surprising they'd claim that.
This is proven by the fact that the Mahabhārata's Bhīṣma-parva has a whole chapter on Mokśa-dharma which give us the very first signs of a proto-sāṁkhya philosophy and it is very much theistic. Also, the later added atheistic Kapila philosophy is a deviation from the original Kapila, the avatar of Lord Viṣṇu.
Even Patanjali is mentioned as Śeṣa in the scriptures and every school agrees with it. Śvetāśvataropaniṣad is one of the earliest references to Sāṁkhya and is very much theistic. Sāṁkhya being atheistic is a fiction. There were atheistic Sāṁkhya branches but it was never 'only' atheistic.
> "God" is merely used as an entity
That is true, because Patanjali's project was "svarūpe avasthānam", the method by which the seer can abide in its own nature. Īśvara is merely used as a prop to gain something else, which is okay because that is what Yoga Sūtra is about but it does not mean Sāṁkhya was originally atheistic or that theistic Sāṁkhya is a later addition.
> You can turn it the other way round and the claim would be even more valid: Atheism came later in the Sāṁkhya schools.
No, current scholarship is unanimous in accepting that the Atheistic view came first. Unless some new unknown texts come to light to make us revise the dates that is what we have to live with.
Outside of the classic sutra texts mentioned above, there is only the "Kapilopadesha" from the Bhagavatha Purana and "Kapila-Gita" from the Mahabharatha which seem to espouse proper Samkhya philosophy. All other mentions in the upanishads/vedas/puranas/itihasas seem to be just a mention without any substantial details.
Most of Sāṁkhya is theistic and came first. All purāṇas are sāṁkhya and theistic. Mahābhārata is theistic. Even Īśvara Krṣṇa never rejects īśvara in the kārikas. Only Gaudapada rejects it explicitly in his commentary. The sūtras, which came much later also don't reject īśvara, they just say it's not necessary (anivārya) to discuss, just like Darwinian Evolution, it's not necessary to presuppose there's a God but theists will still say that God sets it up in the first place.
To say something is not necessary doesn't entail that it's doesn't exist or that it's philosophically untenable.
Śankara does debate with atheistic Sāṁkhya so I'm not saying that it's not the case but it's a mistake to claim that Sāṁkhya is non-theistic because that's what some authors write when it's not the case. The majority of Sāṁkhya traditions were īśvara-vāda, theistic.
Who cares what prescientific people thought first or second? The order in which they thought these prescientific thoughts has no bearing on the correctness of those thoughts.
I had just setup "Stirling PDF" on my home NAS a few of weeks ago, since my SO needed to merge some documents and I'd recently read that (or a similar) HN thread.
I definitely would recommend it. It was really quick to setup; though my already having a reverse proxy with wild card TLS certs setup probably helped streamline the networking side of things.
Just a warning to anyone reading this that 35% lab grade hydrogen peroxide can be VERY dangerous, so I'd just stick to the 2% drug store stuff unless you really know what you're doing.
High purity hydrogen peroxide has been used as a rocket fuel since it's such a great oxidizer.
+1 ours got so moldy inside. Especially after the hardwood installers ran them while sanding. I've gotten quite good at deep cleaning and sterilizing them, but it's a long and messy process.
I was in a similar boat and finally got around to trying out Proxmox in the last year or so. I just wanted share my own experience here, since it's a bit different than the "standard" uses I've seen.
I had been running a k3s cluster (k8s flavor) on some Raspberry Pis, but decided I needed some non-ARM nodes, and "invested" in a few low power "1L" AMD64 PCs (6-8 core + hyper-threading). I was initially going to just install Ubuntu and base my setup off my existing Ansible automation to make things less inefficient. But I figured I'd play around with Proxmox first and see if there was any benefit to using that as a base layer since I'd heard a lot about it.
I'm so glad I did. I ended up learning quite a bit in the process. Some quick highlights about using Proxmox for VMs in general:
* Proxmox supports creating a "cluster", so you can login though one machine to administer them all. You can conveniently "move" VMs between machines pretty seamlessly.
* If you install the para-virtualization drivers for e.g. Windows or Ubuntu VMs, you can do pretty fast remote KVM. E.g. I could run Youtube on a Windows VM in my basement over "Spice" and it almost looks like it's running locally. (Not that it's a use case I care about, mostly just shows the fact it's performant.)
In terms of actually getting around to deploying k3s on top of the infra:
* I ended up learning HPC-Packer, and HPC-Terraform, which integrated nicely with my existing Ansible experience.
* Packer turns an Ubuntu ISO + my "base" Ansible setup playbooks into a pre-baked machine template directly in Proxmox. (My local machine's Packer binary just orchestrates the process.)
* Terraform deploys the machine template into the Proxmox cluster. Basically a config file of machine names + IPs + mac adresses, and a few other params and initial setup.
* Ansible then installs any final dependencies (anything not in the base template), setups up the first k3s master, grabs the join token, and adds in 2 more master nodes for a proper `etcd` backend.
* Ansible then installs my base Kubernetes services (cert-manager, Rancher, Longhron storage, etc) via running helm commands on one of the nodes.
* This is where I'm at now; the next step is for me to deploy my existing Flux.cd-automated "Gitops" apps (built for ARM64+AMD64 via Gitlab runner, also in Proxmox). These _had_ been running on my now-quite-crusty-seeming Pi cluster.
I can run a single command to delete all the VMs, and rebuild + setup everything (full HA cluster + apps deployed and running) from scratch in ~6 minutes without any manual input required from me, just a few secrets/params in a config file.
This has made exploring the horizon of possibilities _so much easier_ without getting locked in; I can try to weird Longhorn storage configs, or try out k8s monitoring stacks without worrying about needing to "back out" my changes if I picked bad settings. (Just blow it up and try again!) I can change how VLANs are configured in early steps, or try adding a library to the base Ubuntu install cluster-wide super easily, etc.
I am primarily a software-engineer, so it has been really nice to delve into the operational side of things, and get a proper reproducible setup. It really has transformed how I think about the cluster in that it's no longer a "thing to carefully maintain", but instead a great sandbox to explore AND deploy my own k8s applications on top of without playing cloud bills.
My Proxmox journey in the past few months definitely turned into more than a rabbit hole than I'd expected.
Could I please ask you to share some of your Terraform files? I'm looking to build a similar setup on my Proxmox cluster, and it would really help to have a template to go from!
Salts are generally stored with the hash, and are only really intended to prevent "rainbow table" attacks. (I.e. use of precomputed hash tables.) Though a predictable and matching salt per entry does mean you can attack all the hashes for a timestamp per hash attempt.
That being said, the previous responder's point still stands that you can brute force the salted IPs at about a second per IP with the colocated salt. Using multiple hash iterations (e.g. 1000x; i.e. "stretching") is how you'd meaningfully increase computational complexity, but still not in a way that makes use of the general "can't be practically reversed" hash guarantees.
As I said the key for hashing PII for telemetry is that the client does the hashing on the client side and the client never transmits the salt. This isn't a login system or similar. There is no "validation" of the hash. All the hash is is a unique marker for a user that doesn't contain any PII.
Kidding, of course. I don't think there's a way to track users across sessions, without storing something and requiring a 'cookie notification'. Which is kind of the point of all these laws.
Storing a salt with 24h expiry would be the same thing as the solution in the article. It would be better from a privacy perspective because the IP would then not be transmitted in a reversible way.
If I hadn't asked for permission to send hash(ip + date) then I'd sure not ask permission if I instead stored a random salt for each new 24h and sent the hash(ip + todays_salt).
This is effectively a cookie and it's not strictly necessary if it's stats only. So I think on the server side I'd just invent some reason why it's necessary for the product itself too, and make the telemetry just an added bonus.
If you can use JS it's easy. For example localStorage.setItem("salt", Math.random()).
Without JS it's hard I think. I don't know why this author wants to use JS, perhaps out of respect for his visitors, but then I think it's worse to send PII over the wire (And an IP hashed in the way he describes is PII).
EU's consent requirements don't distinguish between cookies and localStorage, as far as I understand. And a salt that is only used for analytics would not count as “strictly necessary” data, so I think you'd have to put up a consent popup. Which is precisely the kind of thing a solution of that is trying to avoid.
Indeed, but as I wrote in another reply: it doesn't matter. It's even worse to send PII over the wire. Using the date as the salt (as he does) just means it's reversible PII - a.k.a. PII!.
Presumable these are stored on the server side to identify returning visitors - so instead of storing a random number for 24 hours on the client, you now have PII stored on the server. So basically there is no way to do this that doesn't require consent.
The only way to do it is to make the information required for some necessary function, and then let the analytics piggyback on it
I think I agree with you there. But again, the idea of a "salt" is then overcomplicating things. It's exactly the same to have the client generate a GUUID and just send that up, no salting or hashing required.
Yup for only identifying a system that’s easier. If this is all the telemetry is ever planned to do then that’s all you need. The benefit of having a local hash function is when you want to transmit multiple ids for data. E.g in a word processor you might transmit hash(salt+username) on start and hash(salt+filename) when opening a document and so on. That way you can send identifiers for things that are sensitive or private like file names in a standardized way and you don’t need to keep track of N generated guids for N use cases.
On the telemetry server you get e.g
Function “print” used by user 123 document 345. Using that you can do things like answering how many times an average document is printed or how many times per year an average user uses the print function.
What you're describing is called "pepper". What's called "salt" is not varied between rows and therefore not stored with the hash (and best stored far away from the hash).
It's common to conflate the effects of a solar storm with an EMP; when in reality they're opposite extremes of the same mechanism (i.e. voltage varying over distance).
An EMP is a short-duration high voltage spike; i.e. short-wavelength/high-frequency.
A solar storm acts on a large scale and causes a long-duration high voltage spike; i.e. long wavelength/low-frequency.
So an EMP (i.e. a high altitude nuke) will tend to induce high voltage in small "antennas"; i.e. circuits in an SSD or other transistor electronics like your concern.
Whereas a solar storm will induce high voltage in large antennas; think power lines or long cables. However these days there's enough warning and contingencies to mitigate the worst of these effects; i.e. preemptively shut down vulnerable power systems. The grid "crashing" and needing to do a cold start is still very bad, but far better than also getting damaged.
----
Edit: I also want to point out that the above is specific to "on the ground" effects as we're shielded by earth's magnetic field. Satellites still get bombarded directly with heavy radiation/particles, which is much closer to an EMP in terms of acute impact.
My understanding is that solar storms and high-altitude EMPs have similar effects. Both energize the upper atmosphere which induces currents in long conductors. High-altitude EMP does not harm electronics.
It is close-by EMP from nuclear blast that harms electronics.
Hopefully one day we'll have a grid designed to carry high voltages over long distances instead of using inefficient low voltage transmission which exposes the grid to these dangers.
Is this supposed to be sarcastic? The grid does carry high voltages over long distances. The standard voltage in North America is 765kV, and for HVDC lines it can be 2MV. But that's for long-distance transmission lines, not more local distribution lines, which are necessarily lower voltage (36kV I think) for practical and safety reasons.
This has bugged me for so long and I hope the industry finally stops someday.
To summarize for anyone not versed in electrical power:
* mAh measures how much current your battery holds, irrespective of voltage.
* However, actual POWER is measured in Watts (or watt-hours cumulatively).
* Watts = current * voltage.
* A 2000mAh hour battery at 2 volts has half the power of a 2000mAh battery at 4 volts.
* As voltages can vary based on battery arrangement (parallel vs series cells), this makes a huge difference. You can half or double your mAh by arranging your cells differently, without changing actual power stored.
Using Wh or mWh instead of mAh would make this whole problem go away. But then that means low voltage batteries (like often used in phones) can't inflate their reported mAh compared to high voltage cells (e.g. in power tools). They also tend to conveniently leave out the battery voltage, so you can't tell when it's an apples to apples capacity comparison.
It's also redundant because with 2000mAh... "thousand milli" can just be eliminated, leaving us with 2Ah.
Everyone constantly referencing thousands of thousandths is another one of my "favorite" things about the industry using mAh as a standard measurement of battery "capacity" (besides the fact that they almost never specify voltage or watt-hours).
Don't quote capacity. It is the correct tern, physically. Capacity is the amount of electrical charge something can store, Ah is unit of that. Not the natural unit though, that would be Coulomb (C).
Why use Charge and not energy? Because the voltage changes as the battery is discharging, so it's not as straight forward as just multiplying with the voltage.
Agreed, but not from a consumer perspective, where it is very confusing that a battery with half the capacity might have twice the energy due to differences in voltage.
From a consumer perspective, the battery capacity is the amount of energy, regardless of whether that is wrong.
I don't think "capacity" neccesarily has a concrete unit connected to it. I am pretty sure you could call both the charge and the energy in a battery its capacity.
> It's also redundant because with 2000mAh... "thousand milli" can just be eliminated, leaving us with 2Ah.
But then you'd have to do more conversions when comparing. I've seen batteries with capacities as low as 10mAh. 4 digits is still a reasonably practical number.
In the consumer space, virtually no battery I've seen in more than a decade is less than 1000mAh. If you looked at the Reddit post, you know we're talking about laptops, tablets, phones, external power banks, that type of consumer-facing application. But, even then, converting is fine. People understand there are 1000 meters in a kilometer. I don't think any of this is rocket science.
However, outside of the consumer space... doing conversions like that is also fine. When browsing DigiKey, components are often listed in the optimal unit prefix. When necessary (not so much with batteries), the interface allows you to filter based on ranges you provide, and it will perform the necessary conversions for all the products to give you an accurate list.
> People understand there are 1000 meters in a kilometer. I don't think any of this is rocket science.
Yes, but it's one more mental operation, and every mental operation like that is relatively costly. People don't actually have that many slots of working memory. You are optimizing to minimize digits, which is probably the wrong thing.
> Behold <a single counterexample that is far less commonly encountered by consumers than phones, tablets, laptops, or external power banks>
EDIT: Ok, now you have updated your comment to also include coin cells, which is even less relevant. This just shows you don't appreciate what we're talking about here.
Consumers care about the amp-hour capacity of larger devices for various reasons. They need to figure out how many times they can recharge a phone from an external power bank. They want to understand how much less efficient their laptop is than their tablet. That's not what they do with coin cells or AAA batteries.
You have also ignored that we can express 0.8Ah. It doesn't have to be 800mAh vs 2Ah. Since things less than 1Ah are far less common for consumers, it would be logical to just show everything in Ah, and then represent those smaller things as fractional Ah, if we're afraid of multiplying and dividing by 1000.
We could represent all distances in millimeters just in case, but we don't.
> Behold <a single counterexample that is far less commonly encountered by consumers than phones, tablets, laptops, or external power banks>
People still use AAA batteries, and that probably the most well-known, premium brand of rechargeable AAAs.
> Consumers care about the amp-hour capacity of larger devices for various reasons. They need to figure out how many times they can recharge a phone from an external power bank. They want to understand how much less efficient their laptop is than their tablet.
But they do care about the metric prefix? mAh far more established and slightly more convenient to use than Ah for these kinds of batteries.
Edit:
> You have also ignored that we can express 0.8Ah. It doesn't have to be 800mAh vs 2Ah. Since things less than 1Ah are far less common for consumers, it would be logical to just show everything in Ah, and then represent those smaller things as fractional Ah, if we're afraid of multiplying and dividing by 1000.
I haven't ignored that, it's just not a very appealing thing to do and doesn't answer any of the problems with switching the customary prefix.
Yes. It would be possible to relabel all consumer batteries with Ah instead of mAh, but why would anyone want to go through all that trouble?
Consumers do not know the amp-hour capacity of coin cells or AAA batteries. They don't know and they don't care. Consumers put a coin cell into an AirTag and come back a year later to replace it when their iPhone tells them to. They don't care about the capacity. It's not relevant to this discussion at all. The percentage of consumers who care about the capacity of those types of batteries is certainly tiny.
> But they do care about the metric prefix? mAh far more established and slightly more convenient to use than Ah for these kinds of batteries.
It is not more convenient, since consumers do not think about <1Ah values, virtually ever.
> Yes. It would be possible to relabel all consumer batteries with Ah instead of mAh, but why would anyone want to go through all that trouble?
And I repeat: We could represent all distances in millimeters just in case, but we don't.
LA is only 4,506,163,000 millimeters from NYC. Very convenient.
> Consumers do not know the amp-hour capacity of coin cells or AAA batteries. They don't know and they don't care. Consumers put a coin cell into an AirTag and come back a year later to replace it when their iPhone tells them to.
Then why label batteries with a capacity at all, if consumers don't care so much?
They care when they're buying batteries and they have a choice of different ones to buy.
> It is not more convenient, since consumers do not think about <1Ah values, virtually ever.
Even if that were true, it doesn't justify changing the customary unit.
> And I repeat: We could represent all distances in millimeters just in case, but we don't.
> LA is only 4506163000 millimeters from NYC. Very convenient.
And people could report their height in meters, yet they frequently use centimeters.
Among other things, we don't use millimeters for long distances because 10-digit numbers tend to be an awkward number of digits to work with, but 4 or 5 digits are still pretty easy and natural to work with. I wonder how many digits the LA to NYC distance is in kilometers? Well, wouldn't you know it, it's 4.
Anyway, this conversation isn't going anywhere. Batteries will continue to be labeled in mAh, even if you have a strong personal opinion that everyone else is using the wrong prefix thousands of companies and millions of people just need to switch to Ah now.
We label batteries with capacity in cases where said capacity is tiny compared to user's needs. It allows user to guesstimate if their phone will last 1 or 2 days on a single charge.
For AAA batteries, which in typical use last at least several months the exact capacity number becomes largely irrelevant.
For future rants: mAh is a measure of charge, not current. And batteries don’t have “power stored” — they have “energy stored”.
When you make a statement like “A 2000mAh hour battery at 2 volts has half the power of a 2000mAh battery at 4 volts,” it’s a bit nonsensical — a battery does have a certain amount of power available, but that amount is not charge * voltage, nor is it even necessarily proportional to the energy stored.
Historically batteries have had known standard voltages (12V, 6V) and within that context, mAh is easily convertable to Wh.
With USB PD and powerbanks etc that operate at many voltages using mAh is unclear. It's only used historically as a number comparable to previously used numbers. As someone mentioned the implied voltage is that of the cell 3.7V
So the conversion formula is Wh = mAh/1000 * 3.7V (or substitute the standard voltage for the context)
The main problem with your argument, is that for many use cases, the real voltage from a battery is not identical to the nominal voltage. As the current through the battery increases, energy loss due to the internal resistance of the battery will cause the external voltage to go down.
This means that actual Wh will depend on how many amperes the battery has to deliver. When the load is very low, this hardly matters, but when you need to power a high wattage engine/appliance with a small battery, this can be quite significant.
> Using Wh or mWh instead of mAh would make this whole problem go away.
Amp-hours (Ah) has been the 'standard' way to list battery capacity for decades, see for example the boating/marine world. I'm not against changing it to something else, but there's a long-tail of legacy here.
Also, while we're at it, can we change away from listing the brightness of light bulbs in watts: this may made sense with incandescent bulbs initially, but we're not beyond those.
So who's going to explain to 99.999% of the world why a 10w/h battery that is 5v is incompatible with their 12v device that also takes a 10w/h battery?
After having 2 bikes stolen back in college, my last (brand new) one was haphazardly spray painted rusty-brown and had cotton stuffing taped to the underside of the seat.
That one never got stolen, despite having it for much longer.
Assuming I understand you question: you can define an interface to describe what an object parsed from JSON contains, and then cast your raw JSON-parsed object into that type.
The casting doesn't guarantee the JSON from your server fits the interface, but it WILL ensure any downstream use is correct, and also enable auto complete for its fields (assuming your IDE supports it).
I've been using JavaScript on and off for nearly 20 years, and TypeScript is a massive improvement.
"You" are not "your thoughts": you are the watcher of your thoughts.