Note that there are irrecoverable costs to owning your housing too: https://www.youtube.com/watch?v=q9Golcxjpi8
See also https://lemmy.world/post/23582960
Note that there are irrecoverable costs to owning your housing too: https://www.youtube.com/watch?v=q9Golcxjpi8
See also https://lemmy.world/post/23582960
I had some thoughts about the concept of a “Contributor License Agreement”.
If you are the sole author of a program, you have a special position in that you can distribute the program with any license you choose. People that are not the sole author that copy the source code are not able to do that. If the original sole author of a program incorporates changes from someone that did not sign a Contributor License Agreement, they lose that special position, since distributing the program with a new license would require consent from all the authors, which is surely harder if there are more authors.
Because of this, it might be worth supporting some “community fork” more than an “original” repository, since that makes it clear that the program is likely to only be distributed using a specific license. However, if I’m interacting with an “original” repository, I will expect to have to interact with a Contributor License Agreement in order to have my changes used, since the original authors will want to preserve some flexibility regarding what licenses they can use with their software.
That is not obvious from only looking at https://sh.itjust.works/post/29452661
I can imagine that someone would find a program like this to be useful, and depends on the presently common behavior of zcat
, so I expect this is an important part of a system used by a corporation I interact with (and probably many more than I’d expect):
if
zcat ./file.txt.gz >/dev/null
then
process_file ./file.txt.gz
else
printf '%s\n' "There was a decimal exit status of ${?}"
fi
A failure to understand whether something is useful is not a good reason to change it.
An interesting perspective I heard about is “affordability”. To describe that with my own words: if your income is stable or will grow compared to your housing costs, and housing costs are not burdensome to you, housing is affordable to you. Owning a house rather than having a lease should make your housing costs vary less, so if housing costs will go up in the future it might be useful to buy a house (but if housing costs will go down in the future it might not be useful to buy a house). I found some graphs for “Affordability”: https://dqydj.com/historical-home-affordability/ https://fred.stlouisfed.org/series/FIXHAI
I have also heard that it’s hard to find people to do repair work in some places, and that people there charge a lot of money for their services. If you have trouble finding someone who you can pay just to produce a quote for a roof repair, the actual cost of housing will probably be higher than in other places.
I had a thought after looking at this post: I expect that it’s better to own land in places that are more likely for people to want to move to or work near.
I personally don’t use either of the browsers you mentioned: https://www.privacyguides.org/en/mobile-browsers/
I thought this was obvious: avocado seeds are large because they were eaten by giant sloths. It would surely be much more difficult for an avocado tree to reproduce without the involvement of an animal, and giant sloths are not around anymore, so at some point humans must have taken over from the giant sloths, so there was probably some place where humans and giant sloths lived at the same time.
Car manufacturers aren’t required to document how to repair “infotainment centers” because they aren’t critical to the operation of a car. Making them more useful might require a car manufacturer to spend more money by allowing more requirements to be imposed upon them.
If you find any relevant information, please use it to improve https://www.privacyguides.org/en/android/distributions/
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 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:
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:
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/
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
Are you sure there is no shelter available? It seems there will be at least one that is less than 30 minutes away by car: https://www.msb.se/en/advice-for-individuals/civil-defence-shelters-evacuation-and-warning-systems/good-to-know-about-civil-defence-shelters/ https://msbgis.maps.arcgis.com/apps/instant/nearby/index.html?appid=8bfc89e7c6064bc181c6a1a6bbac2fa3&sliderDistance=1
There is “space for around seven million people” and Sweden’s population is about 10.6 million, and the availability of shelters seems to match the population distribution pretty closely. You could at least let your neighbors know that they can have your space in a shelter (since there might be about 3.6 million people who won’t fit in shelters), or show up anyway in order to help carry away any materials that were being stored in a shelter in peacetime, or to help get food or water into a shelter.