Are "hard links" important or a nice to have in a filesystem?
I'm trying to assess possible feature compromises for a #decentralized / #p2p based #filesystem that can be mounted on multiple machines, so any views on the usefulness of hard links with examples would be appreciated.
One such compromise here is merging of changes made from different devices, that will be much harder with hard linking.
Anyone familiar with Syncer, a virtual disk written in Rust?
It's a massive virtual disk with #POSIX interface that can be mounted locally using #FUSE.
Written in #Rust, the architecture and backend mean it could be adapted to a decentralised backend, something I looked into in the past and an revisiting.
I'm wondering if anyone else is interested in this potential, and if anyone knows the author or second contributor.
❝Today, thanks to Android and ChromeOS, Linux is an important end-user operating system. But, before Linux, there were important Unix desktops, although most of them never made it. …❞
Maybe-contentious claim: for technically-oriented people, no user interface has ever surpassed the Unix shell.
I remember "discovering" it in 1987, 9 years after I'd started writing code in FORTRAN and BASIC. The old-timers showed me how I could do things in minutes that took weeks on other systems, like generate a full sorted concordance of a text in a single pipeline of shell commands.
(If I were ever forced to use a Mac, that's where I'd spend a lot of my time.)
When writing C++, I consistently find myself wanting to use std::string_view, because I want to take a view into a string. Then, as time goes on, I eventually want to pass that string to something which eventually has to interact with a #C (usually #POSIX) API. At that point, I need a 0-terminated string. string_view isn't zero terminated, so I revert back to using a const char * instead of a string_view.
Why oh why isn't there a std::c_string_view which contains a zero-terminated string
Today I learned how to split a variable with multiple lines for a Bash/ZSH script. I was using the previously mentioned mdb-query package, and I have a variable named tables with the different tables, separated by returns. When I fried to do for table in $tables; do echo $table; done, it did not split the lines.
I got the right output with
while IFS= read -r table; do $table; done <<< $tables
“Argument list too long” is such an archaic error.
Sorry, your computer can’t run this program, because somewhere there’s a buffer limited to one millionth of your RAM size. #posix
Since the official web GUI of #Fediseer requires JavaScript (seriously what's up with that, is this a Lemmy thing lol :P), I thought I'd write something that uses Fediseer's API, and the interface wouldn't need JavaScript to be loaded from the website and can be viewed by any plaintext-friendly client. So I settled with #Gopher! :alice_wine:
Currently you can only lookup some basic information per instance, and see all domains which they have endorsed, censured, hesitated, and guaranteed (and vice-versa) in a pure plain text format. I might write an interface for the whitelisted, suspicious, censured, and hesitated lists of instances too, but I'm not promising anything. :P As it stands, this simple Gopher CGI fits my needs for now. :kokoro_yes:
Logging in with your #API key is not supported (probably a bad idea anyway due to Gopher typically being unencrypted :satsuki_sadge:), so you won't be able to see some domain lists of instances that have restricted the viewing of endorsements/censures/hesitations they give, or modify anything in Fediseer.
It's all written in #POSIX#shell script, with the dcgi currently written with #Geomyidae's gophermap format in mind. You can see the source code (which you can treat as being in the public domain) in the URL I've given. Warning: It's pure shell script cancer! :kyou:
sudo-rs is a re-implementation of sudo in Rust. While testing sudo-rs, they have found several inconsistencies in the specification, and found 2 bugs in the original sudo implementation.
Oh wow, TIL: When you do input redirection from a file in #bash, e.g.
python whatever.py < foo.csv
the running command can actually stat() the stdin file descriptor and get the size of the input file! I would’ve expected that it’s more like “well, it’s your stdin, you can’t get the size for that, it’s a stream”.
And, to be fair, if you don’t directly associate the file to the command, it breaks. For example,
“source” is a #bashism. The actual #POSIX name of the command is “.”. That’s right, a single dot.
Many people expect . to be some kind of a shortcut for “source”, and yes, they’re equivalent in #bash, but “source” is not guaranteed to exist in other shells. dash doesn’t have it, for example.
So, if you want to write your shell scripts as compatible as possible, use “.”, not “source”.