> My point is that if you care deeply about what is being installed in the image, size, dependencies, bloat, etc. then perhaps using the NixOS abstraction is the wrong approach. Instead of building "down" by taking things away, build "up"
Those aren't necessarily oppposing points.
NixOS is a declarative distro. It also happens to come with some defaults that, I assume, caters to the commonly expected use case (and maybe has some historical roots as well).
NixOS is not a minimal, build-from-scratch distro. It's more opinionated than e.g. Arch. For example, it ships with firewall turned on by default (https://nixos.wiki/wiki/Firewall). Another example: the default list of packages is somehow Perl, rsync, and strace (https://search.nixos.org/options?channel=26.05&query=default...). Blanking this default to an empty list is IME harmless.
The declarative nature is probably the subtext the author is trying to convey: what are the things one can do to disable these defaults, to reach a very minimal system (ISO really) that one can then build as one wishes.
My own view: rolling release distros gets less in my way than distros like Debian. They allow me to install anything I want, as close as possible to upstream.
Not saying one is better than the other, just remarking that it's interesting to see 'getting in the way' meaning completely opposite things for different people :).
Right. Because only laid-off employees can cause such a damage of course (/s).
This is a twisted way to look at the risk.
Disgruntled employees have more reason to wreak havoc. All the more reason
they should be treated as humanely as possible in a difficult period that
in most cases is inflicted by the company itself.
I have been out of the field for some time, so I am not sure how much BLAST is used these days.
Therer was a time when BLAST-ing a DNA and protein sequence you have is like doing a Google search on it: it simply tells you where the sequence might come from. This is useful especially when your research is to figure out what that specific sequence is doing. It won't give you the answer immediately (otherwise why bother doing the research at all), but it certainly gives context: sequence similarity often hints at similar / related functions.
As an analogy: imagine if StackOverflow is suddenly down and you don't know *if* it's going to be up again.
> in the Hack Club Slack (Discord-style online groupchat), you'll find a group of 27,253+ fabulous ...
See, in my head Slack comes first before Discord. It was released, after all, 2 years prior. My mental shortcut for Discord is that it's like Slack but for games so it has better audio support. But here it's the other way around.
It's ok ~ perhaps the on-ramp path is Discord -> Slack -> IRC :).
I can second AsciiDoc. It hits the sweet spot between Markdown (arguably more suited for short-ish content) and LaTeX (full-blown academic papers with citations, formulas, etc.).
Have been using AsciiDoc for the past few years and loving it, only falling back to Markdown on places where AsciiDoc is not (yet?) available. GitHub and GitLab, for example, supports rendering AsciiDoc. PyPI unfortunately has not supported it, but more seem to be looking into it [1], which is great.
GSoC is awesome and I'm happy to see it's still running.
The experience I got as a student in 2012 was invaluable for my career in tech ~ more so since I did not formally study CS. It introduced me to so much: a lot of the programming itself, collaborating with fellow developers.
I spent one year preparing for it, and man seeing my proposal accepted was one of the best feelings I have ever experienced (much better than when I graduated, even). A close second is knowing that I actually was helping people with my code (I still keep the emails where people sent me questions about the library API I was developing).
I hope this year's (and future) batches of students get to experience the same (if not more) highs :).
> But the real question is why they don't do the same for tax evasion?
Who says they don't?
If I had to guess, I would say the magnitude of the problem is just more complex. The tax system is more complicated and impacts more people.
They did attempt to change the law to give the tax agency more similar powers[1]. Last I checked, it was rejected due to public outcry[2]. I do not expect this to be the last attempt.
It's neat ~ could have used checks in-between to ensure e.g. `$(go env GOBIN)` is not empty.
For something more comprehensive (of course with a larger install size) and the possibility of handling not just Go, I have had good experiences with asdf [1].
Not really (for the first part at least, am not yet finished with the second part). I did deviate a little bit with my Rust implementation.
This was my goal anyway: implement Lox differently. Off the top of my head:
* I used ADTs to encapsulate error types and states as much as possible, this lead to heavy use of enums and pattern matching.
* I implemented the `Environment` as an immutable, explicitly passed value. This was a little challenging at first, but overall quite satisfying to do.
I didn't worry because of Java's perceived lack of 'excitement'.
Just that I am more familiar with other languages and I worried I'd get lost trying to understand Java and not digest the material properly. I tend to fall down rabbit holes sometimes ...
If anything, this has been another way for me to be more acquainted with Java, which I am happy for :).
I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with).
Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one implementation).
Boy was I glad I did.
Writing is superb, end-of-chapter challenges are instructive, code samples are meticulously and beautifully done. Here and there I also encountered references to other languages (e.g. had a brief detour to Lua internals [1], thanks to a side note), which I have enjoyed too.
Went through the first half twice: first using Java as it is written and then secondly implemented the interpreter in Rust (my initial fear turned out to be unfounded). Currently going through the second half.
Introducing `false` as a standalone type but not `true` is what makes this weird. Generic, literal returns are fine. Python is another language that has it [1].
The introduction of the RFC [2] also still mentions `false` is of type bool:
> null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool.
But why call it bool if `true` is not a standalone type too?
Here I disagree. HTTPS gives guarantee to visitors of the site that they can trust the information being served to them.
A malicious actor hijacking plain HTTP connections does not necessarily have to inject code that harms the user's computer directly. He/she could also just alter bits and pieces of the served content to trick the user into doing something not in his/her interest.
So while having better browser sandboxing and protection is good (and welcome), HTTPS is still necessary.
I came into `nodenv` after being a regular user of `pyenv` for a while. Started with `nvm`, but wished for something more pyenv-like.
There is also `asdf` [2], which seems even more generic. On paper it looks interesting, but I haven't found a solid reason to switch out of `pyenv` and `nodenv`.
Has anyone tried `pyenv` and/or `nodenv` and switched to `asdf`?
Why do you think it is the worst? If you don't consider Python, what would you then think is the worst?
Genuinely curious. I use Python daily and I rarely encounter problems with it. There is some getting used to in the beginning, but I went through a similar phase when I started using npm and cargo as well.
What I can say is that I had to go through a lot of experimentation myself to arrive at the tools I use now (pyenv + Poetry). And if anything, maybe the lack of one way that is adopted by everyone in the community is the problem.
> how does the „two copies“ phenomenon of the human genome and the „two copies“ thing of chromosomes fit together? Are those one and the same concept?
Which phenomena are you referring to exactly? That we have two copies of each chromosome and if they mean we have two copies of the human genome?
> Are there two copies of the XY chromosome, too?
Each of our non-sex cells[1] contain two sex chromosomes: one from our father and one from our mother. Since your mother always inherits her X chromosome, your sex is determined by which sex chromosome you got from your father. If you are a female (XX), your father passed on his X chromosome. If you are a male (XY), your father passed on his Y chromosome.
This rule makes for some interesting inferences. For example, your father in turn got his X chromosome from your grandmother and his Y chromosome from your grandfather (both on your father side, of course). Your mother, on the other hand, got his X chromsome from both your grandparents on her side.
So if you're a male, your Y chromosome was passed on from your grandfather on your father's side. If you're a female, one of your X chromosome comes from your grandmother on father's side, but your other X chromosome may come from either of your grandparents on your mother's side.
You can trace this Y-chromosome lineage back to what's called the Y-Chromosomal Adam, which is the last universal common ancestor of all currently living human males[2]. You can make a similar inference using your mitochondrial genome[3] and arrive at what we call the Mitochondrial Eve[4].
Our sex cells[5] are different, since they only have one copy of our chromosome set. The number of the chromosome set we have is called ploidy[6] and so our sex cells are haploid cells, as opposed to our non-sex cells, which are called diploid.
If you're a male, a single mature sperm cell in your body contains either the X or Y chromosome. For females it's different, since they only have the X chromosome, all their mature cells contain only one copy of the X chromosome.
I used to do print debugging a lot. And then I tried using the `breakpoint()` call available since Python 3.7[1], and now I can't imagine doing any serious debugging without PDB (or any other debugger).
(I mentioned Python, since this is linking to the Python-flavor of Icecream).
Sure, there are still times when just calling print() is sufficient. But they are becoming less frequent. `print()` is only shorter than `breakpoint()` by just 5 - len(variable_name_to_print) characters after all.
I know `import pdb; pdb.set_trace()` was available before, though `breakpoint()` is just a lot simpler, among others for the reasons they mentioned in the PEP.
There is also the `--pdb` flag in pytest[2], that lets me jump into a PDB session upon test failure.
All of this makes me think, what are the cases where print-level debugging is the better option in Python, compared to using an actual debugger?
Those aren't necessarily oppposing points.
NixOS is a declarative distro. It also happens to come with some defaults that, I assume, caters to the commonly expected use case (and maybe has some historical roots as well).
NixOS is not a minimal, build-from-scratch distro. It's more opinionated than e.g. Arch. For example, it ships with firewall turned on by default (https://nixos.wiki/wiki/Firewall). Another example: the default list of packages is somehow Perl, rsync, and strace (https://search.nixos.org/options?channel=26.05&query=default...). Blanking this default to an empty list is IME harmless.
The declarative nature is probably the subtext the author is trying to convey: what are the things one can do to disable these defaults, to reach a very minimal system (ISO really) that one can then build as one wishes.