LemoineFairclough @ LemoineFairclough @sh.itjust.works

Posts

1

Comments

172

Joined

2 yr. ago

If you find any relevant information, please use it to improve https://www.privacyguides.org/en/android/distributions/

https://www.privacyguides.org/en/real-time-communication/

It seems this is related: https://lemmy.world/comment/14067084

I haven't seen this image before seeing this post, but I suppose this is related: https://knowyourmeme.com/memes/christmas-just-a-week-away

Whatever the first implementation does ends up being a suicide pact by default.

I agree. The behavior of rm and cat and cp and mv and dd and many other utilities don't necessarily have the interface I would prefer, but they are too widely used for it to be helpful to radically change them. It's somewhat unfortunate that these names are already reserved, but I don't think it's necessary to change them.

In the same way, I don't have a problem with packages having generic names but not actually being useful: I've read that the requests and urllib3 packages for Python aren't being maintained very well, but I don't mind that as long as I can accomplish things while following best practices.

Because of this, I'm not afraid to use names like "getRequest" or "result", especially if they were generated with an automatic refactoring, and I'm not upset when I see similarly generic names being used with source code I'm changing, since I know that the second name for something that's similar to an existing thing will have to actually be descriptive, but the first name is likely to not be.

I have another example of how I'd apply these thoughts: the process for developing v2+ modules for the Go programming language strikes me as inelegant, so I would probably prefer to just create an entirely new repository rather than try to attempt that.

What operating system should I use with my laptop that isn't an awkward kludgy idiosyncratic mess? I would say that Windows has plenty of kludges, like having problems with certain file names. Many versions of macOS are UNIX® Certified Products (for example, macOS version 15.0 Sequoia on Intel-based Mac computers and on Apple silicon-based Mac computers), so it's surely not any less kludgy than Linux.

I suppose that it's not bad to change documentation to be more specific, and change a program such that it matches the new documentation and wouldn't cause any harm if it replaced all the existing versions of the program, but makes it possible to use the program to solve more problems. That would be to "add functionality in a backward compatible manner".

You are also free to create new programs that are not an exact replacement for existing programs, but can enable some people to stop using one or more other programs. That would not be what I describe as stagnation.

"The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence.", so I would be very annoyed if it did something different with a certain file but not others. I wouldn't say that the contents of a file and the contents after the file is expanded are the same. In fact, I expect that some people use cat to process compressed files, and changing how cat acts with compressed files would probably cause them a large amount of annoyance, and would needlessly make a lot of existing documentation incorrect.

I'm impressed that this (mostly) kept the same text on an object consistently.

This has a serious sanpaku problem though: https://en.wikipedia.org/wiki/Sanpaku https://gomoviereviews.com/2016/07/sanpaku-eyes-cinematic-device/ https://www.japanesewithanime.com/2020/01/small-irises.html

I think that providing an exit status that is not 0 when zcat is used with an uncompressed file is useful. Though my opinion is less strong regarding whether it should write more text after an error occurred, it's probably more useful for a process to terminate quickly when an error occurred rather than risk a second error occurring and making troubleshooting harder.

I think that trying to change any existing documented features of widely used utilities will lead to us having less useful software in the future (our time is probably better spent making new programs and new documentation): https://www.jwz.org/doc/worse-is-better.html https://en.wikipedia.org/wiki/Worse_is_better

You are correct. This probably produces something more similar to what you'd want the original command to do, but with better safely:

 bash

    
find -- . -type f -regex '^\./[^/]*$' -exec sh -c -- 'for file in "${@}"; do zcat "${file}" || cat "${file}" || exit; done' sh '{}' '+'

  

That assumes you want to interact with files with names like .hidden.txt.gz though. If you don't, and only intend to have a directory with regular files (as opposed to directories or symbolic links or other types of file), using this is much simpler and even safer, and avoids using files in a surprising order:

 bash

    
for i in *; do zcat -- "$i" || cat -- "$i" || exit; done

  

Of course, the real solution is to avoid using the Shell Command Language at all, and to carefully adapt any program to your particular problem as needed: https://sipb.mit.edu/doc/safe-shell/

Did someone throw rocks at drones recently? I do see something like that was documented, but not recently: https://www.abc.net.au/news/2022-08-25/taiwan-soldiers-throw-rocks-chinese-drone/101371976

Remember that the system documentation can be different for different operating systems. For example, it's notorious that the documentation for sed differs between GNU and macOS, particularly regarding the -i option: https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux

In order to avoid surprises related to this, "POSIX.1-2024 defines a standard operating system interface and environment, including a command interpreter (or "shell"), and common utility programs to support applications portability at the source code level." https://pubs.opengroup.org/onlinepubs/9799919799/ https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html

Building a Cathedral without Science or Mathematics: The Engineering Method Explained

I'm assuming this is relevant: https://news.sky.com/story/ukraine-war-latest-ukraine-claims-it-killed-senior-russian-general-in-moscow-scooter-blast-12541713

There's another post with this image here: https://lemmy.world/post/23112365

Is this a trend or something https://lemmy.world/post/23112365

You might be referring to "Nonfree open source" ("source code that is open source but not free") described at https://www.gnu.org/philosophy/categories.html

Technical problems and political problems can be related, and discussing one in the context of the other can be useful.

OpenSource is preferable whenever possible, but as in anything else, fanaticism is harmful when a good proprietary soft offers a better solution

I think an engineering perspective is useful: we want to solve problems, but different people have different problems, and each person cares about each of their problems to a different extent. If one person thinks their problem is that a relevant amount of their income depends on proprietary software, then the solution is substituting free software to replace proprietary software they depend upon. If another person doesn't depend on proprietary software for their income, but thinks it's a problem that their thermostat runs proprietary software, then the solution is still to substitute free software to replace proprietary software (or to replace the thermostat entirely). However, if someone wants to increase their income tenfold and using proprietary software will accomplish that (and using free software will not), then the solution is to use proprietary software.

It's probably better to help people learn and understand how to use free software than to encourage them to use proprietary software, since free software is probably easier to maintain as someone's situation changes, but there might be some situations where the best solution for someone involves using proprietary software.

I believe these are relevant: https://www.gnu.org/philosophy/open-source-misses-the-point.html https://www.gnu.org/philosophy/categories.html

Of particular relevance is "Resurrecting projects": if you have access to "open source software" but are denied access to install or run modified versions of the software, the access is not particularly useful.

For posterity, I see that another place this person has been asked for a source is https://lemmy.world/comment/13801385