Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: nick65go on May 12, 2021, 10:25:13 AM
-
The upstream developers are focused on new GUI, like GTK3 (or GTK4), which is OK for integration (library shared) for fast/hungry machines; It is less focus from them on small size programs when x64 machines come with 4/8+ GB RAM.
So I wonder who test/develop new program versions for Xvesa, or based on FLTK?
Of course if you have 1-2 GB RAM then even dinosaurus like libreofice 6.x or firefox 88.x can run on it. I tested this.
Two examples: gnumeric and netsurf. The new versions are gtk3, old versions have gtk2 but with some bugs. I did not see many (if any) new functions in gnumeric from ver 1.10.7 up to 1.12.49. Neither new functions in netsurf from 2.8 to 3.10. And none of them needs graphic acceleration. BTW gnumeric 1.12 (neither abiword 3.0) does not run in Xvesa. I do not expect the new upstream versions to be fltk, or gtk1 or gtk2, even if their interface has just few simple menus/options.
Does these means that FLTK or Xvesa is "dead in water" in the near future, and tinycore will be just like the name-plate says: tiny-core but big-appls? like a human tiny head and a fat body? In the end what does matters is not the individual components (genial them-selfs) but the asambled kernel + programs + libraries.
PS: an asambler-code build Kolibri proved the point of nano kernel + apps. #Joke: even Intel has "linux" in their CPU.
-
I wonder if having an fltk wayland backend might help - wayland seems better/faster than Xorg on piCore
-
The ever-increasing hw power leading to app bloat is a known trend, and not many devs to try buck it. Be the change you want to see ;)
Or to quote Roberts, software does not have an expiration date. If an old version works for your use, why update?
-
Right! I arrived to the point where I would not need to update for a very long time.
Except maybe when internet will make "my" software obsolete; like http -> https, no web-site without javascripts, etc. (so dillo 3.1, opera 9 - 12, firefox 13-50, youtube-dl not working anymore). sic transit gloria mundi ;)
PS: could forum-admin adjust the topic title (spell check: ababndon -> abandon?)
-
Hi nick65go
... PS: could forum-admin adjust the topic title (spell check: ababndon -> abandon?)
Done.
-
youtube-dl not working anymore
Hi, nick65go!
youtube-dl works well... ???
-
I just tried both Netsurf and Gnumeric on Xvesa and both run fine. QUALIFIER: The machine running Xvesa is running DSL (bringing back old memories, anyone?), not Tiny Core - Netsurf and Gnumeric are running on Tiny Core Pure64 on another PC and displaying over the network.
This means that whatever problem is happening with Xvesa on Tiny Core should be fixable, but I don't even use Netsurf (prefer Dillo 3.0.5) or Gnumeric (prefer Siag Spreadsheet), so I'll not rush to look into that myself.
NanoX (https://github.com/ghaerr/microwindows) (AKA Nanowindows) is an interesting lightweight X server alternative. It's a relatively active project compared to TinyX, but because it's not derrived from XFree86 there are compatibility issues that are much more real than TinyX (some programs have little bugs, others won't run at all). However it's particularly targeted at FLTK (I think this is what's used for the DOS port of Dillo, for example), so if most of the programs used are FLTK-based then it might be practical.
I'm surprised that nobody's talked about NanoX here before actually - no results searching the forum. It's more of a replacement for Xfbdev than Xvesa actually, but that's pretty academic.
-
Hi CNK
I just tried both Netsurf and Gnumeric on Xvesa and both run fine. QUALIFIER: The machine running Xvesa is running DSL (bringing back old memories, anyone?), not Tiny Core ...
Are those GTK2 or GTK3 versions of the programs?
... Netsurf and Gnumeric are running on Tiny Core Pure64 on another PC and displaying over the network. ...
That would not be an issue there since Xvesa is 32 bit only.
-
Gnumeric is using GTK3. Netsurf is GTK2 but the extension description says it only works in Xorg.
The PC running Xvesa is 32bit, and that's all that matters with regards to the X server. The programs themselves, communicating with the X server via Xlib, are working with this Xvesa. So there must be something wrong with Xvesa in Tiny Core if they're not working there.
-
Which versions of gnumeric and netsurf are working with Xvesa?
-
Hi, Juanito!
netsurf-gtk3 3.10 works with Xfbdev with "background images" off.
-
Maybe it was my mistake to mix, in the same title, two INDEPENDENT subjects: FLTK (GUI) and Xvesa (X server).
The MAIN point was to focus on small total RAM demand when we run few program in parallel.
It is NOT optimal to simultaneously run aterm (a FLTK terminal) , xmms (a GTK1 audio player), gnumeric (a GTK2 spreadsheet) and abiword (a GTK3 word processor). The point was that almost all programs to use the same GUI: FLTK, or GTK1, or GTK2.
For example, a minimal RAM demand combination run (under qmenu) if we focus on GTK2 was with Xvesa:
- gnumeric gtk2 1.10.17 (from tc 3.x), abiword gtk2 2.8.6 (from tc 4.x), vlc 2.2.1 qt4 (from tc 6.x), netsurf 2.8 gtk2, pacman etc
The next upper step, with GTK3 was:
- gnumeric gtk3 12..49 (from tc 12.x), abiword gtk 3.0 (from tc 12.x), vlc 3.0.11 qt5 (from tc 12.x), netsuft 3.10 GTK3 (from tc 12.x)
So if we try to lower the RAM demand (using FLTK or GTK1 only), then
- dillo 3.1 fltk, mplayer-no-dependency, fluff fltk 1.07, etc
But then we are without javascript, old programs with bugs (or obsolete format): can not navigate most web-sites, can not interchange docs with new M$Office 365 etc
Summary: is (next to) useless to gain few MB for X-sever (Xvesa, Xfb, Xorg) and then loose many MB for programs + all their not shared dependencies (different GUI kit).
-
Hi, nick65go!
The joy of Xvesa and Xfbdev is not only (and I expect not particularly) to save a few MB, but to work everywhere, even without drivers, matching Your graphics hardware. TinyCore is nomadic OS - see home page "About Our Project", that's why TinyX servers are the cornerstones of the whole project in my understanding. So don't worry :)
-
@Juanito
I installed the current versions of those extensions for TC Pure64 especially for that test. netsurf.tcz v. 3.9 (netsurf-gtk3.tcz is only available for x86, so I didn't try that), and gnumeric.tcz v. 1.12.45.
I tested both loading various pages/sheets and generally playing around - no problem displaying via Xvesa in DSL as a remote window. I haven't tried Xvesa in TC because I don't have the current TC release installed on an x86 PC.
@nick65go
Yes, I agree it's a problem. In fact any graphics toolkit could itself be considered bloat, because many programs have been written that use Xlib directly, without a graphics toolkit. Examples include the gv PDF/Postscript viewer, xv image viewer, and the vector image drawing program xfig. That is perhaps the ideal way for programs to work most efficiently with X, but it's difficult, so programmers use graphics toolkits instead. Then unfortunately they tend to pick bloated ones if they don't really care about efficiency themselves.
But then we are without javascript, old programs with bugs (or obsolete format): can not navigate most web-sites, can not interchange docs with new M$Office 365 etc
For what it's worth, there was an FLTK web browser based on Webkit (the browser engine from Apple's Safari web browser) called Fifth (http://fifth-browser.sourceforge.net/). It did Javascript, though my build of it never worked reliably. Also you can export to formats such as RTF and CSV for importing into M$Office, or even old versions of Office file formats which it is backwards compatible with. Of course it is tricky if you can't convince people to send you documents in a suitable format.
Summary: is (next to) useless to gain few MB for X-sever (Xvesa, Xfb, Xorg) and then loose many MB for programs + all their not shared dependencies (different GUI kit).
Except that some people might have Tiny Core installed on a PC that they don't use for browsing websites with Javascript, or opening M$ Office files, etc. They might be able to stick to programs using just one graphics toolkit (or none at all). So the smaller X server options might not be such an insignificant advantage for them. But yes, the range of cases where that applies is narrowing.
-
I installed the current versions of those extensions for TC Pure64 especially for that test. netsurf.tcz v. 3.9 (netsurf-gtk3.tcz is only available for x86, so I didn't try that), and gnumeric.tcz v. 1.12.45.
I tested both loading various pages/sheets and generally playing around - no problem displaying via Xvesa in DSL as a remote window. I haven't tried Xvesa in TC because I don't have the current TC release installed on an x86 PC.
Pure64 extensions will not work with Xvesa?
-
This topic was focused on FLTK. Not specifically to GTK3, or GTK2. Not even for GTK1. The two programs (gnumeric, netsurf) were merely just examples.
The (eventual) bugs for specific programs (like gnumeric not running in whatever type X -server) can be better solved in specific thread/subjects. Mixing too many different things (like locally viewing x86 appls from a remote x86_64 machine) in one subject will not help.
@CNK: yes, I agree to pure x86 apps communicating with X-server (preferable x86, like Xvesa) AND a simple ash shell or fltk interface, for comfort. And yes, DSL (damn small linux) is / was a gold mine for past time hardware. Today I can not buy new hardware without mandatory UEFI (because stupid vendors, bla bla). And for BIOS machine, then only second hand /refurbished (not my choice, I have already too many of them for my taste, accumulating dust because few failing parts - GPU coolers, broken keyboards, bad sectors HDD etc).
I prefer old appls, if they can keep up with the new (bloated) standard, forced on us by "common" people/colleagues/friends.
-
Hi Juanito
Pure64 extensions will not work with Xvesa?
It depends on whether he meant Core64 or Corepure64. Xvesa will run on Core64. Xvesa will not run on Corepure64
since it's 32 bit only.
-
Hi Juanito
Pure64 extensions will not work with Xvesa?
It depends on whether he meant Core64 or Corepure64. Xvesa will run on Core64. Xvesa will not run on Corepure64
since it's 32 bit only.
I obviously didn't make it clear enough that I'm talking about Xvesa running on one PC (PC1: DSL, x86), and Gnumeric/Netsurf running on another PC (PC2: CorePure64, x86_64). PC2 isn't running any X server, the Xorg extension isn't even loaded. See this guide (https://tldp.org/HOWTO/Remote-X-Apps.html) for details about running remote X applications.
I am certain that PC1 is running Xvesa ("$ ps -A | grep Xvesa", also I launch it with some TinyX-specific arguments). It's probably a different version to the Tiny Core extension, but I don't know how to get a version number out of it. With an understanding of how X works (client programs communicating with an X server, either running on the same computer, or remotely over the network), it seems to me that this proves there must be a bug in the Xvesa/TinyX version used by Tiny Core, rather than in the client programs such as Gnumeric and Netsurf.
Anyway, if I find the time I'll burn a live CD for x86 Tiny Core 12 and observe the reported problems with Xvesa on Tiny Core myself. Maybe it depends on the configuration, such as resolution or colour depth, and actually an identical configuration of Xvesa in Tiny Core will work with those allegedly Xorg-only programs too. I'll start a new thread for this then, unless someone else does so first.
-
Well, at least the gtk2 theme issue is not technically a bug in tinyX. DSL tinyX did not support xrender. Ours does, but an earlier version. Some gtk2 themes use a gradient that is not a gradient, but a straight-color line, which is not allowed by the older xrender version. So technically that one is a bug in the gtk2 themes, or maybe an unstated requirement on a newer X server. You can search the forum for the exact error message, saying opcode RENDER etc etc.
I don't know if the mentioned apps are about that or something else, just mentioning.
-
I honestly only have one complaint with the tools in fltk.
The font size.
Nowadays all monitors have high resolutions, lowering the resolution means having a less defined image (because lcd monitors seem to work well only with their maximum resolution).
So tinycore applications for my eyes are unreadable if I don't put my nose 20 cm from the monitor, which makes my visual conditions even worse.
When xfce was around I used alt+mousewhell to zoom, now I try to avoid graphics tools as much as possible.
-
@vinnie: is your complaint ONLY about the "tools" which use FLTK ? So do you talk about TC control-panels (and its applets), and basic appls from default wbar (editor, mount, run) ?
Because FLTK is GUI tool-KIT, and ANY apps can choose its default font (for example: aterm, dillo, flaxPDF, flview, fluff, etc.).
I use just flwm (for desktop-menus) with 1600x900 on a laptop display of 17 inch. Even less resolution for TC in virtual-machines ;)
Is any "global font" setting for fltk preferences?
-
Yes I am referring to tinycore tools, if you know a practical way to enlarge the fonts of their gui, please tell me :-\
-
Use exactly half the resolution of your monitor, and the image will still be sharp. It's only non-integer scaling that gets blurry.
-
Use exactly half the resolution of your monitor, and the image will still be sharp. It's only non-integer scaling that gets blurry.
I haven't:
$xrandr -d :0
HDMI1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 480mm x 270mm
1920x1080 60.00*+ 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 75.02 60.02
1440x900 74.98 59.90
1280x720 60.00 50.00 59.94
1024x768 75.03 60.00
800x600 75.00 60.32
720x576 50.00
720x576i 50.00
720x480 60.00 59.94
720x480i 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
HDMI2 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
The half of 1920x1080 is 960x540
-
In that case, you need to add a custom modeline to your xorg.conf. (can also be added via the xrandr tool, to test at runtime).
Use the cvt tool to calculate the numbers for you.
-
uhm? i am not really expert in these things, but the resolutions supported by a monitor are not already fixed in the monitor? or with this "custom modeline" i create a virtual resolution that being a bisection of the normal one then you can still see sharply?
-
For most monitors, the list is just for convenience, and you can use other resolutions too.
https://wiki.archlinux.org/title/Xrandr
-
Ok, I tried it and it works as you say, the display still looks "sharp" to me looking at the rectangular edges.
gtf 960 540 60 #to know modeline
xrandr --newmode "960x540_60.00" 40.78 960 992 1088 1216 540 541 544 559 -HSync +Vsync
xrandr --addmode HDMI1 "960x540_60.00"
xrandr --output HDMI1 --mode "960x540_60.00" --panning 1920x1080
xrandr -s 1920x1080 #return back
I added panning which is not useful now (you have to reset ratpoison to make it fit) but it was to try to emulate xfce zoom with alt+scroll.
It's almost perfect except that the mouse focus is not followed in the center but you have to move to the edges, this slows down a bit but better than nothing.
Remaining on the theme I tried to do also the negative, for a single window I have not found anything (some say that you can try with xephyr or xnest and start a graphic server inside a window, but it seems too exaggerated) and among other things xcalib is not on tinycore, but xrandr is capable to make it the same (even_if_I_don't_know_if_it's_an_intended_function_, negative values from - 1 invert the colors).
Here's how I binded it on ratpoison (I replaced all spaces with _ because of server error):
bind_less_exec_[[_$(xrandr_--verbose_--current_|_grep_HDMI1_-A5_|_tail_-n1_|_sed_'s/[^0-9.]*//g'|_cut_-d'.'_-f1)_==_1_]]_&&_xrandr_--output_HDMI1_--brightness_-1_||_xrandr_--output_HDMI1_--brightness_1
However, I have the impression that the result is not really good
-
I made the script that toggles the zoom on and off (simply toggles each time you launch).
I hope I've made it generic enough, but if there are things to correct, let me know.
-
Curaga - you are a super-genius! I had NO IDEA you could do a non-standard modeline to a modern computer monitor. Last time I touched modelines was back in the very early glass monitor days. I made a custom modeline exactly half my native resolution, and holy cow, it rocks! The core log was burning a hole in my forehead so I got rid of that. :)
Vinnie - you brought it all back. Created a custom modeline which worked out to the same values you have, and created a file as root with an X11 monitor-section called 5-monitor.conf in /usr/local/share/X11/xorg.conf.d/5-monitor.conf. Added that to the TC backup file list to make sure it stays.
I probably should make a writeup for others who like us, dig the fltk/flwm environment on modern high-res monitors, but their standard values are just too blurry no matter what. Curaga just rocked my world.
Nick - back on topic - I think the main issue is that most consumers aren't really using computers to compute anything, but are just turning them into other things that need flash and sparkle. Multimedia, gaming, and even web-browsing where the underlying code is 90% unnecessary graphics and 10% content - if that.
Sadly, as we know, the browser has gone from it's original intent into an o/s of it's own. Nobody without corporate backing can keep up with all the javascript which is just taking over. Sadly, I think this browser developer just reached a stage of burnout which many devs recognize:
https://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox-and-what-ive.html
Spreadsheets? I have never seen anyone use them for what they were designed for. If anything, they were simply used as electronic graph-paper, or *maybe* sorting a row of data. A bunch of horsepower and resources hogged just to make a lunch-seating chart. :)
Anyway, to each his own. I keep it simple and yes, I do now run TC 64 bit on modern computers - even those that are secure-boot. Details elsewhere here.
The thing that is overlooked is just how fast things are now. We *can* go back to the days of simple sed/grep/awk and just smoke 'em compared to the old days. Even huge text files are so easily crunched, that even flat text files which used to be laughed at compared to dedicated databases, can be pressed into service merely based on speed now.
All I need is a nice looking system for the eyes. But it doesn't have to be total resource hogging eye-candy. Save that for actual computing, not entertainment.
If I need a spreadsheet, I'll whip up the ol' "SC" spreadsheet. Know what I mean?
-
Hi, PDP-8!
Shame on me, I don't know what is the "SC" spreadship :( Is this curable?
-
Hi jazzbiker
See here:
http://tinycorelinux.net/10.x/x86/tcz/sc.tcz.info
-
Wep, thanks Rich! I must have remembered that the first thing to do if I hear about something amazing is to check the presence of "something-amazing.tcz" in the repo :)
-
Hi jazzbiker
... check the presence of "something-amazing.tcz" in the repo :)
Yes, but you may have to check multiple repos. For x86 sc.tcz is present in TC8, 9, and 10 but not TC11 or 12.
It is not in any of the x86_64 repos.
-
On average I used mostly a browser (+PDF reader) and spreadsheets in the last months. (of course with apulse, ffmpeg codecs). Flwm is sufficient for my fixed menus categories (linked on TC start-up). I do not spend more than few minutes per day on FLWM menu (so no icons /fonts) focus.
For me gnumeric (or LibreOffice) is in need, the equivalents for MS-Excel goal-seek, what-if scenarios, solver of linear/ non-linear equations, and dynamic charts. So "SC" is good but not that much. YMMV.
I still dream (and chase) for a 32 bits netsurf-alike with FLTK interface, hoping that its java engine will be enough advanced for online banking etc.
I prefer the 32 bits appls in VM (virtual machines) from TC64 hosts. VM speed is good enough on modern hardware and its security is precious-less. Plus it allows combinations of tc appls [3.x -12.x].
-
Nick - here's something to ponder to make us look at the situation in another direction.
I think the individual developer of TenFourFox who simply can't keep up said it best about part of the reason he is stopping development, and why simple individually developed browsers are a lost cause (but not really - see my comments)
"However, JavaScript is what probably killed TenFourFox quickest. For better or for worse, web browsers' primary role is no longer to view documents; it is to view applications that, by sheer coincidence, sometimes resemble documents."
About half-way down this page:
https://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox-and-what-ive.html
EXACTLY! So no bank is going to recognize Dillo, Fifth, Midori, NetSurf and the like. Their javascript engines have no hope of keeping up with what was once an interactive document viewer, but pages full of javascript applications. Most online pages elsewhere are like this too making them the small independent browser a very nich application.
BUT - what can we do? What I'd say to the dev of the Fifth browser for example, is to totally forget about online access. Keep improving Fifth to be an excellent OFFLINE html document viewer. Heck, now that Curaga cured my resolution problem, even Dillo serves a purpose for those willing to perfect their .dillorc :)
Interestingly enough, Slitaz uses Midori as a default browser, and of course these days is more or less in the same useless online boat as all the rest. But it is still VERY useful for html documents. Heck, they even created an offline spreadsheet with it!
I guess the point here is that while I'm forced to use browsers online that are written to deal with javascript engines which the ONline world has become, there is still a great need for those of us who value a good HTML reader tool!
And of course, doing html markup on one's own can be a very creative way to express yourself and learn something, but the push from the corporate browsers have that big push to make kids learn javascript, json, yadda yadda and push good quality html markup to the side as old fashioned - you *have* to go online kid! Yeah, right - but no.
So that's my dream - Fifth cleaned up, perhaps Midori, and don't worry at all about javascript. Rip that crap out. There's no hope of keeping up with javascript engines, so fuggedabout it, and make Fifth or whatever a rockin HTML viewer for TC. Wish I had the chops to do that myself.
So going off topic, but we have a problem - but a possible solution - to leave the online world to itself, but not abandon a browser's main purpose - to view html documents. Heck, how many know about using a url of "file://" these days?
-
PDP-8, I agree that forced future for java engines (because google market share) is for Web-Kit browsers. Even today fifth can run in a VM (because old open-ssl). Yes, I wish it could be updated by developers. Some browsers (fifth also) can fake their ID agent. The bloated (but free) firefox 90+ is working OK. Shame there is not smaller and good alternative yet for online movies / music.
IMHO we have already in TC all the tools for offline viewers (html 4.x, pdf, text, images, audio/video, etc).
As for HTML editors, in the past I learned in few hours the near 40 tag-types to build a html page from inside of a text editor. But I do not publish web-pages, so AbiWord doc exported as pdf is enough for me. Anyway in TC there are already productive web-editors, if you search for them.
-
I'm with ya, although the kludges we used to do a decade ago by fooling browsers simply won't cut it any more. At least not on a large scale.
That's why I'm of the mind to just rip out that cancerous javascript support, and if a site doesn't work - well better to have it just balk and refuse to work, than work poorly and tax a dev to death trying to support the moving javascript goalposts.
For that, we are forced to run the big 2 or three. Ok fine, I'll do my taxes, banking and so forth with those. But for smaller local or intra-net work, Dillo Midori Netsurf Fifth would be just fine - if the dev is willing to throw up a warning banner:
SITE NOT SUPPORTED
Rather than work poorly with it. This kind of delineates the modern online sites that are mostly javascript programs, rather than markup, than those that are mostly markup and no javascript at all which are a pleasure to use. :)
Makes for a smaller binary, less resources, and the initial objective of what a browser is for - static or limited document interaction can be obtained.
I think that's the crux of it. The definition of a browser has changed.
That being said, I'm rockin Dillo-xft nicely, although I'd prefer a more classic Midori-like experience for the locally generated or javascript-less pages. I'd love to rip Midori apart, remove any cancerous javascript, ad blockers and all that online crap since I'm not going to use it for major online work anyway. Oh well...