• 0 Posts
  • 16 Comments
Joined 1 year ago
cake
Cake day: September 20th, 2023

help-circle
  • Yes, but you know what I did? nothing, I just have the program exclusively accept lowercase doom.wad

    This means it became annoying for the user. The problem shifted and now it’s the end-user the one with the responsibility to read the manual and do the work. A lot of people just get a DOOM.WAD, put it there and are surprised it doesn’t work.

    And there are many many programs that are doing the same thing in many similar situations. In fact, in the Linux world, most software pushes this to the end user. So this is just as much of a problem for users as it is for programmers.

    At the end of the day, the question should not be: is it more complexity for the user or for the programmer? …the question should be: what’s the end cause making it complex? is there a way it can be made simpler?

    This is the same for every problem. Often user-friendliness is a tradeoff, most user-friendly software I’ve used keeps so much complexity within that it becomes annoyingly slow and inefficient. I’d rather use the terminal for file management than wait for the GUI file browser to finish loading my huge remote storage directories.


  • But then you are not getting rid of the complexity, you are just forcing programs to become more complex/inefficient.

    I experienced this with the doom libretro core, which is meant to be portable and have minimal dependencies… so if I need it to automatically find DOOM.WAD/ doom.wad/Doom.WAD/etc in a directory I would either have to add a globbing library as dependency to handle this case and have it fetch [Dd][Oo][Oo][Mm].[Ww][Aa][Dd], manually check for each possible case, or list the entire directory (I hope you don’t have a library of a million wads!) and compare each file (after upper/lower) just to find the one with the right name. And that could be a real pain for embedded devices with low I/O or if there’s a remote storage layer behind.


  • I’m with you, and not just from a “human” perspective. Also when writing small programs meant to be relatively lean/simple it can be a problem when the user expects it to find a particular file regardless of its case (will it be DOOM.WAD or doom.wad? Doom.wad? Doom.WAD? … guess it’ll have to be [Dd][Oo][Oo][Mm].[Ww][Aa][Dd] and import some globbing library as extra dependency… that, or list the whole directory regardless its size and lower/upper every single filename until you find a matching one…)


  • I agree that we shouldn’t worry (at least for the moment), but I think the main reason is the lack of locks, both when it comes to hardware (no locked bootloader) and software (getting root access is trivial, so you can uninstall whatever components you might not like and with updates not being mandatory you can keep it under your control).

    With SteamOS, you already have an ecosystem, which is Steam. There is (at least for now) a clear distinction between Hardware manufacturer and software provider.

    Currently, the only officially sanctioned version of SteamOS is the one that is shipped with Steam Deck (even though that might change soon), which is hardware sold by Valve (ie, the same company making the software). Meanwhile, most people using Android don’t use Pixel / Nexus devices and thus their hardware is not being sold by Google.

    So I’d say this depends entirely on how do the new manufacturers wanna go about it when it comes to offering their own custom versions of SteamOS. At the moment this is ok because Valve has been acting as a “benevolent dictator” and they have essentially had a monopoly on SteamOS 3 devices until now. Once that monopoly breaks (and if Valve actually allows third parties to ship their own customizations) we’ll have to see what kind of control will their partners want to assert over it.




  • That’s horrible for muscle memory, every time I switch desk/keyboard I have to re-learn the position of the home/end/delete/PgUp/PgDn keys.

    I got used to Ctrl-a / Ctrl-e and it became second nature, my hands don’t have to fish for extra keys, to the point that it becomes annoying when a program does not support that. Some map Ctrl-a to “Select all” so, for input fields where the selection is one line, I’d rather Ctrl-a then left/right to go to the beginning/end than fish for home/end, wherever they are.


    • Alt-delete deletes the whole word before cursor
    • Alt-d deletes the whole word after cursor
    • Ctrl-k deletes (kill) everything after the cursor

    Whatever is deleted is stored in the “killring” and can be pasted(yanked) back with Ctrl-y (like someone else already mentioned), consecutive uses of Alt-delete/Alt-d add to the killring.

    • Alt-b / Alt-f moves one word backwards / forwards
    • Alt-t swaps (translocates) the current word with the previous one
    • Ctrl-_ undo last edit operation

    All those bindings are the same as in emacs.

    Also, normally Ctrl-d inserts the end-of-file character, and typically can be used to close an active shell session or when you have some other interpreter open in the terminal for interactive input.


  • That quote was in the context of simply separating values with newlines (and the list also included “your language’s split or lines function”).

    Technically you don’t even need awk/sed/fzf, just a loop in bash doing read would allow you to parse the input one line at a time.

    while read line; do 
       echo $line # or whatever other operation
    done < whateverfile
    

    Also, those manpages are a lot less complex than the documentation for C# or Nushell (or bash itself), although maybe working with C#/nushell/bash is “easy when you’re already intuitively familiar with them”. I think the point was precisely the fact that doing that is easy in many different contexts because it’s a relatively simple way to separate values.


  • For the record, you mention “the limitations of the number of inodes in Unix-like systems”, but this is not a limit in Unix, but a limit in filesystem formats (which also extends to Windows and other systems).

    So it depends more on what the filesystem is rather than the OS. A FAT32 partition can only hold 65,535 files (2^16), but both ext4 and NTFS can have up to 4,294,967,295 (2^32). If using Btrfs then it jumps to 18,446,744,073,709,551,615 (2^64).





  • What do you mean by “not require sudo privileges”?

    Do you mean not require root permissions? that depends on what are you trying to do. You’ll need to make changes in your system to allow normal users to have permissions for it, and in many cases that’s not possible (or very safe).

    If what you mean is that you don’t want to need to type"sudo" every time, but still be able to have the commands run with root permissions, then there’s multiple ways to do this:

    • Add an alias such as alias command='sudo command'. If you don’t want to type the password, you can change the sudores file so that your user doesn’t need to enter a password when running sudo for that command (someone else in the comments already explained how to do that, using an entry with NOPASSWD: /usr/bin/command in the sudoers config).

    • alternatively: set the SUID bit of the executable you want to run, so that every time the file is executed (by anyone) it will always execute as the user who owns the file (so if the owner is root, the file will always be executed as root)… this is not something I’d recommend though, since it can lead to security vulnerabilities.



  • What C does depends on the platform, the CPU, etc.

    If the result actually differs due to compilers deviating in different architectures, then what we can say is that the language/code is not as portable. But I don’t think this implies there’s no denotational semantics.

    And if the end result doesn’t really differ (despite actually executing different instructions in different architectures) then… well, aren’t all compilers for all languages (including Rust) meant to use different instructions in different architectures as appropriate to give the same result?

    who’s to say what are the denotational semantics? Right? What is a ‘function’ in C? Well most C compilers translate it to an Assembly subroutine, but what if our target does not support labels, or subroutines?

    Maybe I’m misunderstanding here, but my impression was that attempting to interpret the meaning of “what a function is in C” by looking at what instructions the compiler translates that to is more in line with an operational interpretation (you’d end up looking at sequential steps the machine executes one after the other), not a denotational one.

    For a denotational interpretation of the meaning of that expression, shouldn’t you look at the inputs/outputs of the “factorial” operation to understand its mathematical meaning? The denotational semantics should be the same in all cases if they are all denotationally equivalent (ie. referentially transparent), even if they might not be operationally equivalent.