Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: nitram on November 29, 2016, 11:09:35 AM
-
Greetings, heard Juanito is already working on TC8, just got TC7 running nice :)
Will there be an input thread for suggestions or wishlist items before release or should i post some items here? Something i expressed to Jason earlier also holds true for TC base, if the volunteer developers are burning out maybe a longer period between major releases would be beneficial. I would rather see TC around in 10 years than the main players burn out and leave. Some users are cutting edge, personally a new release every 3 years or so would be good enough.
-
Well, I'm looking forward to an updated graphics stack, or whatever might fix the broken i945 drivers /dri issues. So a new release would be preferable for me rather than going back to 6.x. Other than that, if things just work, I don't care about the version number.
I personally don't use cutting edge hardware so I don't require the newest kernel, but there might be users that do. Core advertises itself to use a recent kernel, so the period new versions are shipped wouldn't be expected to take too long by many, I suppose.
-
I rely on TC for business reasons, and will be more than happy to help alleviate some of the workload.
We have access to some pretty beefy servers which can be used for building/compiling stuff.
I think the biggest concern regarding slower releases is the lack of security updates. With each TC release, we're relieved that at least some old local security vulnerabilities are patched, but new ones always surface eventually. I would be fine with a slower major release cycle if minor updates were more frequent (ex: monthly or quarterly).
-
If you need timely security updates, it would be best to use a distro that offers paid support, such as RHEL.
-
Well, I'm looking forward to an updated graphics stack, or whatever might fix the broken i945 drivers /dri issues.
Then compile your own kernel, that's no good reason to upgrade *everything*
As this is already in the "talk" section i can tell some nice upgrade story:
In order to upgrade my tinycorelinux router (just routes stuff through some secure tunnel to a server with fixed IPv4 address which will NAT everything and put it into the real internet) from tc4 to tc7 I recently copied the mydata.tgz and the onboot.lst to a vm on an other machine running the latest iso. There i tried to install the same packages (had to drop some or rename some package names that had changed in the meantime). When these steps were successful I created a second tunnel to the actual NAT router and did a manual live failover by unplugging the cable to the old router, deleting it's return route from the NAT router and adding the router ip to the new machine. When I saw that everything is still working and all TCP connections have indeed recovered I copied the tce dir back to the original machine, rebooted the machine and plugged out the new, plugged in the old router.
All in all it was way too easy, I had expected some bigger complication to arise from the upgrade, like normally is the case on all those ubuntus. Considering this I actually wasted a lot of time, just to prepare for the worst, but which didn't happen. I blame tinycore.
-
I'd be interested to know in what kernel version this bug is definitively fixed since there seems to be some confusion over the issue.
-
Question:
Why do you even continue developing Tiny Core Linux?
Wouldn't it make more sense to shift all the manpower over to dCore (http://wiki.tinycorelinux.net/dcore:welcome) instead?
AFAICT, dCore would also alleviate those update issues, since dCore can make use of the huge Debian/Ubuntu repositories, so one wouldn't have to rely on Juanito etc. only to compile new software (no offense, just saying).
-
Question:
Why do you even continue developing Tiny Core Linux?
Wouldn't it make more sense to shift all the manpower over to dCore (http://wiki.tinycorelinux.net/dcore:welcome) instead?
AFAICT, dCore would also alleviate those update issues, since dCore can make use of the huge Debian/Ubuntu repositories, so one wouldn't have to rely on Juanito etc. only to compile new software (no offense, just saying).
And next step to kill dCore and close site, forum saying why to waste time for dCore when there are so many other systems and even TC is not developed anymore.
-
Let me quote @roberts:
Not sure of your position... But I see it as another advantage.
It is quite simple to import versus asking and waiting for a community member to recompile for relocation on current native Core, unless, perhaps, you are the type that perfers to compile everything.
Also on native Core to implement a security upgrade not only depends on a community member being available, it may also lead to breakage.
This versus the vast community of Debian developers who maintain Debian.
;)
-
Hi pq5190362. TC and dCore are uniquely different, to say one is better than the other would not be accurate. They both have advantages and disadvantages. Better question, why are there 8 replies and nobody responded to my original question :)
...just joking, will add my 2-bits later.
-
Better question, why are there 8 replies and nobody responded to my original question :)
You had expressed your concerns about main developers possibly burning out and leaving.
They're probably less likely to burn out if they wouldn't have to compile every single package themselves and instead would focus on dCore and re-use the packages from Debian/Ubuntu instead of compiling them themselves, right?
-
If you need timely security updates, it would be best to use a distro that offers paid support, such as RHEL.
Curaga,
I offered to help and support TinyCore, why would you push me to another distro? Perhaps you read my comment as a complaint, but it was meant as a suggestion for improvement with which I can definitely help.
-
I've been running old versions of tinycorelinux for long times without any security problems.
Yes, tinycorelinux itself doesn't promise you anything regarding security, but you can create your own levels of security if you know what you're doing.
aw: there is no security, all you will get is liabilities. if that's what you need get rhel.
-
just want to thank everyone for making and maintaining both tinycore and dcore
both have their advantages
and both are masterpieces
i use them both and merge them
make tcz/sce that work on both
turn sce into tcz so that you can download it from debian and use it in tinycore
use the same home and tce folders for both tinycore and dcore
working on adding boot codes and merging tc-config to let you choose your script path
so that i can merge the cores
anyway great fun
thanks again
and please don't burn out
i hope you know what a great gem you guys have here
ulfr
-
Well, I'm looking forward to an updated graphics stack, or whatever might fix the broken i945 drivers /dri issues.
Then compile your own kernel, that's no good reason to upgrade *everything*
I think it is, as I want to be able to submit extensions. If it would only be the kernel then I could still do so. But if possible fixes would be X related, that would be a potential incompatibility concern for me which I cba of due to lack of expertise.
-
Well, I'm looking forward to an updated graphics stack, or whatever might fix the broken i945 drivers /dri issues.
Maybe you could use dCore-xenial and use the Oibaf PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers), which always has the latest git versions of Mesa/DDX. Or does that PPA not work on dCore-xenial? According to the Wiki, PPAs should work: http://wiki.tinycorelinux.net/dcore:ppa-add_command
-
I offered to help and support TinyCore, why would you push me to another distro? Perhaps you read my comment as a complaint, but it was meant as a suggestion for improvement with which I can definitely help.
It's just how I see it, a volunteer distro cannot ever match a paid one for secure servers, etc. Even Debian with its manpower is usually slower than RHEL or Suse.
What's your use case? You mention that local kernel vulnerabilities concern it.
-
What I can say about security is that I'm maintaining Apache, Postgresql, PHP, bind, dhcpd and lighttpd for TC 64 and I'm keeping them current because I need them to be. What I can also say is that putting together a build box isn't a big deal in TC. If security is important to you and you have preferred packages I'm sure the community would appreciate the help. I know a lot of people use TC for real world applications, and we know why we're not using fat distros. TC is more of a community effort than it would appear to be on the surface. I disagree that the paid distros are more secure. They have way more packages than a server needs so they require more updates. The beauty of TC is that the very small amount of software reduces the attack surface and so security should be easier since so few packages per server would need updating.
My $0.02 input for TC 8: Unify the 32-64 bit installer. The 32-bit installer will work for both if the install paths are tweaked just a little. I posted my solution here a while ago: http://forum.tinycorelinux.net/index.php/topic,19738.msg122475.html#msg122475 (http://forum.tinycorelinux.net/index.php/topic,19738.msg122475.html#msg122475)
-
Maybe you could use dCore-xenial and use the Oibaf PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers), which always has the latest git versions of Mesa/DDX. Or does that PPA not work on dCore-xenial? According to the Wiki, PPAs should work: http://wiki.tinycorelinux.net/dcore:ppa-add_command
ppa works under dCore
-
Forgive this off-topic reply, this thread is now officially off-the-rails. Despite dCore being slightly heavier than TC, my old graphic hardware never worked better in dCore-jessie and stretch, as the required packages are readily available for import to make things work. For me it was Mesa related libraries. Misalf you may want to install dCore-xenial or stretch, test glxgears, SMPlayer or other benchmarking software and see what other imported packages may be required to make it work welll again. If you identify the culprit(s), then just provide the required extensions for TC8.
-
Doesn't seem like a dep related thing though. More like a X / driver related thing. I've bloated everything out of Core that I could think of but there is no way to make 3d work. Would be a shame if 6.x would be the last release to provide 3d on crappy old intel integrated graphics.
-
Doesn't seem like a dep related thing though. More like a X / driver related thing. I've bloated everything out of Core that I could think of but there is no way to make 3d work. Would be a shame if 6.x would be the last release to provide 3d on crappy old intel integrated graphics.
Suggestion:
1. Download the ISO of the current daily build of Ubuntu 17.04 Zesty Zapus (which is using Kernel 4.8 at the time of writing this):
Unity version:
http://cdimage.ubuntu.com/daily-live/current/
GNOME version:
http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/
KDE version:
http://cdimage.ubuntu.com/kubuntu/daily-live/current/
2. Burn the ISO to a USB stick
3. Boot from the USB stick into the live OS (i.e. "Try Ubuntu without installing")
4. Check if 3D works
5.1 If it works: Then most likely the Kernel/DRM/Mesa/DDX stuff in Tiny Core Linux is outdated and is causing the issues
5.2 And if it doesn't even work on Ubuntu 17.04: Then maybe you should submit the issue on the freedesktop.org upstream issue tracker with setting Product to DRI via https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and setting Component to DRM/Intel
6. Let us know about the outcome ;)
-
I'm reasonably sure that the problem is the kernel driver
-
May the inclusion of i915 to gallium provide a useful fallback, in case there won't be any improvements or fixes for intel gen3 integrated graphics?
-
Maybe this is answering a different question, but I noticed that if I load xf86-video-vesa and not xf86-video-intel, Xorg-7.7 uses the modesetting driver and I don't get the intel kernel driver errors.
Did you try that?
-
but I noticed that if I load xf86-video-vesa and not xf86-video-intel, Xorg-7.7 uses the modesetting driver
You don't need to install any xf86-video-* DDX at all to land on xf86-video-modesetting.
As already discussed in another thread (http://forum.tinycorelinux.net/index.php/topic,20191.0.html), xf86-video-modesetting is included in xorg-server now, so it will automatically be used if no other xf86-video-* DDX is installed.
xf86-video-modesetting (which defaults to DRI3 (https://bugs.freedesktop.org/show_bug.cgi?id=98875) and uses Glamor for acceleration) + Compton (http://forum.tinycorelinux.net/index.php/topic,20590.0.html) is working very well on Intel hardware by the way, even better than xf86-video-intel.
As suggested by AMD employees, Compton runs well with the following options:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/911776-amdgpu-radeon-ddx-updated-better-2d-performance-tear-free-dri3-default/page5
-
Yes, I tried modesetting. I have to explicitly specify it via xorg.conf though.
Anyhow, it's terribly slow.
nitram informed me that the gallium driver was compiled without support for i915
--with-gallium-drivers="nouveau,r300,r600,radeonsi,svga,swrast,[swr]"
For me, all this is quite puzzling. That's why I'm asking if it would make any sense to add support for i915.
Of course, the intel driver would be preferable for me if it will work in TC 8.
-
It's just being removed? You don't want to use it, it never reached production quality.
http://www.phoronix.com/scan.php?page=news_item&px=Intel-ILO-Gallium3D-Dropping
The official Intel driver is the non-gallium one.
-
I have seen this thread today, and I have an observation.
pq5190362 - Please don't engage in Core versus dCore, I don't encourage or allow it in the dCore area, and the same goes for the main Core forum. Thank you for your interest in dCore. But main Tinycore/Core is the 'real deal', and I like interest in dCore but dCore is a secondary offering that is based on Core. So there is no competition. Thank everyone for understanding.
-
it's a usual tactic i observe in open source projects: tell all slightly-related projects that the other competing projects are better. they don't look at why or care about any technicalities. they just think they do it for the greater good, that people will get back to work and then make more useful software (i.e. support their crappy feature request), cause all that was needed for greatness is their friendly encouragement.
-
hey
just my 2 cents
tinycore and dcore are the greatest
i cant make them (not a dev) but i can appreciate them
thanks guys
ulfr
-
You don't need to install any xf86-video-* DDX at all to land on xf86-video-modesetting.
As already discussed in another thread (http://forum.tinycorelinux.net/index.php/topic,20191.0.html), xf86-video-modesetting is included in xorg-server now, so it will automatically be used if no other xf86-video-* DDX is installed.
That is not the case with my hardware - if xf86-video-vesa is not loaded, Xorg-7.7 will fail with a "no screens found" message even though it successfully loaded the modesetting driver.
If xf86-video-vesa is loaded, Xorg-7.7 will use the modesetting driver in preference to the vesa driver.
-
"Xorg-7.7 will use the modesetting driver in preference to the vesa driver"
Is there any benefit in this for the user? (just curious) :)
-
Full resolution with non-VESA screens.
-
ah, that's useful :)
-
Full resolution with non-VESA screens.
No, that's not really (the only) benefit.
It's rather:
xf86-video-vesa is not accelerated, whereas xf86-video-modesetting is.
-
Since "Santa" ( ;D ;) ) is currently working on bringing Wayland to Tiny Core Linux (http://forum.tinycorelinux.net/index.php/topic,9021.0.html), maybe it would be a good idea to make a nice and lean Wayland + Weston session the new default for Tiny Core Linux 8.x :).
-
wayland might be an option for corepure64 8.x, but it's not going to be the default...
-
what's the point of wayland?
-
what's the point of wayland?
https://wayland.freedesktop.org/
-
Not sure when TC 8 RC set for release, hope to submit some proposed default configs within the week. Highlights and rational below. Combination of usability, simplicity, performance and cosmetic. Feedback and discussion welcome, thanks.
* Modify /etc/motd, no more subjective image, ascii 'Tiny Core Linux' centered across top, similar to link below. I proposed similar before and no change was deemed necessary. Will only spend time on this if there is interest and commitment from developers.
http://wiki.tinycorelinux.net/_media/dcore:dcorescreenshot:dcore_default_boot.png?cache=
* Modify /etc/.setbackground, move away from Win95 (blue backing) meets Apple (wbar) first impression, recommend:
Change background to medium grey or similar, eg. hsetroot -solid "#979797"
* Modify /etc/skel/.ashrc:
#alias d='dmenu_run &' # Delete, no dmenu since TC4 !
alias tce='cd /etc/sysconfig/tcedir' # 'ce' not intuitive
* Modify /etc/skel/.Xdefaults to:
Aterm*transparent: false
- Not true transparency anyway (ie. tacky), reduces usability, performance hit:
http://forum.tinycorelinux.net/index.php?topic=9021.msg128544#msg128544
Aterm*fading: 100
- Poor default interface, opening side by side terminals should not render unfocused terminal virtually unreadable.
- This made first learning TC much more difficult, took a while to figure out which option was the culprit.
* Modify /root/.Xdefaults to:
Aterm*transparent: false # As ./Xdefaults notes above
Aterm*title: Root Terminal # ID working in root
Aterm*cursorColor: yellow # Cautionary yellow vs 'tc' green
Aterm*fading: 100 # As ./Xdefaults notes above
* Remove following /opt/.xfiletool.lst entries, irrelevant for most installs, default should be software agnostic:
XUL.mfasl #Query outdated Firefox files
XPC.mfasl
.adobe/Flash_Player/AssetCache #Impression TC developers recommend Flash
.macromedia/Flash_Player
.opera/opcache #TC's Opera is seriously outdated
.opera/cache4
-
so, i still use opera, i don't care how seriously it is outdated as long as all the alternatives don't work on low RAM computers.
-
* Modify /etc/skel/.ashrc:
alias tce='cd /etc/sysconfig/tcedir' # 'ce' not intuitive
$ which tce
/usr/bin/tce
$ realpath `which tce-ab`
/usr/bin/tce
"tce" is a CLI app browser script, not exactly a good idea to replace "ce" with "tce" :P
-
Some good points nitram.
Haha, you don't like your owl anymore? :p
Not sure about the style change. The background is the first thing I set (to plain black usually) but that's totally up to each user I'd say. Screenshots of Tiny Core, one can find on the web, show this particular style, and I would stick with it. It's not ugly, even though not very pretty, but it resembles Tiny Core.
"ce" is not intuitive, true. Not sure about a replacement.
The terminal to be set transparent by default (also by FLTK apps hard-coded) really should be ditched. Depending on users settings, one can end up with black text on black background. I can determine exact mismatching settings if needed. I've hex-edited the Apps binary to work-around this issue for myself.
-
Thanks polikuo, spend more time in dCore, forgot about tce-ab. Making a point hiro that TC base configs should be software agnostic whenever possible. There are hundreds of repository extensions, default .xfiletool.lst shouldn't cater to three applications. This ~/.ashrc might be good, instantly navigate critical TC directories, feedback please. The other alternative is 'te' for /tcedir/, this was suggested somewhere before, it's okay but does not cover other frequently accessed directories.
# Quick access to TC configuration directories:
alias o='cd /opt'
alias s='cd /etc/sysconfig'
alias t='cd /etc/sysconfig/tcedir'
-
Hi nitram
Aterm*fading: 100
- Poor default interface, opening side by side terminals should not render unfocused terminal virtually unreadable.
- This made first learning TC much more difficult, took a while to figure out which option was the culprit.
Changing the fading is not necessary. The culprit is the transparency setting. One of its side affects is a washed out
background in a terminal which reduces the contrast with the white text. Open a terminal with some text. Change the
transparency setting in .Xdefaults to false and save the file. Open a second terminal with some text. The second terminal
has a true black background unlike the first terminal. Move the focus back and forth between the two terminals. I think
you'll find the second terminal quite readable even when it does not have focus.
-
it doesn't have to be software agnostic, it is there to filter away the most typical big offenders that fill the home directory with caches that shouldn't be backed up. it is just a line, it's not taking space.
-
Sorry for lengthy post, when there's disagreement tweets lead to misunderstanding.
@hiro, please view the bigger picture. A config file entry isn't benign text, there is data that needs processing. In this case filetool.sh uses tar -X to process each list entry every time backup is run, whether the files exist or not, wasted resources. TC's leanness and purity are it's best features, otherwise we would run bloated pre-configured distributions. Everything is purposely designed to be lean: kernel modules separate, binaries stripped, docs removed, base GUI uses FLTK, etc.
These proposed changes are for base, as they belong in base, which affects piCore and dCore. Keeping a similar base between these is important, provides a consistent and familiar default setup and usage. From the .xfiletool.lst discussion above, piCore doesn't have Flash, neither dCore or piCore have Opera, XUL files appear deprecated by Firefox (https://en.wikipedia.org/wiki/XUL). Of the TC installs that use graphics, probably <10% install Opera. Why should these entries be default checked in every fresh install?
It is doubtful default .xfiletool.lst has been modified for several major TC releases. These entries are likely remnants from whoever was developing at the time, software they used in every setup, not necessarily shared or used by others. For consistency, therefore, the choice is to expand .xfiletool.lst to encompass all software, similar to a custom /etc/hosts file (http://someonewhocares.org/hosts/) or just strip it for purity. Obviously the TC way is to strip it down, especially since a custom pre-configured .xfiletool.lst would require a volunteer to actively manage file entries. If software specific entries are included, then what about .fontconfig, .dbus, .thumbnails, crashes, unwanted sqlite files, etc.. It wouldn't take long for 10 active users with different software to come up with a very long list. Better to just strip down the file and let the user decide.
@Rich, changing the fading is necessary, transparency is only part of the issue. Fading 70 is present default in TC, this means 30% dimmer. This is exactly what the 'fading' option is for:
optional off-focus fading of text - when aterm looses focus its contents is dimmed.
http://www.afterstep.org/aterm.php
-fade amount
This option allows for darkening/lightening of colors when aterm is loosing focus. amount is the %value of the desired brightness, where 100 is the original. if amount is less then 100 - colors will be darkened. if amount is less then 0 or more then 100 - colors will be lightened. Lightening can cause some strange looking effects if applied on bright colors. This option causes aterm to use more colors, as the result it is disabled by default. Use --enable-fading ./configure option to enable it. resource fading.
http://www.afterstep.org/aterm.php
This was tested in TC7 with both a white and black plain background, modify ~./Xdefaults to this:
Aterm*transparent: false
Aterm*fading: 70
Open two Aterms and run 'top' in both, toggle back/forth, obvious difference in text brightness even with transparency disabled. If you are not seeing this, query whether you are using an Aterm version that supports fading, Aterm configuration issue, have monitor set to max brightness, etc. With monitor brightness set to 50%, and fading set to 70 there is an obvious difference between active/non-active Aterms. For me this affects readability, even with corrected vision in a well lit office and non-reflective LCD monitor. If 70 doesn't affect your vision threshold, try 50 or lower.
As a terminal is one of TC's most important tools, this is worth addressing. As a >20 year experienced therapist working with visual and perceptual issues, aging, various environmental settings, workplace health and office ergonomics i feel qualified to make this suggestion. TC should be about usability first, the fading option is an *option* and should not be default.
Thanks.
-
Sorry, provided wrong Aterm man page link and forgot to mention my TC7 install is using Fluxbox, thanks.
https://linux.die.net/man/1/aterm
-
Hi nitram
Open two Aterms and run 'top' in both, toggle back/forth, obvious difference in text brightness even with transparency disabled. If you are not seeing this, ...
I never said there was no difference in text brightness when switching focus. I said that disabling transparency results in
higher contrast and that a terminal that has lost focus is now quite readable.
With monitor brightness set to 50%, and fading set to 70 there is an obvious ...
I find bright monitors hard on my eyes. My monitors brightness is set to 40% and fading is at the default setting of 70.
-
Hi Rich.
Thanks for reiterating, got it, you notice the difference but for you it is 'quite readable'. As mentioned earlier, these recommendations are partly to improve usability. From my experience, the default interface of opening side by side Aterms rendered the unfocused terminal virtually unreadable, making it difficult to first learn TC with numerous terminals. So when you say 'changing the fading is not necessary', despite my report of having a 'virtually unreadable' terminal, you are discounting the needs of others. This may not be intentional but that is, in fact, what is happening.
Fortunately your visual threshold is better than mine. Maybe you have better visual acuity, larger monitor, larger or sharper fonts, crisper image. What i am saying is the default didn't work for me in a reasonable environment with reasonable equipment, so it is likely the default won't work well for some others. For me the threshold is 80, that's still 'quite readable'. When i change fading to 90 the difference between minor fading and no fading is almost unnoticable. Maybe your visual threshold is 60 or 50, don't know.
So what's the magic number? Keep it at 70 because it's okay for Rich but not nitram. What about users who have vision that can't be fully corrected, use TC in less than ideal workplace lighting or from a moving vehicle, have a small or dim monitor, use a CRT monitor with glare. To me the solution is simple. Aterm provides the option, it is optional. The most reasonable choice to improve usability for all users after a fresh installation is to disable fading.
An expert user can freely change the default. A new user doesn't even know where the default config option is located. When i first started TC my favorite 'built-in' terminal was Aterm, as i liked the scrolling and did not yet know shift-page up/down scrolling. Despite the fading issue i persevered and struggled when opening >1 terminal at a time. At first i thought it was FLTK related, then i thought it was just built it, never could find an ~/.aterm/ configuration file or directory. Sorry i'm slow but it took quite a while to discover the actual culprit was ~./Xdefaults -> Aterm*fading.
So of course expert users will say just use or install another terminal. I wanted to learn TC with only the tools provided and, as mentioned, did not know how to scroll using the other 'built in' terminals. It is doubtful my experience is unique, others will likely have a similar experience. Peace out.
-
I think.... [emoji12] it a question of the school you're from. The text within a transparent window is quite clear when it has focus.
No matter how many windows I have open I'm only reading the one in focus. Suits me just fine that other windows are faded, helps my eyes focus on the window with relatively brighter text.
If you're used to panels, then I can see where this is going.. I think all windows are in focus in this case.
I have to say, I've always admired the transparent window background, which I know is not the issue here, just saying.
Sent from my iPhone using Tapatalk
-
I'd just like to know if a kernel version has been settled upon yet?
-
4.8.something, but I've been out of commission for months now, and may be for a month more due to personal reasons.
-
Sorry to here, feel better soon :)
thanks
-
i disagree about short posts, long ones are rarely written well enough to warrant their reading. time is limited.
the terminal or its config is easy enough to change, so i never considered it important enough to suggest a change from transparent default (though i always personally change it cause i need higher contrast).
imo the unstripped versions and documentation are actually so important that i regularly miss it in tinycorelinux. if it was just a matter of having it split into multiple extensions it would be excellent, but that's not how most packages are submitted sadly.
if you argue about tar performance can you please measure first, and properly? perhaps there's a bug in the busybox implementation we should fix.
the user can decide regardless by changing the filelists.
if you want to make your tinycore more lean how about you remove some of the extensions instead of microoptimizing base :D
I agree about the custom hosts file, that would be a welcome addition: right now it's backup always gets overwritten when the hostname is applied iirc. i changed that here, but would be a good idea to allow this by default for everyone i think.
cause you're in that profession: did you ever consider whether one of the devs here might have an astigmatism and thus feels like low contrast is better? :)
-
@coreplayer2, agreed everyone computes differently. Unless you are able to provide an example, however, i can not think of any other software that dims when not in focus. Having functional terminals is important in TC, especially after a fresh install and it's one of the only tools available. I can tile FLTK editor against any file manager, web browser or other terminal and never need to click focus or alt-tab just to more easily read the contents. Only the window's title bar usually changes to reveal focus, not the actual data. So for users that require a full brightness Aterm beside a file manager or whatever, this is less than ideal as a default setting.
As outlined, the proposed Aterm changes are for out of the box performance, readability and accessibility. Nothing an expert user can't revert in a few seconds if they want transparency or dimming. There is no suggestion to remove any of this great software. Take care.
@hiro, unless the instruction is simple, i also have an opinion on short posts that do not adequately address the subject, posts not punctuated appropriately or do not properly address the reader, individuals who feel their time is more important than that of someone else, etc.
Benchmarking tar is not necessary, computers process lists efficiently. The difference between 5 and 10 .xfiletool.lst entries would be measured in milliseconds. Ample explanation and sound rational was already provided why the extraneous entries should be trimmed. Honestly never thought a minor configuration suggestion would be resisted so fiercely by an experienced user, who is going to customize the list anyway. If it is such a minor change, it begs the question why the resistance. One last reasonable analogy and i can't explain it any further. I live in the north, it's winter, look out my window, it did not snow, the sidewalks are clear, i go out and *shovel* the sidewalk anyway, 1000 of my neighbours do the same thing.
Similar to above, never thought minor config suggestions would lead to accusation of micro-optimizing. We are all here since we enjoy using a system that is open source and accessible. AFAIK users are encouraged to learn, provide feedback, submit extensions and enhancements. Without users there would be no need for the system. The suggestions outlined are well thought out, rational arguments presented. As you know, i'm not an an/out user, make a few complaints and leave. From my past history on this forum with TC and dCore, i believe my intentions are clear. Please respect your fellow forum members, nobody discourages you from expressing your opinions and suggestions.
A developer with astigmatism would have the same challenges as other individuals with impaired vision. Although impaired, people's vision remains relatively static from moment to moment. If the astigmatism was severe, glancing between a file manager or focused bright Aterm and an unfocused dimmed Aterm would likely make one impossible to read, or the other, possibly both. The first thing the individual would need to do is change Aterm settings to ensure focused/unfocused are the same brightness, as suggested, then adjust global monitor brightness and contrast for maximum visibility so all software can properly be visualized. Forum members could then help the user change font size and fore/background colours as required for contrast, but at least the dimming contrast would already be addressed out-of-the-box.
@curaga, hope everything turns out okay whatever hardship you are experiencing, take good care, life is more important than computing.
-
"The difference between 5 and 10 .xfiletool.lst entries would be measured in milliseconds"
prove it.
My resistance is not against the effect you're trying to achieve, but your method of justifying it's need.
-
Sorry hiro, after spending time addressing your poorly thought out 'developer with astigmatism' argument, i'm done jumping through hoops. I've already admitted list processing is fast and there would be a negligible difference between a shorter/longer list. There was other rational for this recommendation, see above if you have time to review, not everything is a timed event.
Fortunately or unfortunately it looks like TC 8 will be on hold for a while. I may submit these suggestions in the near future, although recent interactions with the community have not left many warm fuzzies. Obviously i have no control over whether suggestions are accepted, despite good intentions for a better base. Happy new year all.
-
Milliseconds are admittedly slow in this context, so I didn't realize you were making an argument in my support. I still want hard numbers though. Regardless of your intention of argument. It *is* curious to me.
None of these things is super urgent or important, so I suggest you take it slowly. Don't become personal please.
Good ideas need time to develop, but they can only grow with a good critical thought process. A good rational argument will ultimately lead to persuasion, so I disagree that there is "no control" from your side. Don't pretend I'm not listening or something. Consensus is always my goal.
I hope you can find some warm fuzzy feelings in real life though. Be it still in this year, or in next year :)
-
4.8.something
4.9 is the new LTS Kernel, see:
https://plus.google.com/+gregkroahhartman/posts/DjCWwSo7kqY
So 4.9 probably would be a better choice. Just saying.
-
Yes, but the toolchains are built, so 4.8.x it is.
-
4.9 won't be far enough along, .0 or .1 is not something I want to rely on. It also doesn't matter much what is LTS when the kernel is kept for a release.
-
comparing the existing:
(http://i.imgsafe.org/381cfd095c.png)
..to the proposed:
(http://i.imgsafe.org/381d21de04.png)
Whilst the proposed is easier to read, the existing is still easily readable for me (I use reading glasses) and, subjectively, looks better than the proposal.
-
I thought the proposal was only regarding the fading effect not transparency, fading is most noticeable for folks who use tiled windows.
IMO the existing look is perfect as is and one of the unique traits of tinycore.
I really like the transparency effect and fading helps to find the window in focus.
My vote is no change.
-
This is why a neutral grey background was recommended in the orignal proposal. Most users would likely 'subjectively' prefer a grey background against a black/white terminal than the current blue background.
If discussion has shifted to subjective aesthetics, an ascii 'Tiny Core Linux' motd would likely be voted more pleasing than the current 'owl'.
Aterm transparency on limited hardware causes a visible performance hit, this makes default TC and FLWM appear laggy. The recommendation to disable transparency is based on the assumption that performance should trump aesthetics, a defining characteristic of TC.
Regarding Aterm fading, visual threshold was discussed above and everyone's visual threshold is different. The question isn't whether a terminal is readable enough for you or me specifically, rather 'what would make the terminal the most readable for every new user, even those with more severe visual limitations?'
To be clear, the proposed changes are for default, user can change what they want.
-
obviously we should choose grey on grey to meet in the middle. it will also mean transparency won't reduce the contrast.
i sometimes use my laptop outside in the sun where max. brightness of my screen is quite low compared to surroundings. that's why i normally try to at least maximize contrast.
but tinycore is no turnkey system, so i don't think it's too much to ask of the individual users/admins to adjust to their personal preference (or need).
-
Forgot to mention, good subliminal sales tactic Juanito, cleaner terminal outputs and congruent terminal sizes, displaying pretty Core logo in the 'nice' version :)
In actuality all terminals open to the same default size and FLWM smart places newly opened windows into the corners first, not obscuring the nice Core logo regardless of transparency.
The originally proposed suggestions were meant to be used as a package to provide maximum readability, functionality and performance for all systems while being asthetically pleasing. Not everyone who starts using TC is an expert, it is meant for all potential users to try, therefore not all immediately know how to change defaults. If someone argues no performance hit with transparency, boot up a Pentium III. If someone argues nobody uses this old hardware, i would counter systems like TC are the best for old hardware, last stop before recycling. There is an obvious difference with dimming. If someone argues why all the trouble, defaults need to be set to something so may as well make them efficient and as usable as possible.
I once asked a fellow member why even incremental changes were so difficult, the reply was i need to successfully argue my case and convince the developers. Just digging in and holding up my end, no ill will intended. For the record, the suggested defaults are not all of my preferences, just think they are best defaults for base system. If a developer promised Roberts TC would always be blue or whatever, then of course i would understand. Take care all.
-
Robert used to change the bg color every few releases, it's not set in stone. Me, I fall on the "pretty is fine" end, nice screenshots are good PR, and folks can configure their systems how they like.
-
Thanks for feedback. Changing software for the sake of change never made sense but i believe reasonable rationale was provided. Having said that, IMO a TC8 screenshot that's identical to TC5 would be considered neutral PR: https://en.wikipedia.org/wiki/Tiny_Core_Linux
For the record, the proposed change is not ugly, a pleasant, truly generic blank slate 'toolkit' with full functionality and no performance hit:
(http://i64.tinypic.com/mmdhsh.png)
Nonetheless a decision has been made, thanks for your consideration.
-
Hello Everybody and Happy New Year to all of you,
Regarding transparency, the first change I make with each new release is to take it out sytematically.
It's nice to see the TC logo as a kind of 'watermark', but lacking contrast was disturbing.
For me productivity comes before aesthetics ( eventhough it's very important ), and that's the specialty of TC, (my favorite on every machine I use, specially on my PentiumIII _year 2000!_ that I'm sending from this mail ).
Simplicity+Modularity=Freedom. That is the 'core' of TinyCore...
Regards.
-
Hello Again,
Regarding Aterm's background & text colors, I created a feature ( that I've never seen anywhere by the way) allowing me to 'automatically' have a different couple of colors, with each lauch of Aterm, always preserving contrast between text and its background, and at the same time differentiating one Aterm window from the other. I'ts really productive, and aesthetically interesting, can be tailored to each one's taste if needed.
I don't know if this can be a useful idea for TC users too.
Regards,
-
Just saying:
4.9 won't be far enough along, .0 or .1 is not something I want to rely on.
After your comment I was assuming that Tiny Core Linux 8.x must be right around the corner.
But Kernel 4.9 is already at .4 now (4.9.4) and Tiny Core Linux 8.x has not been released yet.
-
what's the rush, pq5190362?
-
This thread is about 8.x, hiro. So, one would assume that it's okay to discuss 8.x here, hiro.
-
i mean why is it so important to you that the developers take the newest kernel available?
-
Because the kernel is never being updated after release. So might as well go with the latest LTS kernel, especially if the current stable Kernel is going to become the next LTS kernel.
Also, it's not like 4.9 wouldn't have any advantages over 4.8:
http://www.phoronix.com/scan.php?page=article&item=linux-49-features&num=1
-
I don't see what benefit a LTS kernel has for a distribution that doesn't updates the kernel between distribution releases.
-
TC is a toolkit, not a distribution. Everybody welcome to customize it to his/her needs including using a custom kernel without pushing others to do the same.
-
Four stable updates in two weeks is plain scary, far above the usual pace. I would stay away from that version just because of that, it clearly signs it's not stable.
-
Four stable updates in two weeks is plain scary, far above the usual pace. I would stay away from that version just because of that, it clearly signs it's not stable.
Same with the LTS 4.4x, one release per week :( Or in less time.