PDA as "X terminal"

Meh. As someone who prefers Linux to Windows I already have a hard enough time finding software to do the things I want to do. Switching over to either of Linux's less popular cousins would seem to only aggravate the problem.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

No doubt. Linux offers much in the way of device support which was lagging in the 'BSDs, but that has changed lately, and most applications which run on Linux will also run on 'BSD, and they are likely to have ports or packages.

Of course, it depends upon what you want to do ...

FreeBSD may be less popular than Linux amoung users, but it is in no way a "lesser" OS, and PC-BSD (based upon FreeBSD) is rapidly becoming my favourite desktop over Ubuntu, Suse, Debian, etc. Full support for Flash, right out of the box, and a choice of desktop (this improves in the next release, because PC-BSD is heavily KDE slanted just now -- and while I prefer Gnome to KDE, I'm looking closely at Enlightenment 17 which seems to be nearing release FINALLY!).

Cheers, Rob.

I can try it on the beta site (40 "clients") and see just what sort of a resource hog it is. I am pretty sure it will choke at 40 -- and definitely at 1,200 :-/

The PDA is only "active" when it is updating a display. I suspect battery life won't be affected -- in significant terms -- by the difference in computational load for one "communication protocol" vs. another. I.e., the time spent sleeping over the course of an 8 hour shift will be virtually the same (?).

Having to move to a server *farm* (when you run out of CPU and/or bandwidth) really complicates the design and maintenance of the

*system* (what happens if *a* server goes down -- how do you migrate those active clients to another server, how do you manage the configuration, backups, etc.).

As you add clients, this becomes more and more inevitable. If, OTOH, each client brings horsepower with it, then you can scale more gracefully on a given server size.

This will be *really* easy to test! Set swap to 0 and load clients until it panics. I can probably try that with the existing application and just hook up 40 "PC's" to act as those 40 clients. Assuming xrdp ports cleanly to NBSD...

Gnu Herd runs on PDAs?

--
Grant Edwards               grant.b.edwards        Yow! But was he mature
                                  at               enough last night at the
                              gmail.com            lesbian masquerade?

"Weenyism"? :>

I suspect most folks aren't aware of the origins/differences, etc. (AT&T vs. the BSD morph)

I like the T3 as a reasonably compact PDA. But, in this sort of application, it loses out to the hx4700 ergonomically as well as architecturally.

Thanks. Yes, I'd already been there. But, it's all Linux-centric. I suppose I could peek in the Linux kernels for anything that isn't supported in NBSD and just port the differences without violating the letter of the law (seems like everyone copies everyone else in the OSS OS camps -- just different implementations)

Ouch! I have a friend who used to do the VAX builds for one of the camps. Had a serious impact on his electric bill, I'm sure! (and couldn't have been fun in our hot weather!)

TdR seems to be at the center of most of the disharmony in the *BSD camps. No personal experience with him so I can't comment other than "coincidental observations". IMO, disorder (in *BSD as well as *Linux) is the only thing that keeps MS in command of the market. You can't develop a real product with no *imposed* sense of direction :-/

A friend had, long ago, suggested using the original Palms as UI's. I.e., treat them as *terminals* accessed via the serial port on their docking connector. Seemed a good idea, at the time. Of course, they have progressed far beyond that in terms of i/f's (witness my desire to use them as GUIs with their attendant higher bandwidth and processing requirements).

I think most handhelds are more useful *not* repurposed to some other OS. Simply because the lack of appropriate applications to run on them (I don't believe you can port a desktop application to a handheld without giving serious reconsideration to the entire UI as the physical environment is so very different!).

Again, I think you will find that the sorts of applications that you might want to have available to you just won't "fit" with the tablet's ergonomics.

By way of example, note how hard it is to play/port most *common* games to something like an iPad -- the "controls" are just "wrong". Wanna run gdb(1) on something without a *real* keyboard? Perhaps...

*if* you redesign the UI to exploit the sorts of controls that are more viable on the tablet... :-(

This is very evident if you deal with designing for disabilities. Many in that "community" profess that it "doesn't cost anything" (more) to design for disabilities. But, this just isn't realistic. Forget the fact that most folks ("designers") are ignorant of the multitude of different "disabilities" and the consequences of each... it's just not *practical* to design "greatest common divisor" interfaces to address everyone's shared/common capabilities.

As a thought experiment, consider how you would *actually* interact with the applications that you would like to port to that handheld (tablet, etc.). You might later find that you are disappointed in the utility of those tools :-/

I make no bones about using Windows-based tools for much of the "activities" related to work. I'm not going to build *a* particular (obsolete) kernel just for the *privilege* of running AutoCAD on a non-windows platform. Why? It works quite well where it is. With a wide variety of peripherals (as opposed to a few that "kindof" work with it). Ditto DTP, PCB, schematic, multimedia authoring, etc. etc. etc. I use my BSD boxes to write most of my code. My databases are hosted there. As is my web server, etc.

OTOH, I typically interact with those things from a Windows front end! I am not excited about having to build 30 damn libraries just to have a GUI toolkit available for a utility to run *under* BSD -- when the same utility already runs reliably under Windows (and I can install it in a few minutes!).

I rely on the UN*X boxen for verifying my devices "play nicely" with other network facilities. MS has bastardized so many protocols that they aren't worth supporting -- especially when they keep

*changing*! If MS had developed DNS (WINS?), everyone on the planet would have to rewrite their URLs yearly as MS decided to make things case sensitive, then change ':' to ';', then list domain components in reverse order (e.g., com.google), then switch to UTF16 encoding for everything, etc.

They're all just tools. Pick the ones that best suit what needs to be done.

Amusing that you don't see carpenters becoming religious zealots over the brand of *hammer* they use! :-/

I got on the NBSD bandwagon with 0.8 in '92 or '93 (? memory for this sort of detail fades after a few decades :> ). Then, quickly moved to FBSD 0.9 (which was contemoraneous with NBSD 0.8 but the FBSD folks wanted to look like they were "ahead" :-/ ) as the x86 port of FBSD was more stable than NBSD's (since FBSD *only* supported x86 while NBSD had many ports).

[ read "port" as "platform" soas not to confuse it with FBSD's early notion of "port" vs. "package" vs. "apps"]

But, at around 2.2, FBSD started trying to be a Linux-wannabe (concentrating on new features with little regard for making existing features *work*!) so I jumped back to a more mature NBSD. Which is where I've stayed, since.

[I have looked at OBSD from time to time but never saw any real reason to go that route over NBSD -- the three camps freely steal/share code/ideas so why switch if you don't have to? :> ]

I think there has been some politics in the NBSD camp in recent years (in-fighting?) so my next upgrade might find me reevaluating that decision, again. :<

Any comments you can add in that regard?

But if you're running the application on the server, you run into the same issues sooner or later. Performing the rendering on the server will move the cut-off point (by how much depends upon how much of it you can push onto the GPU).

I wasn't suggesting running an X server per terminal. If the entire stack is custom code, I'd rather have one normal X server for use as a rendering slave, and each instance of the application mangage its own frame buffer (e.g. OpenGL FBO, GLX pixmap or X pixmap) and RFB/RDP connection, with one copy of fonts, icons etc shared between all clients.

If you want a more vanilla X environment, you could give each terminal a normal window and use a compositing manager, so that each window has a dedicated framebuffer and you don't have to worry about fitting the windows onto the screen.

There's already a VNC-like package which is implemented as a compositing manager on the application side, so that each window gets its own native window on the terminal side rather than one big window for the desktop. But I have forgotten what it's called.

Depends on what you run on the PDA of course, but I don't see why not. Assuming you can put Linux on the PDA, you just run NetSurf (or whatever) in your init script. Then disable any keypresses to get into boot menus etc.

"Browser" and "never crashes"? Hmm, don't think I've ever seen one of those ;-)

That sounds like VNC... you don't have to use any particular windowing system over VNC, there are libraries to push drawing primitives through it. So you just say 'rectangle here', 'rectangle there', getting back 'mouse click here' etc, and it's up to you to render pixels in the rectangles, deal with UI events etc.

Theo

"Xpra"

I was trying to avoid reflashing the PDAs. Of course, if I consider everything as "fair game", then I can make the PDA do *exactly* what I want/need.

Yeah, Doug's initial comment re: X being a heavyweight process pales when you look at all the cruft in a typical browser! E.g., In 25 years, I've never seen an X terminal crash; OTOH, I can do that pretty easily with a browser in 25 *minutes* :-/

The X core protocol does this. Extensions to it help reduce network traffic at the expense of client side caching, etc.

I think a *smart* use of the protocol would let me preload resources into the client -- since I *know* a priori what the "client's" capabilities will be -- and eleminate a good deal of traffic without having to write any code on the "client" side (e.g., send all the pixmaps over en masse and store them on the X server; then call them up explicitly from the application).

This has the advantage of getting me out of the "display server" business entirely!