loveknight, loveknight@programming.dev
Instance: programming.dev
Joined: 8 months ago
Posts: 13
Comments: 14
Posts and Comments by loveknight, loveknight@programming.dev
Comments by loveknight, loveknight@programming.dev
"(...) Dr. Stallman notes that he cannot comment much about technical aspects of Rust, but he remains concerned (for a year already) about the trademark aspects. He is still receiving no clarification or assurances on the matter. Previously he suggested forking it and calling it something like "crust" (in a talk or a session he did with several Brazilian hackers). " (via)
How will we stave off ecosystem takeover if not by taking its early signs seriously? At the start of every case of "Stallman Was Right" was a lot of presumption that, in the eyes of many, did not make a solid conclusion.
They really want people to stop talking about the Epstein files, huh?
As the saying goes, don't throw the baby out with the bathwater. I think @floofloof@lemmy.ca summed things up pretty well here.
Also, from my reply to that comment:
As for the off-putting statements about ‘Rust people’: Since the article was published on March 19, I wonder if much of it, revolving around what the author saw as indications of authoritarianism, came from heavy disquiet in the face of authoritarianism’s recent gaining hold of the White house. I’d even consider it likely that people who post on Techrights have an above-average sensitivity for this kind of thing. It could be that the author has since arrived at a more differentiated and just view. Of note, since the time of his writing, the Rust project did remedy things that he criticized about their website.
Agree on everything. (As for the off-putting statements about 'Rust people': Since the article was published on March 19, I wonder if much of it, revolving around what the author saw as indications of authoritarianism, came from heavy disquiet in the face of authoritarianism's recent gaining hold of the White house. I'd even consider it likely that people who post on Techrights have an above-average sensitivity for this kind of thing. It could be that the author has since arrived at a more differentiated and just view. Of note, since the time of his writing, the Rust project did remedy things that he criticized about their website.)
1) Your criticism omits the passages about usage of the MIT license over the GPL (the ones I quoted in the post). I haven't quoted the other parts of the article because they are not as substantial, but their being opinionated and questionable in what they say about 'Rust people' does not mitigate the recklessness of those who strive to create MIT-licensed replacements for GNU coreutils.
2) Discord on the website of the Rust project: That's not a lie at all: it was the truth at the time of publication on March 19, and even as late as May (having been there for at least four years). So it appears that the Rust project has decided to drop Discord as an officially advertised channel. Good move. I would think that vocal criticism like the author's played a role in this.
3) Rust forum telling users to use Firefox, Chrome or Safari, and refusing to be accessible by other browsers (however circumventible this may have been): How was this not a sign of flagrant disregard for free software and for people's right to use the web however the fuck they want to use it - or how they need to use it, in case of disabilities? (This antifeature doesn't seem to be in place anymore, but compare point 2.)
We've been warned. (And unsurprisingly, Roy Schestowitz is being bomarbed by Microsofters with a chain of SLAPP suits.)
Perfect, thanks for the explanation. Indeed, I found the same solution via StackOverflow about simultaneously.
Ah that's good to know about zsh.
Sorry regarding the second code block; it does indeed work as intended, and quite elegantly.
For the first code snippet to run correctly, $list would need to be put in double quotes: echo "$list" | ..., because otherwise echo will conflate the various lines into a single line.
The for loop approach is indeed quite readable. To make it solve the original task (which here means that it should also assign a number just smaller than $threshold to $tail, if $threshold is not itself contained in $list), one will have to do something in the spirit of what @Ephera@lemmy.ml and I describe in these comments.
Thank you, in fact I ended up doing something that's mathematically pretty much just that: I have the previous line stored in an auxiliary variable lastline, and it is the evaluation of the current line $0 that determines whether the previous line gets printed.
awk -v threshold=150 'BEGIN {lastline=""}
(lastline!="" && threshold<$0){print lastline} #the additional check lastline!="" prevents an empty line at the very beginning
{lastline=$0}
END{print} #hardcode printing of the very last line, because otherwise it would never be printed
'
Of note, in the case where some list entries are repeated, the behavior of this script will be:
- The threshold value, if it's in the list, will always be printed just once, even if it occurs multiple times in the list, and also if it happens to be the first, last, or only entry in the list.
- All larger entries will be printed exactly as often as they occur in the list. This even holds for the largest value: its last repetition will be printed via the final END{print} statement, whereas all preceding instances get printed through the statement that depends on threshold<$0.
(IIRC, it was a StackOverflow post that led me to this.)
Very specifically for learning about GNU/Linux and Unix, I highly recommend the book Classic Shell Scripting by Arnold Robbins and Nelson Beebe (O'Reilly Media, 2005).
ISBN: 9780596005955
I recently wrote the following about it in a post:
This book is extremely readable and gives a very good introduction to the various standard Unix shell commands (grep, sed, awk, tr, sort, to name but a few) and how to tie them together to do useful things. It’s very suitable if you have some experience with the command line at the level of individual commands but now want to see how to do construct more interesting pipelines and scripts. It includes an introduction to regular expressions. The fact that the book is already 20 years certainly means that some explanations and approaches are outdated, but since shell programming is at the core about text processing, almost all contents of the book are still highly relevant today.
New to this instance, but for me too it is comparatively sluggish since I started using it yesterday.
Or get a used thin client (e. g. HP T620, T630, T640 or Dell Wyse 5070). Cost: ~40-100$. Biggest advantage: Passive cooling, i. e. they're absolutely quiet.
"(...) Dr. Stallman notes that he cannot comment much about technical aspects of Rust, but he remains concerned (for a year already) about the trademark aspects. He is still receiving no clarification or assurances on the matter. Previously he suggested forking it and calling it something like "crust" (in a talk or a session he did with several Brazilian hackers). " (via)
How will we stave off ecosystem takeover if not by taking its early signs seriously? At the start of every case of "Stallman Was Right" was a lot of presumption that, in the eyes of many, did not make a solid conclusion.
They really want people to stop talking about the Epstein files, huh?
As the saying goes, don't throw the baby out with the bathwater. I think @floofloof@lemmy.ca summed things up pretty well here.
Also, from my reply to that comment:
Agree on everything. (As for the off-putting statements about 'Rust people': Since the article was published on March 19, I wonder if much of it, revolving around what the author saw as indications of authoritarianism, came from heavy disquiet in the face of authoritarianism's recent gaining hold of the White house. I'd even consider it likely that people who post on Techrights have an above-average sensitivity for this kind of thing. It could be that the author has since arrived at a more differentiated and just view. Of note, since the time of his writing, the Rust project did remedy things that he criticized about their website.)
1) Your criticism omits the passages about usage of the MIT license over the GPL (the ones I quoted in the post). I haven't quoted the other parts of the article because they are not as substantial, but their being opinionated and questionable in what they say about 'Rust people' does not mitigate the recklessness of those who strive to create MIT-licensed replacements for GNU coreutils.
2) Discord on the website of the Rust project: That's not a lie at all: it was the truth at the time of publication on March 19, and even as late as May (having been there for at least four years). So it appears that the Rust project has decided to drop Discord as an officially advertised channel. Good move. I would think that vocal criticism like the author's played a role in this.
3) Rust forum telling users to use Firefox, Chrome or Safari, and refusing to be accessible by other browsers (however circumventible this may have been): How was this not a sign of flagrant disregard for free software and for people's right to use the web however the fuck they want to use it - or how they need to use it, in case of disabilities? (This antifeature doesn't seem to be in place anymore, but compare point 2.)
We've been warned. (And unsurprisingly, Roy Schestowitz is being bomarbed by Microsofters with a chain of SLAPP suits.)
The dangerous push by Canonical to rewrite GNU coreutils as Rust code without the GNU license (techrights.org)
Earlier post version: image/text.
The dangerous push by Canonical to rewrite GNU coreutils as Rust code without the GNU license (techrights.org)
Earlier post version: image/text.
The dangerous push by Canonical to rewrite GNU coreutils as Rust code without the GNU license (techrights.org)
Earlier post version: image/text.
The dangerous push by Canonical to rewrite GNU coreutils as Rust code without the GNU license (techrights.org)
Earlier post version: image/text.
Book recommendation if you've been using Python for a while: Effective Python by Brett Slatkin
It’s currently in its third edition, published November 2024.
The Shell Scripting Tutorial: Parsing long command-line arguments with getopt (shellscript.sh)
This is a little tutorial that I found in my search to learn how to use getopt (mind: not getopts, which is a completely different thing). I want to share it here because I find it refreshingly to the point. Just the main code block already tells almost the whole story:
Perfect, thanks for the explanation. Indeed, I found the same solution via StackOverflow about simultaneously.
(Solved) Ways to run the join command on memory/variable contents instead of files?
Edit: I figured it out: The solution is over a process substitution operator:
Ah that's good to know about zsh.
Sorry regarding the second code block; it does indeed work as intended, and quite elegantly.
For the first code snippet to run correctly,
$listwould need to be put in double quotes:echo "$list" | ..., because otherwiseechowill conflate the various lines into a single line.The for loop approach is indeed quite readable.
To make it solve the original task (which here means that it should also assign a number just smaller than $threshold to $tail, if $threshold is not itself contained in $list), one will have to do something in the spirit of what @Ephera@lemmy.ml and I describe in these comments.Thank you, in fact I ended up doing something that's mathematically pretty much just that: I have the previous line stored in an auxiliary variable
lastline, and it is the evaluation of the current line$0that determines whether the previous line gets printed.Of note, in the case where some list entries are repeated, the behavior of this script will be:
- The threshold value, if it's in the list, will always be printed just once, even if it occurs multiple times in the list, and also if it happens to be the first, last, or only entry in the list.
- All larger entries will be printed exactly as often as they occur in the list. This even holds for the largest value: its last repetition will be printed via the final
END{print}statement, whereas all preceding instances get printed through the statement that depends onthreshold<$0.(IIRC, it was a StackOverflow post that led me to this.)
Say you have a list of increasing numbers and a threshold. How do you get the highest number smaller-or-equal to the threshold *and* all numbers that are larger?
Let me show you what I mean by giving an example:
Very specifically for learning about GNU/Linux and Unix, I highly recommend the book Classic Shell Scripting by Arnold Robbins and Nelson Beebe (O'Reilly Media, 2005).
ISBN: 9780596005955
I recently wrote the following about it in a post: