mrlemke

Why would I pay my developers to do bug fixes if you've only paid me once? Bug fixes are the user's problem, so why should I have to pay for it?

To expand on shagie's answer, vi is a separate utility except when it's not (f.g. Linux vi is usually a minimal vim build running in vi-compatible mode). For a more pure taste of vi, install nvi or use vi on *BSD.

Note for mobile users: you can setup quassel server to connect to IRC and use the quassel client on your phone. The quassel server acts as an intermediary that keeps the IRC connection stable.

I thought of OpenBSD too since it includes Perl modules for OpenBSD::Pledge and OpenBSD::Unveil. Now I'm wondering if I can get something to work where these are used before importing CPAN modules to reduce the damage of potentially hostile modules.

To add to this, it's designed to work in conjunction with small programs. You don't write everything using bash (or whatever shell) built-ins. It will feel like a crappier Perl. If there is some part of your script where you're struggling to use an existing tool (f.g. built-ins, system utils), write your own small program to handle that part of the stream and add it in to your pipe. Since shell is a REPL, you get instant feedback and you'll know if it's working properly.

It's also important to learn your system's environment too. This is your "standard library", and it's why POSIX compatibility is important. You will feel shell is limited if you don't learn how to use the system utilities with shell (or if your target system has common utilities missing).

As an example of flexibility, you can use shell and system utilities in combination with CGI and a basic web server to send and receive text messages on an Android phone with termux. Similar to a KDE Connect or Apple's iMessage.

It works quite well. There is a lack of precision trying to drag the cursor around on Android, which is made worse on the <$100 quality devices. Using vim's keyboard commands, I can precisely edit text far easier than anything else I have used on a phone. I never used emacs because I'm not a fan of chords, and this is amplified on the phone. However, people who swipe text may like emacs chords over vim's commands and modes.

Neither would the 8 bit CPU you are salvaging. You don't even really need it anyways, you could get away with integer math. You would be running trading algos for bullets and cigarettes in a shanty bazaar.

I just want a 200LX with a bit more RAM, wifi, and a new-ish CPU. As far as I'm concerned, it could run on a Raspberry 0 W. I haven't seen anything new with that Palmtop style of keyboard. It needs both good keys and a decent layout, but everything new I've seen seems to compromise on both.

More support, better support training, and policies that don't handcuff their dispute resolution options (before lawyers get involved). Excellent support, and even taking it on the chin when appropriate, will do more for a business' image than any finely-tuned damage control press release.

You can easily stow a portable solar panel in a hiking bag that can charge your phone and the other accessories. A laptop would have a harder time getting charged, even if it was a Chromebook. Portable battery packs intended for phones would also be easy to stow. Not only do they fit more compactly, but they are light on your weight budget and not as fragile as lightweight laptops.

I've been thinking about something similar. A polyvalent UI with CLI, GUI, and AUI (audible user interface). The AUI could be implemented as a TUI/HTML page (to leverage existing work on screen readers) but designed to be read rather than seen.

As long as you're not messing with memory directly (i.e. dynamic allocation), the OS will clean up after your program exits.

I also like to look at the two and four star reviews. 5 are obviously bought, 1 could just as easily be an irrational customer, and 3 may just be people who feel lukewarm. Well written 2 and 4 star reviews seem to have the greatest number of people attempting to approach the review objectively.

Gambas is the best I have seen for something that feels like VB6. It's Linux only, but it has JIT.

Huh? Just use neocities.org. Even has a built-in editor on the site.

Don't take the following as a critic of your disdain for shell. Your comment reminded me of this:

https://www.gnu.org/software/nosql/4gl.txt

Note to phone users, the formatting works better in landscape.

I don't remember when this was written, but it's an interesting read. It requires a bit different approach, but it is augmented well by 3GL programs. Commands that don't exist can be written in shell, Python, C, Rust, etc. I usually use a shell first approach, start the command as a shell script and rewrite it in something else if necessary. It is quite flexible and extensible if you work within it's data types (probably the wrong term, but f.g. files and text streams).

I use espeak and it works on Termux too.

You don't get the market Nintendo is catering at all. I have bought 3 Switches because the games are fun and they have age appropriate content. I will probably buy another two more Switches by the end of the year, but not a single PS5 or Xbox One *.

That's why I bought and played Breath of the Wild. It sure beats an experience like GTA V's single player where I can't seem to go five minutes without some NPC talking. I dreaded everytime I opened a car door.

Or living in a rural area with crappy Internet. I've installed wireless Internet in places where the people are wealthy but could only get a crappy DSL line. An Internet connected app, web or native, was a pain in the butt to use.

Mobile users can have problems too. I still come across dead zones in network coverage that render some apps useless and I'm not even outside of town.

Thanks to flat design, Athena widgets are now a minimalist widget set. Using X resources, you can even personalize and theme your apps.

This is the only response necessary for those demanding free support. You can even shorten it:

"AS IS"

TUIs are better for visual representation and interaction on resource constrained systems. Just keep using the CLI if that's what you want.

I'm not sure why you need HTTP or dbus for control. Just use stdin and stdout. For example:

  cat << EOF | my-cli-music-player
  enqueue album:40-oz-to-freedom
  enqueue album:steal-your-face
  randomize
  play 10
  wait 20s
  ...
  EOF

  cat << EOF | dc | espeak
  100 k 22 7 / p
  EOF

No problem, stuff happens. :)

"Why BSD?" wasn't the question. I have already read a lot of the arguments about that particular question. If I were to generalize my question to ladyanita22, it would be, "Why would you want to run a BSD for Gnome, Wayland, Steam/Proton, and other generally Linux software, instead of running it directly on Linux where it is supported best?"

What does the user get out of running a BSD for Linux software that they can't get out of Linux? If you prefer BSD, then why not use software that is better tailored for BSD rather than software that requires porting and changing or removing all of the Linux specific bits?

How's that?

Cross-compilation would be nice. I have used asyncio to allow the GUI to run in the main thread but have other processing done separately. I am not sure I understand why you are getting a new window on Windows. Were you trying to create new windows separate from the thread the root window is in?

Why do you want to run a BSD?

I am not particularly interested in the above, except power management and wifi. I am trying GhostBSD as an alternative specifically because I am not interested in Gnome, Wayland, or Steam. I don't hate them, just don't care. I may go simpler and just use CTWM and cobble together a desktop environment.

I am genuinely curious what running these things on a BSD gets you that you can't get with Linux. Using a mainstream distro (like Debian or Fedora) gets you this without hassle.

I have goofed around a little bit with GUI programming for Go. Fyne is incomplete, but I did find it relatively simple to slap something together. It may turn out to be a good cross-platform toolkit in the future, but I didn't like the requirement on OpenGL. Not my choice, but the utility needed to run on Windows 7 and I don't like updating drivers on the machine (risky).

Webview works ok, and you can get a lightweight Electron-like thing going that uses your existing browser. This reduces binary size greatly. I didn't try any JavaScript frameworks with it, just vanilla JS. You can bidirectional bind between JavaScript and Go too.

What I liked the most was gothic, since Tk looks good enough and runs on Windows 7 easily. Gothic is a Tk binding for Go that is quite simple to use. However, you are writing the GUI in Tk now, and you will either love it or hate it. I do have a bias for Tcl, so it was appreciated.

My use case scenario was supporting an old machine running Windows 7 with mediocre video. I ended up just using Tcl/Tk without Go since it was simpler and reduced a layer (Tcl->Go->C). When it comes to writing small and/or inhouse stuff, I found it easy and fast to just slap out a Tcl/Tk app and call it a day. I can develop on my Linux/BSD box and then just Windows specific bits if necessary and it usually Just Works(tm).

Oh, it should be noted that Python + Tkinter is a decent alternative for those of you needing executables. Pyinstaller is basically a "one-click" and works with bundling Tkinter. Roy Keene has done good work putting together kitcreator for Tcl, but pyinstaller is simpler if you don't understand the magic.

This is exactly why I never bothered. Combine that with the fact users can pay $0 and then come to GitHub to complain (i.e. create a support burden), I figured it wasn't the best option for a solo developer to build a business model on.

It would be more interesting if there was more flexibility in the monetization. Options for a minimum price + pay more per seat (for integration with some corporate provisioning software), subscription pricing, one time price + either support subscription or support "piecework" (like bug bounties or developer consultation), and invoicing integration.