The way India handles that is by having a progressive income tax that is collected at the federal level and sales taxes at both the federal and local level (CGST and SGST). Apart from federal funding of states, they also get all the SGST taxes and are free to set their rates for fuel, road taxes etc. Having multiple levels of income tax is always painful.
Also, the government provides free java/excel based tax filing systems with a certain level of sanity checking.
Apart from this there are several fremium sites like cleartax to help file taxes but they don't get to lobby.
(yes, corruption is inherent and tax evasion is rampant, but at least filing taxes aren't as painful as US tax filing seems to be)
I used clusterssh in the past and it is really good at sending commands to multiple machines. However for any real work, I would strongly recommend keeping the typing to a bare minimum and do all your work inside a well tested script. Better yet, use ansible or something like it to manage multiple servers
> I would strongly recommend keeping the typing to a bare minimum
Agreed.
> and do all your work inside a well tested script
At a minimum, with `set -ex` at the top. But I've stopped using (ba|fi||t?c)?sh scripts and switched to standard Makefiles for all my deployments. It requires changing the way you would normally code/script actions or interactions, but you get deterministic results.
I started playing around with self-hosting some things I use a few months ago and I was thinking about using Ansible but it just seemed way too complex.
Wouldn't the difference there be that the person consuming meat is voluntarily consuming it while even people sticking to older tech phones are exposed to the newer radiation? I am no luddite but this would be my argument from a devil's advocate position
No, because you're only exposed to radiation if you actually use a phone. Google for "inverse square law". Your exposure is orders of magnitude lower from "second-hand cellphones" than from using it yourself; it's not like second-hand smoking.
Not if there's a cell tower every 100 yards putting out 30dB more power than your phone. The inverse square law also doesn't apply when you have phased arrays doing beamforming if you're directly in the path.
You get a lower exponent than the square with a beam. For a perfectly parallel beam the exponent is technically 0 (same intensity regardless of distance - like a laser pointer) For a focused beam intensity will actually increase with distance up to the focal point. Some energy can be absorbed by the medium (air/moisture/rain), but that is not covered by the inverse square law.
The cross section of the beam can be any shape, the important thing is the signal source is an area not a point. The value of the inverse square (of distance from source) is dominates power density when the signal source is effectively a point - this becomes the situation for a laser or anything at long enough distance, but at distances where it is effectively a beam, the strength of power density does not dissipate by that value. The geometry of the beam concentrates the power density at its focal point, which can be far behind the source or in front of it. For an ideal beam focused to infinity (parallel rays) its power would never dissipate with distance - as all of the power goes in the same direction.
We don't need to form an ideal beam to say its doesn't follow the inverse square rule, any focusing of rays breaks the rule (at scales where it is reasonable to treat it as a beam and not just rays emanating from a point)
I hope that helps picture the situation. My original comment that a beam can have a different exponent was incorrect except in some approximate sense. The inverse square value will still apply, but from the beams real or imaginary focal point (if it is a point) But it the case of a transmitter beaming a signal at another, that focal length can be far beyond the reciever, so the 'rule' can be completely confounded.
It depends. The inverse square law applies to spherical wavefronts. Due to diffraction, wave fronts always become spherical in the far field.
But in the near field, that's not the case.
Beamforming arrays have planar wavefronts close to the source, so the inverse square law does not apply. The wave fronts will become spherical again at a "large" distance from the emitter, where the meaning of "large" depends on wavelength and emitter size.
Focussed lasers also do not have spherical wave fronts in the near field. The distance at which the inverse square law starts to apply to lasers depends on beam width, coherence, and focus.
There is a substantial difference in my opinion. Laws rarely put forward a mechanism or seek a complete understanding of a relationship, while theories often do.
Ohm's law was a law long before the electron was discovered. It's an emperical linear relationship that just seemed to work. Since no mechanism is suggested, it's not possible to determine whether ohmic behavior is expected or not. In contrast, The Drude Model's explantion of ohmic behavior could be considered a theory. It makes an attempt to understand the underlying physics, and from this it is possible to predict whether a material will follow Ohm's Law or not.
I think modern scientists are a lot less likely to call any empirical relationship a law. Theory is still pretty widely used, and not for things that could be called laws.
You can say the "the theory of quantum chromodynamics," but not "the law of quantum chromodynamics". 'Law' implies a small number of simple equations, while theory allows for a much larger scope of complexity or rigor. The meaning is absolutely different. Modern science is pretty complex compared to what went on 200 years ago, so it's not surprising law has fallen out of favor.
no. smoke is heavily influenced by ventilation and the enclosure. there's a fair amount of modelling in the literature, for example on how much air flow you would need in confined spaces to reduce secondhand smoke cancer risks to acceptable levels.
It's not really uncommon to see "no smoking on the patio" or "no smoking within 100 feet of this door" signs. And some states have legalized smoking cannabis, except outdoors.
I've seen such limits imposed on private property, but as far as I know there aren't any laws (specifically for cigarette smoke) that extreme.
Don't get me wrong, I'm not a smoker and never have been. I like these laws. I'm just being a bit pedantic. There has been a general trend of restricting smoking and I think that trend has continued outdoors. It used to be that you could smoke anywhere, then businesses started creating indoor smoking sections. Then indoor smoking sections were banned and smokers moved to the outdoor seating. Then smoking outside near exterior doors was banned, in a way that effectively banned smoking at many restaurants entirely. Beyond this, in some places like NYC you have smoking bans in public parks and beaches as well, regardless of how far you are from any exterior door. (To be clear, I support these bans because cigarette smokers are notorious for their litter.)
And in the case of cannabis the restrictions are even more severe. In Washington you cannot smoke cannabis in view of the general public or in most buildings (except residential, although many apartment buildings have smoking bans too.) California is more permissive, but even they enforce a 1000(!) foot smoking ban around schools and youth centers.
There is definitely room for a scheme compiler. But the scheme ecosystem felt extremely fractured the last time I took a look. Chicken had a decent but aging repo. Chez had a great compiler (I prefer not compiling to C) but it's package ecosystem was not something well advertised if it did have one. Racket has too many dialects which might appeal to some but found the number of sub languages overwhelming for a casual schemer.
Making languages is the thing that Racket does better than any other language, so they do tend proliferate. However, for getting stuff done the majority of work is done in just Racket. You don't need to know the other languages unless you're interested in some specialist task they target.
Back when I was a regular Scheme user Racket had by far the biggest ecosystem and community, so it would be my suggestion if you're interested in exploring Scheme.
Yes. I've written a test framework for another software I'm developing that (optionally) sets up an environment for the executable under test, (optionally) launches and monitors the executable (process state, stderr/stdout), connects to the process via a WebSocket (that's what that executable does) and then tests the surface of the exposed WS-API. As the executable runs under windows & linux, embedded and not, this approach lets me run the test suite under all different hosts and connect to localhost or the thing running elsewhere. So, in my case, you may not see it in a product; but the product we're building is continuously tested with a myriad of racket programs.
I did and even though I'm forever in love with both Rebol and Red, Racket does languages in a more fun way and powerful way for my own personal taste. Don't know if you have checked this book out but https://beautifulracket.com/ is a wonderful introduction for building languages with Racket.
For me, the power of the Redbol approach lies in the rich set of datatypes, so you can create dialects at the block/value level, leveraging the syntax without having to tokenize at the string level. It's no small thing to be able to create languages that natively understand values like email addresses, URLs, IP addresses, files as distinct from strings, and more.
From brief check on the book I see that Racket has a lot of infrastructure for making languages, but fundamentally I don't see the difference with Parse in Red. One can easily add tokenizer, reader and expander similar to what is there in Racket.
For those that haven't used Rebol or Red. It is a homoiconic language like lisp, but no s-expressions as I understand it.
Rebol is really nice with a lot of built-in primitives that make it super useful although Rebol is kind of dead now (some users exist, but no new versions in a while). Red is being worked on and if it ever reaches 1.0 could be a game changer.
I think it is pretty easy to build little DSLs, but I don't think macros are super easy unless I'm mistaken. If somebody could shed some light for me I'd appreciate it.
You don't need macros in Red (but it's easy to roll out your own macro layer, if one so desires [1]), all code transformations can be achieved at runtime. A brief explanation of how this works is given in [2].
As for Red / Rebol vs. Racket content - I wrote an excessive post on that some time ago [3], in response to similar question.
TL;DR from language creation perspective is that Racket has state-of-the-art macro system and all the necessary infrastructure, and Red has metaDSL (that is, DSL for creating DSLs) called Parse [4], which is basically PEG on steroids (think OMeta) + a different take on homoiconicity, compared to Lisps, which, most of the time, renders custom readers and tokenizers unnecessary.
I tried it and would consider it a write-once language, similar to Forth in that respect. It seems good for quick hacks but not for long-term maintainable projects.
I'd like more info on that as well (as part of Team Red). And, for comparison, what language(s) you feel are best for that, and what features lead to that.
where both `cat` and `grep` can be either shell commands or Red functions and you can redirect input/output from/to variables as well as files. Also you can mixin Red data types, like in example here `%/etc/passwd` is a file instance, not a string.
Also the language itself heavily utilizes this (called Parse dialog) for example they don't have regular expressions at all, JSON is parsed using it as well, GUI system is a fully separate dialog and so on.
Racket 7.4 now comes running on chez if you so wish. Check out [1]. In there there's also the links to the whys, hows and whats of the whole effort.
I've been using racket quite a lot lately, really like it. The thing I do not like about racket is the whole "racket 2" effort. Abandon S-exps? Really? To leave behind the 'popularity boundaries' of lisps? d'oh How about you drop your common USP that you share with the other lisps to become .. what, exactly.. irrelevant?
Cf. your 'dialect' point: In reality, the languages are just (supposed to be) DSLs for specific (sub-)problems of your problem-space. I don't mind, at all. You just require the libraries written in that other dialect from racket and use the stuff in there, et voila.
I always thought that was the best feature of scheme. Nobody agrees on anything, except mainly R5RS, keeping it from going down the path of "one implementation for everything, always" that most languages suffer from once they become a little popular. Scheme is one of the very few languages that has resisted accruing a lot of bloat throughout its existence (R6RS never was very popular because of that)
People underestimate the upside of being able to paste any example snippet into your repl and have it work transparently in almost every scheme, without having to worry about libraries or eco-systems.
For anything more exotic, you grab the nearest SRFI and squeeze it around until it works in the scheme you're working with.
Scheme: it's so simple, any subgenius could use it!
I am just getting into Scheme, and have heard good things about Chez. Any pointers to what is standard out in the wild? What are the de-facto Scheme tools are people using these days?
The story of Scheme is that it was so easy to implement (relatively) that they ended up with dozens of implementations, so they decided to write a standard... and then started doing the same thing with the standard(s).
It's a language family, or even philosophy, rather than a single language.
R6RS was the one that really sparked the divide, and for a long time only had a limited number of implementations due to this controversy. The big thing that R6RS brought, in my opinion, was a syntax for creating modules and sharing them. R7RS was an attempt to create an R5RS-like minimal standard that still had a library/module syntax so that you could get a bunch of implementations and share code between them. R7RS-small did this, and then R7RS-large attempts to use the module syntax to create a big body of "industrial strength" code that you can use to get "real things" done with scheme. The R7RS-large process seems to be using the SRFIs as a staging ground for the new modules, standardizing on chunks of them as they go in different "editions".
So the theory now is that you can write a smaller R7RS-small compliant scheme, and do all your language experimentation in that, and someone else could come along and bootstrap that into a fairly useful large implementation without a ton of effort, and modules you write on that scheme could then be reused on other implementations.
1. R7RS explicitly decided to repudiate R6RS, leading to the disagreement.
2. R6RS made changes that did not have consensus and the resulting vote didn't have a big enough super majority requirement, leading to a controversial standard.
3. There was always major disagreement about all the relevant points, and R5RS itself was only created by not introducing anything new post 1992, and by not taking a position on the controversial topics. So any standard effort was bound to be controversial.
I've grown to dislike activate, because it breaks the simple rule of "never run pip, python, etc., only run your-venv/bin/pip, python, etc.". Now the rule is "Don't run pip, python, etc., unless you've previously run activate and not deactivate" - and it has the complicated special case of "make sure the command exists in your virtualenv." (For instance, it's definitely possible to have a Python 2 virtualenv where pip exists but not pip3, and now if you run pip3 install from "inside" your virtualenv it's global pip! Or you might have a Python 3.6 virtualenv and type python3.7 and wonder where your packages went, or several other scenarios.)
If you have the shell prompt integration to remind you whether you're in a virtualenv or not, it's fine, but I don't always have it, and I find it helpful to manually type out the full directory name (generally with the help of up-arrow or tab...) so I know exactly what I'm running.
for bash/fish it automatically prefix with a (your-venv-name) so it's obvious you're under some venv, not sure about csh but I would assume it will do something similar. looks like venv supports bash/csh/fish only by default however.
Long answer since I have been thinking about this since my school days.
Somewhere in the mid 90s, there was a boom in the IT sector in India - jobs in IT paid 2-3x more than other jobs. Most people who could buy new houses and cars worked in IT. This lead to a push from most parents to put their children into an engineering undergraduate program. Companies like TCS hire people from all branches of Engineering for IT jobs. They retrain the new hires given that the coursework is terrible in most universities anyway and don't care whether you specialized in mechanical engineering or computer engineering.
Of the 300 that finished high school with me, 50 went into commerce and management related programs, 200 went into engineering. Only 1 high-performer (who incidentally was a girl and thus could, by societal norms, "risk not getting a job since she would get married anyway") took an alternate path - pursuing a top-notch program in social sciences.
For a long time, the only way of getting an assured cushy job was to pick some branch of engineering and getting hired by TCS, CTS or Infosys in campus hiring drives.
This and the booming middle income class who could afford college education but needed a job guarantee at the end of it caused a precipitous drop in the quality of people pursuing pure-science and math programs in the country (very few are still considered prestigious) and an explosion in the number of engineering colleges. When I finished my undergrad in 2010, my university alone had 400+ affiliated engineering colleges, churning out > 10000 graduates every year. Most of my batchmates (B.Tech in IT) couldn't code despite going through a 4 year program.
This also meant that vocational programs like carpentry and plumbing were criminally underpaid to the point where it is now hard to find skilled carpenters and plumbers below the age of 40. Agriculture became a thing for only the poorest. A previous push towards vocational training was shot down as casteist [1] and politicians will dare not even mention it anymore because of that.
Things are making a comeback though, Taxi cab drivers are earning salaries comparable to what junior developers do for the first time in decades thanks to Ola and Uber. Vocational programs are going to become necessary within the next 10-15 years. In the years to come, I predict farming making a huge comeback (though corruption and government price-fixing still makes it unpalatable to most who currently are in the middle class)
The reason Taxi cab drivers are earning good salaries is a combination of demand from the IT sector employment and VC money throwing. If by any chance Ola or Uber loses funding or leave the market their salaries will reflect the market value in the economy.
In the 2008 bust a lot of Taxi drivers lost their cabs and there was a massive inventory of it. Luckily Ola and Uber came along and the demand picked up. This time they might not be lucky.
This is what happens when you are in a service based economy. If India does not create industries here or encourage small and medium scale businesses to flourish then they are going to see a lot of problems. Encouraging monopoly is the last thing they should be doing and should break up some of the massive companies to encourage smaller players to rise. This is just one of the things but there are so many basic things that the Government has to improve and they are really late in the game.
Higher education will only get costlier and more and more people will fall in the debt cycle. Hopefully people become financially prudent and find better ways of making money rather than depend on big corporations to provide employment.
