Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: wysiwyg on June 13, 2014, 09:01:21 AM
-
Good morning everyone! I have been working with TC over the past several weeks and have put together a basic system including the ability to watch movies using VLC. Everything seems to be going good (haven't tried 3D yet), but I have run into a problem when adjusting the volume level. If the level is *anything* but 100%, the volume sounds like it's turned to 200%, cracking, and distorted. I should be using alsa (at least that's what's in the onboot.lst file).
Also, and I don't think this has to do with VLC, but the screen saver doesn't get disabled. Every 10 or 15 minutes the screen blacks out. Wiggling the mouse or pressing a key on the keyboard will resume the audio/video. Any help would greatly be appreciated.
Thanks,
Dave
-
Not sure about your volume issue, but I had to explicitly set audio module to ALSA to get sound working in the first place ("Automatic" did not output anything).
[Tools] -> [Preferences] -> Audio -> Output -> Output module: -> "ALSA audio output"
About screen blanking, I'd like to know how to make this automatically, too.
xdg-utils provides scripts for that but doesn't seem to work on it's own or it isn't used by VLC.
Maybe a screensaver deamon needs to be installed?
Currently, I just turn it off when watching a movie.
Off:
xset s off -dpms
On:
xset s 600 600 +dpms
-
Thanks for the info Misalf. If I recall correctly I did set that parameter to ALSA, but I will check tonight to be sure. Something else that I noticed too was that when I use another distro like Linux Mint, the VLC in that OS will allow the volume to be increased to 200% whereas the volume in TC will only allow it to go to 150%. Not that it matters because any setting other than 100% causes the problem. Just not sure if something may be misconfigured somewhere.
Thanks for the tips on turning off the screensaver. I'll work with your code right now, but please keep me posted if you get this figured out!
Thanks,
Dave
-
Strangely, changing volume via GUI behaves differently than using mousewheel in full screen where I can always go up to 200%.
[Tools] -> [Preferences] -> Show settings -> "All" (bottom left)
Interface -> Main interfaces -> Qt -> Maximum Volume displayed -> ...
-
Hmmm that's interesting, I'll take a look at it over the weekend and report back. Thanks again for your help!
Dave
-
I did take a look at the sound setting and I was correct that I did try to set the option value to 'ALSA'. Still a no go... So I looked in the repo and it looks like mplayer made it in there again. I installed it and tried to play a movie, but the sound was failing there too with an error about a missing /dev/dsp file. It looks like the sound card isn't being detected correctly or perhaps a bug in the driver...
Dave
-
Just to add my experiences to this thread because I have a very similar issue with vlc and the volume being so incredibly high that the result has deafening and distorted, with no satisfactory control. Had to rush to the receiver to crank down the volume before the whole neighborhood awoke.
For my volume issue I think vlc needs compiling with support for S/PDIF passthrough, no setting in vlc allowed an adjustment of the volume.
While totem player available in repo for both x86 & x86_64 does not exhibit this issue.
First issue I had.
enabling playback to "ON" on reboot; I found that persistent Alsa settings in a backup did not enable this mixer setting on reboot. Instead i used the following in home/tc/.xsession
amixer -c 0 cset name='IEC958 Playback Switch' on
For now I use totem player
-
Hmm that's interesting coreplayer2. I also noticed that my audio hardware settings for VLC weren't being saved between reboots. I will try installing totem tonight and see if the volume issue persist. I would ultimately like to use mplayer, but it would be nice to have some type of video player in the mean time. :)
Thanks,
Dave
-
If you want hardware setting saved, you need to do a backup. The relevant files need to be included in /opt/.filetool.lst. /home is included by default.
For alsa settings, see the alsa info file.
-
Indeed, following the info file to set and include settings in backup will restore most settings like specific hardware, volume etc etc.
however I found that IEC958 Playback Switch remains off no matter what, this required manually enabling each reboot but was resolved with the above command.
Sent from my iPhone using Tapatalk
-
If you want hardware setting saved, you need to do a backup. The relevant files need to be included in /opt/.filetool.lst. /home is included by default.
For alsa settings, see the alsa info file.
Thanks for the info gerald_clark. Currently I have a permanent home directory that is mounted during the boot process. Shouldn't VLC store configuration settings there (and in turn not have to backup/restore)?
Thanks,
Dave
-
Settings for ALSA are stroed elsewhere, though.
You need to read alsa.tcz.info . Viewable via Apps tool.
-
If you are using the home= boot code you MUST remove home from /opt/.filetool.lst.
Then you need to do a backup so that the /home in the backup does not overwrite files in /home.
-
Settings for ALSA are stroed elsewhere, though.
You need to read alsa.tcz.info . Viewable via Apps tool.
Sound good, I'll take at it!
Thanks,
Dave
-
If you are using the home= boot code you MUST remove home from /opt/.filetool.lst.
Then you need to do a backup so that the /home in the backup does not overwrite files in /home.
I am using the persistent home boot code, so I'll perform these steps as well. Thanks for the tip gerald_clark!
As a side note I was interested in knowing if there was a way to install the packages to a partition instead of using squashfs loopbacks. Is there an advantage to the current way of using packages over a more traditional installation method?
Dave
-
We call that scatter mode, and it is specifically not supported.
Core is designed to install everything fresh at each boot.
You should read the core book and the core concepts page.
http://tinycorelinux.net/book.html
http://tinycorelinux.net/concepts.html
If you want a traditional install, you would be better off with a traditional Linux, not Core.
-
Is there an advantage to the current way of using packages over a more traditional installation method?
Flexibility. Changing onboot.list or tce directory you can have a different "installation", a different system very quickly just after reboot.
Safety. Installation is read-only, you can't destroy it easily.
-
We call that scatter mode, and it is specifically not supported.
Core is designed to install everything fresh at each boot.
You should read the core book and the core concepts page.
http://tinycorelinux.net/book.html
http://tinycorelinux.net/concepts.html
If you want a traditional install, you would be better off with a traditional Linux, not Core.
I do recall seeing scatter mode mentioned in the online book, but it doesn't really address the pro's and con's of any "installation" method or go into details of why the squashfs loopback mounts are used (which is what I'm asking).
Also, be careful steering users towards full distros - I'm investigating TC for specific reasons which are not being addressed in others. :)
Dave
-
Flexibility. Changing onboot.list or tce directory you can have a different "installation", a different system very quickly just after reboot.
Safety. Installation is read-only, you can't destroy it easily.
Ok, so here's what I have so far for pro's:
- flexibility in the form of having access to various software via the onboot.lst file and tce bootcode
- read-only files (safety and OS is fresh after every reboot)
Technically, if the extensions were installed in scatter mode, pro #1 could be achieved by only using an alternative tce bootcode (without having to additionally edit onboot.lst). And pro #2 can be achieved as well in scatter mode by booting off of an SD card with the lock enabled (which would be much more secure and achieve the same goals than mounted loopbacks).
Please understand, I'm not trying to argue but instead gain understanding. At this point (based on these two replies) I can't see why scatter mode wouldn't be supported other than the package manager doesn't support it.
Thanks,
Dave
-
And pro #2 can be achieved as well in scatter mode by booting off of an SD card with the lock enabled (which would be much more secure and achieve the same goals than mounted loopbacks).
Much more secure? Why?
With a r/o SD card you must provide a writable storage to save you backup; of course if you have any. there can be a case when no need for backup.
-
Hi wysiwyg
an SD card with the lock enabled (which would be much more secure and achieve the same goals than mounted loopbacks).
Unless you happened to forget to enable the lock. To write to a squashfs file you must unpack it, make your changes, and repack it.
At this point (based on these two replies) I can't see why scatter mode wouldn't be supported other than the package manager doesn't support it.
Because it completely contradicts the design philosophy Roberts had when he created this distro.
You are free to modify this distro as you wish, but as Gerald mentioned, you might be better off with a more conventional distro.
-
And pro #2 can be achieved as well in scatter mode by booting off of an SD card with the lock enabled (which would be much more secure and achieve the same goals than mounted loopbacks).
Much more secure? Why?
With a r/o SD card you must provide a writable storage to save you backup; of course if you have any. there can be a case when no need for backup.
Thanks for the reply bmarkus. I would say that it's much more secure because there's no way to compromise a system with a physical switch (unless you have someone on the 'inside'). If a system is compromised with squashfs mounted loopbacks, the cracker can just modify those files and upon rebooting the system, you still end up with compromised software giving the user a false sense of security.
I will concede the point that you would need more than one storage device for writing your backup data (given my scenario), but this can be accomplished via another SD card, flash drive, hd, or even network storage. :)
Dave
-
Hi wysiwyg
an SD card with the lock enabled (which would be much more secure and achieve the same goals than mounted loopbacks).
Unless you happened to forget to enable the lock. To write to a squashfs file you must unpack it, make your changes, and repack it.
At this point (based on these two replies) I can't see why scatter mode wouldn't be supported other than the package manager doesn't support it.
Because it completely contradicts the design philosophy Roberts had when he created this distro.
You are free to modify this distro as you wish, but as Gerald mentioned, you might be better off with a more conventional distro.
Thanks for your reply on this as well Rich. Regarding the SD locking, yes this could be forgotten, however you're talking about a trivial amount of code that tests and prompts the user to lock/unlock the SD card depending on what's going on (e.g. the manufacturer supplied update that needs to be installed). See the reply to bmarkus for additional info on this.
Again, I'm not trying to argue, I'm just not sure why the scatter mode "installation" option isn't supported which is why I'm asking the question. :) To me this would create even more flexibility for the distro. To quote the website "Tiny Core is not a turn-key operating system" which, to me, means that TC is more or less a distro that a user can tailor to meet their specific needs before it becomes useful. Providing the most flexibility is what accomplishes this goal, right?
Another quote from the website "Easy, fast, and simple renew-ability and stability is a principle goal of Tiny Core." I would certainly say that TC is already accomplishing these stated goals. However, to get the most speed during bootup, wouldn't scatter mode create the least amount of overhead?
Great conversation so far! :)
Dave
-
The design goal of Core is to NOT have packages scatter their files all over the disk.
You might want to look a dDore which uses debian packages.
-
Ok so it doesn't sound like there's a particular reason other than for "cleanliness". If that's the only reason then I will continue my efforts on creating a 'scatter' installation mode. :)
Thanks for everyone's input! If there are any points that can be made in favor of using squashfs mounted loopbacks over a typical installation, please let me know!
Thanks,
Dave
-
Everyone has said not just no to scatter mode but Heck No !!!
Many benefits of security in a tc frugal install seem to have been deliberately pushed aside in favor of a totally insecure scatter mode install. Please tell me how it's possible to compromise an extension without the tools, and how a compromised extension if that's even possible could possibly survive an update check?
You'll perhaps find enlightenment in reading the core concepts before you venture further
Frugal, a fresh install on every boot..
Sent from my iPhone using Tapatalk
-
Loopbacks also protect against silent corruption (bad sectors, failing flash, etc). In a scatter install you won't notice until it's too far, unless you checksum everything.
The cleanliness was already said, but I'll add that even Linux systems accumulate files over the years just taking up space.
-
Everyone has said not just no to scatter mode but Heck No !!!
Many benefits of security in a tc frugal install seem to have been deliberately pushed aside in favor of a totally insecure scatter mode install. Please tell me how it's possible to compromise an extension without the tools, and how a compromised extension if that's even possible could possibly survive an update check?
You'll perhaps find enlightenment in reading the core concepts before you venture further
Frugal, a fresh install on every boot..
Sent from my iPhone using Tapatalk
Good morning coreplayer2, thanks for the reply as well! I see that people keep saying no to scatter mode, but I haven't had anyone tell me why other than 'cleanliness'. Can you list several security features that are ignored in a scatter mode install?
If a system is compromised, all kinds of bad things can happen. How could the tools necessary to manipulate packages not be uploaded to the hacked device? Update checks can be hacked too. No matter what, the most secure solution is a physical switch to enable/disable writing (regardless of scatter mode or any other mode). This also accomplishes the 'fresh install' on every reboot (as already mentioned).
Thanks,
Dave
-
Loopbacks also protect against silent corruption (bad sectors, failing flash, etc). In a scatter install you won't notice until it's too far, unless you checksum everything.
The cleanliness was already said, but I'll add that even Linux systems accumulate files over the years just taking up space.
Thanks for your reply as well curaga! I'll give you the first valid point for loopbacks over scatter mode regarding the corruption issue. For the accumulation of files, this wouldn't be any different than a typical TC install vs a locked SD. Both solutions would prevent those files from being written (in the wrong place) in the first place.
Thanks,
Dave