• 0 Posts
  • 80 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle

  • So true. I mostly live in the embedded world but have had to write GUIs from time to time, mostly to connect and send commands to some sort of embedded device.

    I always start with a cli version for testing and then write the GUI. A quick wrapper around the comms library and I’m done.

    But there are so many annoying fiddly little details in the GUI to deal with that it usually takes as long just to write the GUI as it does the entire rest of the code. Layout, menus, tooltips, icon choices, dealing with screen sizes, DPI, resizing windows, responsive data, etc.

    Edit: A simple example that I’ve dealt with many times is reading and writing config data. For the CLI version it’s typically two commands:

    ‘tool read_cfg’ reads from the device and prints the config to stout

    ‘tool write_cfg’ reads a config from stdin and sends to the device.

    Add a ‘-f’ option to use a file instead of stout for people that don’t remember how to use redirects. Add a couple of documentation sentences to the help command. If there are any issues, print them to stderr and bail. If the user wants to edit the config they can use whatever $EDITOR they prefer.

    The same functionality in a GUI means that you have to first implement an editor for values. In my case that was generally a bunch of nested key/value pairs so I could probably find a widget that would work. And then understand how it handles being resized, gets styled, uses tooltips, etc. Of course there would need to be some code to get the data into and out of that widget which would probably need massaging. Then I need to let the user know if there are local edits. And then there is the fact that the data is now in three places, on a local disc, on the device, and in the editor and I need to communicate with the user that there is a difference between loading and saving from disc vs the device. Do I give a warning that loading from once place will overwrite anything they’ve changed in the editor? How do I make the four load/save buttons have obvious icons? And how to handle errors? An annoying pop up? Partially load the data? Something else? So many little things that have to be designed, implemented, and tested.


  • In my case, I use several different types of machines: Personal Linux desktop, personal low end Linux laptop, remote servers where I have sudo, work Mac, shared remote work servers where I don’t have sudo. I want my setup to be basically the same everywhere so that my muscle memory works, but there are some things that also need to be a bit different for each. Hence, a dot files manager that lets me run one command to keep my environment consistent in all those different targets. I use chezmoi + git for it nowadays.


  • Oh it absolutely is. Bringing files into Be is fine. The file type sniffer runs in the background and adds whatever metadata it can in a lightweight quick way. IIRC there are addons for specific file types like media files that add nice things like author, runtime, etc.

    Sending them out is a pain though. All the metadata is usually lost and from what I recall even emailing a file from one Be machine to another could be difficult. IIRC you could zip them and the metadata would make it, but raw files and tgz would lose it.



  • My college roommate got an install CD of the first version that ran on x86, maybe 3.0? I tried it on my computer and became an instant convert. It was so astoundingly much faster and stable than Windows was on the same hardware, had a decent free IDE, and could play MP3s without skipping while compiling, browsing the internet, and spinning a GL Teapot all at once on a Pentium 75 with 16MB of RAM. Nothing else even came close for a desktop experience. I bought a copy for myself and every version that came out.

    I’ve been daily driving Linux for a long time now, but I still look back and wonder what could have been. There are still things to this day that BeOS did better and faster in the ‘90s on single core sub GHz machines with spinning rust than Linux, MacOS or Windows can on top end modern hardware.


  • I think there are a couple of reasons. First, the Linux kernel doesn’t support resource forks at all. They aren’t part of POSIX nor do they really fit the unix file philosophy. Second, most of the cool things that BeFS enables are very end user desktop oriented, and Linux leaves that desktop environments, not the kernel. BeOS was designed as a fully integrated desktop os, not a multiuser server os. Finally, I expect that they are a security headache, as they present this whole other place that malware could be stored. Imagine an innocent looking plain text file that has an evil payload sitting in an attribute.


  • If you are nostalgic for BeOS, then the elevator pitch is, “It’s Be, only on modern hardware and more software support.”

    If you are unfamiliar with BeOS, the pitch is: “Imagine an extremely lightweight desktop is with all of the things you would expect in a modern environment with none of the legacy. In an alternative universe, BeOS would have become OSX.”

    There are so many things that Be did right from the very beginning that other OSs have adopted, but never as cleanly as Be did it.

    For example, its file system. Most people don’t really notice or care about the file system, they all have directorys and hold files, maybe with permissions. BeFS does that as well, of course, but so much more. The entire file system acts as a database, so you can easily perform fast queries on it. You can also create virtual directories that are the result of those queries.

    You want a “folder” that contains every markdown file created after 2020 between 20 and 1000kb in size? Bam, instantly done and live updated whenever something accesses it. The files aren’t actually copied there, just appear there to normal tools, almost like soft links.

    BeFS also supports a resource fork system that it calls attributes. These can also be queried using the same database like tools as the rest of the system. File typing is done this way, every file gets a MIME type attribute and there is a daemon that sniffs them when a new file is downloaded or copied over.

    Even more, this allows some crazy things like plain text files that have font, color and other formatting elements because all that is stored as an attribute.

    Or their contact information app, which stores every person as a zero length file with details as attributes. You can create a virtual folder of all your contacts that meet a certain criteria and have other applications use that folder for whatever.

    Or the email app which stores each email as a file, and adds the basic metadata like to, from, subject, read, etc as attributes. Then you can have different virtual folders based on those. This also means that the basic file system browser is the default way to view email, because it supports all the attribute viewing, queries and such you would need. Or you can do it all from the command line using either basic cli tools or some slightly specialized ones.

    Combining attributes and virtual directories makes for a fantastic media library system, all built into the os for free. Imagine a directory that contains “Every metal song I have, from 1989 to 1993, that I haven’t played in three weeks” or whatever else you want.

    Back when people used files and all applications were local first, this was probably much more exciting, but it’s still pretty cool.



  • At one point I thought like the middle guy, but I didn’t have the money to do it so my computers were made from whatever parts I could scrounge up from dumpster diving, school auctions, or whatever. I was building or upgrading my computer every six months or so with what I found.

    Once I had the money to buy basically whatever computer I wanted, I would build a high end machine and then not bother to upgrade it until I had a friend who needed one. I pass my old one on to them and the cycle repeats.

    My laptops are still random auction finds. My current one came as a pair for $40. I popped in a new SSD and battery in one and have ignored the other. I should see if Haiku supports it well enough to be worth daily driving.











  • My version is definitely wordier, but I like it.

    add-alias() {
      if [[ -z "$1"  ||  -z "$2" ]]; then
        echo "Useage: add-alias <alias_name> \"<command_to_alias>\""
        return 1
      fi
      echo "alias $1='$2'" >> ~/.bash_aliases
      source ~/.bash_aliases
      echo "Alias '$1' for command '$2' added and sourced."
      
    }
    

    And, of course, the first thing I test it with is $ add-alias alias-add add-alias.