But it is important for people like you and me to be aware of the concept and issue in general.
224 karma · joined December 20, 2011
But it is important for people like you and me to be aware of the concept and issue in general.
The grandparent post was wondering what the issue is, and my post described what IMHO is the main potential issue.
You have your opinion on to what degree this might be a problematic instance of cultural appropriation, and I have my opinion (which I haven't stated).
But the point is that the opinion that matters is that of Iroquois people and other descendants and (cultural) inheritants of the person whose name is being used. (Not that they are obliged to have an opinion on this, or to speak with a single voice on this matter.)
And it's not a cultural issue that's particular to the US. It appears that the author of the Hiawatha web server is not from the US either (Wikipedia suggests he is Dutch), so you might ask what link he has to Hiawatha and what justification he has for using the name and laying claim, in whatever small way, to a piece of the original Hiawatha's prestige.
The term to research is cultural appropriation.
(Clearly all these web servers are following Apache's lead in their naming. ISTR a story in the past that ASF had (retroactively) sought and/or received the blessing of the Apache Nation leadership for their use of the name; there's some related information at <https://www.apache.org/apache-name/> though nothing as clear-cut as the story I'm vaguely remembering.)
https://github.com/samtools/samtools/pull/1165 https://github.com/samtools/htscodecs/pull/22
which work around limitations in the default system awk on Solaris/OpenIndiana/whatever the remnants of SunOS are called these days…
Just skip over them: From the Egyptian some-class-of numerals used in almost all the some-kind-of tasks of the Egyptian state, etc.
(Also, welcome to reading a text for which you are perhaps not the target audience. Now think about all the computing jargon that we tend to just take for granted in our own writing...)
C itself doesn't need this, because you can write `else if …` without needing to put another layer of braces around the subordinate `if` statement.
Sure, in isolation it's more orthogonal. But it's hard to see this as a real value add when amortised against the compatibility headache, when the arguably cleaner alternative of `#if defined FOO ... #elif defined BAR ... #endif` is already available.
(Incidentally (1) you can choose to also spell out `#ifdef FOO` as `#if defined FOO` when it's one of a list of alternatives like this, so they all look similar; (2) there's no need for excess parentheses with `#if defined` either.)
(Or with the Annex K variants -- memcpy_s(), memmove_s() -- if that floats your boat, and as this is Microsoft it surely does.)
* News wires are large old distributed networks. There may still be old equipment attached to it that natively uses this encoding; or modern software may still be using the compatible encoding because it was never practical or cost-effective to have a "flag day" to switch over.
* Even if the technical limitation has been lifted, the convention may live on as part of the folklore of the field.
See https://en.wikipedia.org/wiki/Baudot_code#ITA_2_and_US-TTY
There was a time before ASCII, you know...
Half-open because of the slicing properties, as noted in your posting and the grandparent posting.
0-based because of the simplification for converting between relative coordinate systems. Suppose you have one interval A represented as offsets within a larger interval B, and you'd like to know what A's coordinates are in the global coordinate system that B uses. This is much easier to compute when everything uses 0-based coordinates.
Here is a slightly longer discussion of that in a genomics context: https://github.com/ga4gh/ga4gh-schemas/issues/121#issuecomme... and a draft of a document I wrote up (again, in a genomics context) so as never to have to have this discussion ever again: https://github.com/jmarshall/ga4gh-schemablocks.github.io/bl...
Personally I don't see much reason for this to be implemented via a git repository (rather than a text field in a database, like the existing Bio text), other than "we're GitHub, everything's a git repository, so why not".
At the moment, it's a single-file repository. Perhaps they have some ideas for other things that could be served from there too.
Weirdly at the moment it's required to be a public repository. This seems counterproductive: if it's my personal information blurb I don't much want other people looking at its history and I certainly don't want them forking it. (Are there any non-malicious reasons for doing that?)
Fortunately it's easy to use a little custom CSS to revert them to square images, at least for now:
https://gist.github.com/jmarshall/a880c93725ee727abb54473582...
This is a time when BLM protests have led to various aspects of structural racism in society being reexamined. For tech, it's a good time to reexamine use of .io too.
After `make clean` and `git status --ignored` shows nothing worth preserving, you can delete the worktree (via `git worktree remove`) with impunity. No more paranoid checking that there is no valuable work stashed or hiding in other branches before typing `rm -rf`, as those are shared with the main worktree so won't be lost.
It's one thing to run a webserver while your software is running.
It's quite another to leave it installed and running even after the user has uninstalled your application.
And to actively evade the user's attempts to remove the webserver component. Until this update, if you removed ZoomOpener from your Login Items and via `rm -rf ~/.zoomus`, it would miraculously reappear every time you participated in another Zoom meeting. (To stop this, you had to touch .zoomus as a file or otherwise make it harder to recreate as a directory. But if they had chosen to, Zoom could have coded around these countermeasures thus leading to an arms race, at least for a while.)
I still fire up my T61 from time to time -- it's the only computer in the house that still has a DVD drive.
Classy.
I'm involved in BAM and CRAM -- it feels like a collaboration to me!
These formats are a collaboration between bioinformaticians at a number of research institutes and companies around the world, with various charity, governmental, or other funding. They are maintained under the auspices of GA4GH, which is indeed something like W3C.
That may be true in the abstract or in the case of MPEG's multimedia technologies. It is not true in this specific case of genomic file formats.
The existing formats in use in the field (BAM and CRAM) that MPEG-G is looking to supplant come from the genomics community itself. They have come about in the course of bioinformaticians' work analysing sequencing data or as bioinformatics research [1]. Thus this R&D has primarily been bankrolled as scientific research; the funding comes from scientific charities or other scientific research funding.
That is to say, it has come from collaboration.
[1] CRAM originates from "Efficient storage of high throughput DNA sequencing data using reference-based compression", published in Genome Research in 2011. <https://genome.cshlp.org/content/21/5/734.long>
It's more that CRAM is an incumbent format, developed by (different members of) the same genomics community that made the preceding BAM format in the same space. Both BAM and CRAM have been in common use in the field for 5+ years.
As the newcomer, the onus is on the MPEG-G proponents to compare its performance to the formats already in common use.
It's a shame, because the Git dispatching code ought to be able to invoke the ssh command via
ssh -p 22 -etc -etc -- <hostname>
to prevent interpreting options in <hostname>, thus defusing the in-band signalling causing this. But I suppose it can't depend on every ssh implementation understanding this "--" POSIX utility syntax guideline.e.g. https://github.com/samtools/htslib/issues?q=is%3Aissue%20aut...
Makefile:2: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
See 2c64fb221a265f9e7fc93374906b1e7540377561: 1998-09-04 Paul D. Smith <psmith@gnu.org>
* read.c (read_makefile): If we hit the "missing separator" error,
check for the common case of 8 spaces instead of a TAB and give an
extra comment to help people out.
I guess you may have indented it in the modern way with 4 spaces of "tab". Either way, there's also help to be had from your other tools, e.g., vim highlights space-indented make recipes in glaring red error bars.That niche doesn't particularly exist anymore, so strncpy() isn't often a good fit for what people need these days. Hence they don't like strncpy(), but what they really mean is that they shouldn't have been considering strncpy() in the first place.
strncat() on the other hand... now that's a weird function!
But there's no explanation of why we don't need a GOT any more.
Possibly this is "Reuse of the PIC hard register" noted in https://gcc.gnu.org/gcc-5/changes.html ..?