Modern 486

when was the last time you tried something like ubuntu, 15 years ago?

You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU, because Windows is what they know and it works very well for them.

Here's an example. Everyone knows how to download an app from the web. Click the download link and run the file that shows up. Done.

Under Linux... well, uh, sudo apt get something? I only know that from using an rPi. Does Linux have automatic installation from a web site link? I dunno. Most other people don't either. It's not about whether it is easy or not. It's about what people know about it. Most people don't even know the name Linux, thinking you mean that character from Peanuts.

Most people who would want to have a music server or a file server know how to do things under Windows. They can find software on the web, open source or not, download and install it and get something to work. I remember using Win2K and finding a really useful web site on networking, World Of Windows Networking, WOWN. Someone bought the site and ruined it. :( But I had a home network up and running like clockwork. I struggled mightily to do the same thing with the rPi. Heck, just finding out how to run a terminal emulation that would support REPL with file download was no picnic. I got it done eventually, but I would need to do the research again as I don't remember the many complications and tricks I had to pull off to get it to work. Or, on a Windows box, I can just use a remote desktop, done.

I suppose I could run a remote desktop so I can operate the rPi from the laptop, maybe? Again, I don't know and it would take a bunch of research.

Is this all out of date?

yes

Well, at least one part is not out of date. The fact that people know Windows and not Linux. So any product build that supports Windows has a ready base of Windows users compared to the much smaller market for Linux.

That's not changing anytime soon.

On a sunny day (Fri, 11 Mar 2022 10:16:00 -0800 (PST)) it happened Rick C snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

Well you could read - and ask in comp.sys.raspbery-pi But google will tell you in a seoond, I use it all the time.

All these thing you just mentioned exist for Pi That said I wrote most of my own, from this newsreader to media player / music center to video stuff. A LOT more - email client, irc client, navigtion program, some is on my website In Debian (variant of that is raspi OS) apt-get install will install things for you. I run and program raspies all the time via SSH from my laptop as the keyboard is faster than the other wireless ones I have here on the table connected to the raspberries. I do have a 5 channel HDMI switch on a big monitor to select raspis or security cameras or TV... But those raspies are so fast even via ssh I can just watch video too that way.

Home network? 3 8 port switches here, everything wired:

And, if you look close you can see several RTL-SDR USB sticks and antennas. Everything talks to everything else. And that in only downstairs in the back, upstairs is the soldering station and a big PC (seldom used these day). The black PC is no longer used... Its what you make of it. This is a triple ssh example:

Scripts is the solution to everything so you do not have to remember every detail of all the thousands of commands zsh is a much more pleasant shell to use than bash at least for sysadmins.

Rick C snipped-for-privacy@gmail.com wrote in news: snipped-for-privacy@googlegroups.com:

You left out the word "most" or even "some".

MOST WINDOWS USERS

All caps boy. Crazy Mr. All caps boy.

The conversation is here. I suppose you can call this a conversation.

No, little is found through a web search in a "second". It often take many minutes or even hours to wade through the ever increasing dross to find a topic you are looking for. I was just trying to find the market cost of lithium carbonate and it brought up many pages telling me how great lithium batteries are or what's going on with the latest lithium powered gadget, etc. God forbid you use a search term that is in the title of a song or movie, you'll never get past that.

I don't really care what is available for Linux... well, not at the moment, although this conversation is making me want to fire up the rPi and pickup where I left off a few years ago.

My point is there is a market for people who would like to do some of the things you did, but using Windows because that's what they know. Why swim upstream and learn a new OS? Not everyone is a geek or wants to learn all the gory details of how to do the things you can do. I do a print screen by pressing a button on the keyboard, with the ALT key if I only want the window in focus rather than the whole screen. Why would I want to bother to learn "import -screen xgpspc_mon_via_ssh.gif"??? Learn it? I don't even want to type it! Click, click.

This is why people don't use DOS.

and you can do exactly the same in Ubuntu et. al.

printscreen for the whole desktop, alt-printscreen for a window, shift-printscreen for a selectable area

or, just like on windows, you can hit the start/windows key and start typing screenshoot and you get a window with all the settings, what you want to copy, where you want to save it, if you want the pointer hidden etc.

You still aren't grasping the concept. If I'm not a Linux user, (and I'm not, really) I don't know that. If I'm a Windows user, I know how to do it. Why would I want to change?

Windows has actually improved greatly over the last decade or two. It's very stable, easy to use and there are tons and tons of help in figuring out how to get your work done. People may not like the idea of using Microsoft, but it works. I had a problem with LibreOffice the other day and I ended up in an exchange with a couple of the nerds who appear to be developers or something. The bottom line was they blamed it on the file format for MS Office files and said I should use MS Office if I need to share MS Office format files! Ok, if that's the non-Microsoft approach, I'll use Windows and stick with what works for me.

I think you have the wrong REPL. It's really just a way to say an interpretive interface.

It often is done via a serial port interface, often emulated through USB, but can be done with network protocols. It does require a terminal emulator to be running somewhere to provide the user interface to the user.

Yes, as others have told me. I think the scheme I used before was to run a terminal emulator on the laptop using sockets perhaps? But I don't recall how that connection to the rPi was connected to the USB serial cable on the rPi. Somewhere in the process I was trying to use a terminal emulator on the rPi, but that is an alien concept under Linux because a command line is a terminal interface (or so I was repeatedly told)... just not what I needed. I don't remember the details. I just recall it was a huge PITA to get running because of Linux. If I had plugged the serial port into the laptop, it would have been a slam dunk. But I wanted the unit under test to be in another room. Maybe I should have bought a 50 foot serial cable and run the interface at 9600 bps rather than 200,000, or was it 2 Mbps? The speed was fast enough that the screen would blink and was completely rewritten.

In the Forth group some guy is talking about trying to make hardware as easy to interface at a modular level as software. I'd like to make software as easy to interface as hardware.

On a sunny day (Fri, 11 Mar 2022 13:10:53 -0800 (PST)) it happened Rick C snipped-for-privacy@gmail.com wrote in snipped-for-privacy@googlegroups.com:

When [if] you install a standard Rasoi OS you can do the click thing for almost anything. Not much new to learn, just like going to a new supermarket and the first time you find things are in a different place, get used to it fast... I have the GUI too in one of the 9 virtual screens on any system I run.

The advantage of a 'command line' is like going to hardware shop and saying "I need whatever" and the guy will put it in front of you in a second. When you have a million things to chose from a click menu is so silly and slow. And not to mention voice input for the visual disabled, What is it these days? "Siri where .." sort of things. I have voice input on my old PC for teefee Show BBC1 works. I never use it, remote on my cheap HD Chinese sat box is faster and more quiet.

In this world everything has a learning curve, I have been in foreign countries and trying to convey something by pointing or drawing is possible but a difficult way to communicate Learn the language, something US folks seem not to be busy with. Here at high school 4 languages are already required Dutch, French, German, English, and some also have Latin. So I always say: 'My computer speaks English' typing is faster than working through silly menus You can make your own language; by naming the command scripts you write.

Now you could argue that learning is so hard, well then you are dead Life is learning

"He who is nit busy being born is busy dying"

But I like the supermarket that is right next to my neighborhood. I have no reason to drive across town to check out a market that doesn't seem to offer anything I don't have.

No, the guy was very rude to me because I didn't know the proper name of the thing I wanted. It's the long, round, flexible thingy that goes from the pipe under the sink to the little pipe that runs up into the sink. He keeps telling me he can't find any long, round, flexible thingies.

Yes, and trying to figure out the name and details of the one thingy of a million is even harder and slower, in fact, it takes forever because I have to go to another machine that is working to look up the name of the thingy if I can find it even then. Without the Windows machine that is working, I would have zero chance of getting the other machine to do what I want... or even know that I might want to try it.

No learning curve for the things you already know how to use.

We don't interface with other languages much. So very little utility in knowing one of the many, many other languages that might be useful.

Jack of all trades, master of none.

You still fail to grasp the most basic principle involved in this discussion. Perhaps it is a language problem???

No, it's just a matter of you not being able to put yourself in others' positions. If you aren't a nerd, and you already know something about Windows, it will be rare that you will think, "Rather than learn more about Windows, I think I'll learn an entirely different OS I know nothing about". Are we done here? This really has become a pretty silly conversation.

Not really a shell. It's a programming language based on a virtual stack machine. I'm sure you seen those before. The difference this one uses the virtual stack machine as the programming language. No parameter lists, data is pushed onto the stack (or left from previous words) and each word gets its inputs from the stack, leaves outputs on the stack. The fact that it is interpretive is just icing on the cake. It is also compiled, so the best of both worlds.

Yeah, SSH rings a bell. Like I said, it's been years since I ran this from other parts of the house. In my case the rPi was not the client, but an intermediary to provide the serial port to the small MCU target.

Most of that means little to me. Under Windows you just run a terminal emulator program and done.

Minicom rings a bell too. Whatever I used on the rPi was not very full featured. It needs to be able to link the keyboard and screen to the serial port, but also send files to the target for compilation. Forth runs on the target and you send source code over the serial port or other comms channel. Sometimes if the target is more capable, the target has a file system, so can act as the entire development system running an editor. This case was a little TI MCU with maybe 4kB of RAM and some 32 or 64kB of Flash. So the files were edited on the PC or rPi and downloaded for each compile.

Yeah, that's right.

That sounds like what I did, except there's nothing to run on the rPi other than connecting the link from the PC to the serial port to the target. Forth runs on the target. I like Codewright for an editor, so I would have been editing the files on the PC and shooting them down to the target. I seem to recall that was the part I had the most trouble with. Trying to make all this work like it was one pipe between the PC and the target.

Hardware has gotten mostly to the point of interconnecting large blocks called ASICs, much as software has done the same. Both require some amount of glue to make everything play nicely together. When you really need to design digital hardware, that's mostly done in FPGAs, so we are back to software, kinda, sorta.

There is analog hardware, but mostly hardware is inside chips unless you are designing the 1 in 1,000 things that haven't been done a million times before.

CMD is what I use, but the new one is Powershell.

I think the file send was transparent to the rPi. The files are text source code, as if they were being typed at the console. So it is dumped to the SSH pipe from the PC. No protocol needed.

I don't recall. It could have been a n MSP430, or it might have been one of their ARM chips. TI muddied the waters by putting some of the ARMs under the MSP430 moniker because they were "targeted" to similar applications. Stupid marketeers don't understand this makes life harder for engineers causing them to shy away from their parts.

So running a SSH program on the PC would give me a console that is actually the minicom on the rPi? I should try to resurrect this as I may need to use it again. I am living in Puerto Rico and it would be nice to operate a target in the mainland. Other than the need to reset the target when things get really fouled up. That's why I wanted a USB hub that could cut power to individual plugs.. or even the whole hub. Doesn't matter. I just need it to be controllable from the rPi so it can reboot the target. I guess in theory I could tie an output from the rPi to the reset line on the target, but there are times when a power cycle is useful too.

More like,

This is starting to come back to me now. The comms program on the PC gives me a Linux shell, so I can do other things if I want, like toggle the reset line on the target or even the power source.

I'm old school, so I think hardware should be designing in the mind as if it was hardware. The HDL is a necessary evil for implementing it. I was helping a software guy learn HDL and he ended up creating a "Hello, world!" program with a software approach, because he didn't need to optimize anything. You can't argue with success.

What sort of things are you interested in doing in FPGAs?

You are describing quite a common way to arrange things.

I assume your "terminal emulator" on the PC is something like Putty or Tera Term Pro. Both are fine for the purpose. In each case, you will be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based editor such as nano. That works fine for small changes, but is less than ideal for big development. (You can also use vim or emacs - I personally have never liked either, but they are immensely powerful for those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best ways, for development purposes, is not transfer them at all - use network filesystems of some kind. Use Windows shares on your PC and mount the share on the Pi, or have both use a common file server. With a *nix host system you can also use NFS or even sshfs - file share over ssh. (This is less efficient than "real" network file systems, but very easy to set up ad-hoc.) With a Windows development system, standard Windows CIFS sharing is probably the easiest. And you can do it either way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and the Pi, and you can skip the file transfer step.

There's nothing on the rPi to edit. No files live on the rPi. The work is done on the PC talking to the compiler on the target. The rPi is there to connect the target serial port to the network. It's just a pipe. I could use anything for this that runs an OS, including another laptop. I have a netbook running Windows 7, but it is so under powered it can barely run a browser. Good thing I don't need to run a browser on it. I think the mail limitation is the limited memory actually.

The latest rPi is available with 8 GB I believe. Sounding more like a Windows machine every day. I should try booting the netbook under Linux. The screen is rather tiny for my eyes though, but using it remote the screen doesn't matter.

I'm pretty sure I ran something on the rPi that was like a terminal emulator. Is there a way to easily connect the serial port on the rPi to the connection from the PC? I'm trying to remember and it seems like there was a problem that had to do with someone capturing a special keystroke that didn't work out ok. I don't think it had to do with the target as that is strictly a TTY type connection. No need for special keys of any sort. Forth either responds, or you have to reboot the target. I don't recall.