Tiny Core Linux
Tiny Core Base => TCB Tips & Tricks => Topic started by: coreplayer2 on October 19, 2012, 08:42:15 PM
-
I have to say, thanks for this boot code
waitusb=5:LABEL=TINYCORE
this, this above boot code has decreased my USB boot process tremendously, cut to a fraction of the previously used waitusb=5. Another benefit of this boot code is seen when the Label has been corrupted (renamed etc) where a countdown will be presented, providing system feedback (beside the obvious accidental Label rename).
I know bmarkus is a heavy supporter of Labels, am sad to say I never gave enough respect to Labels before. However all that has changed, now I understand the importance of Labels.
Thanks again
-
waitusb=5:LABEL=TINYCORE
Impressive. I wonder if other "mountable targets" like UUIDs are valid.
-
Hi genec
Yes, you can replace LABEL with UUID
-
I have to say, thanks for this boot code
waitusb=5:LABEL=TINYCORE
great contribution!
on my old 1,6ghz-one-core-notebook i could decrease the boot-time from 8,6s to 3,9s now.
that's a noticeable speed improvement.
thanks.
-
hi
sorry but best boot code ever?
Not if you are filesystem is on normal hard drives, meaning not USB drives.
but I would say, that a candidate for most unique bootcode ever.....one that AFAIK no other Linux distro can offer.....is a bootcode that allows you to choose which sound device you have enabled at boot up.
As you can see this too is subjective because most people do not have 2 sound devices to choose from eh?
http://wiki.tinycorelinux.net/wiki:alsa_part2#choose_sound_devices_at_boot
and it goes without saying but will say it,
thanks for this bootcode as well.
-
You can do this on other distros, too.
What if your 2 devices use the same driver?
-
OMG. A spinning hard drive? That's archaic...
But I'll give you that if you have a rare PC with two audio cards then that boot code might be a contender..
:)
-
What if your 2 devices use the same driver?
quite possible, true....but then you would probably be using a model=string to differentiate between them, I hope
-
I have to say, thanks for this boot code
waitusb=5:LABEL=TINYCORE
I use 30 seconds on my USB sticks -and- on my hard drives. That way I can use an almost identical menu.lst (for grub4dos) on whatever I boot from.
The wait time is cancelled as soon as the device is recognized, so it doesn't cost me any time. But if something is seriously fouled up, and the device never comes on line, 30 seconds gives me plenty of time to notice something is going on and take control of the situation.
FWIW, I rarely see it count down even one second before recognizing a USB stick and cancelling the wait time, though it wasn't always so.
And yeah, that's the coolest boot code ever because I can specify a subdirectory on the device:
waitusb=5:LABEL=cruzr0/boot/core4.6.2/tce
or
waitusb=5:LABEL=cruzr0/boot/core4.7rc3/tce
for two entirely separate distributions on the same usb stick. -That- is cool!
-
OMG. A spinning hard drive? That's archaic...
If you spin those old things too fast, all your bits will fly off the edges. That's why there's more data on the outer tracks than the inner ones. :)
-
but I would say, that a candidate for most unique bootcode ever.....one that AFAIK no other Linux distro can offer.....is a bootcode that allows you to choose which sound device you have enabled at boot up.
As you can see this too is subjective because most people do not have 2 sound devices to choose from eh?
http://wiki.tinycorelinux.net/wiki:alsa_part2#choose_sound_devices_at_boot
I think such a bootcode might be sound system specific, when core has no sound system in base and offers 2 different sound systems treated equally as extensions...
-
LEE that is cool too ;D
Never occurred to me that you could combine the two, I use a similar boot code to specify two separate versions of core via separate tce directories, am going to try your method thanks
-
Lee, I think you are confusing waitusb= with tce=.
-
Lee, I think you are confusing waitusb= with tce=.
You're right. Looks like one of those "senior moments". I can use that excuse now that I'm old enough that the AARP wants me. :)
-
This highlights a lack in our docs, I believe :)
Core is not even close to being as complicated as many other distros, but it does have many nice tricks like that. If even experienced users like coreplayer2 find new old things, that to me says docs aren't up to snuff.
If only there was enough time ;) I've had this idea of writing a book on Core, fully current for one release, with chapters describing the internals, some on projects to use Core for, some focusing on boot time etc. I was thinking both the pdf and ascii sources would be freely available online, dead tree version available at some cost.
Sadly, at least 'til christmas uni is taking all of my time, weekends too.
-
Our system has matured and settled down from the frantic pace of early development.
A book would be most welcomed. Curaga, I would encourage you to do so.
-
I was going to request topics, and also if anyone wanted to contribute chapters. But as it is, I haven't even yet gotten to prototyping asciidoc for that purpose.
I've written man pages in asciidoc, and so far I really prefer it to any alternate formatting systems, like latex and docbook. It would seem suitable to do books in as well, given that O'Reilly does so.
But anyway, with no time there's no time. Any comments appreciated of course, just don't expect any progress this year ;)
-
This highlights a lack in our docs, I believe :)
Core is not even close to being as complicated as many other distros, but it does have many nice tricks like that. If even experienced users like coreplayer2 find new old things, that to me says docs aren't up to snuff.
It could also indicate that once experienced users get a setup that works, there's little need to learn new things until the setup needs to change. Not, of course, that I'd argue about the quality of the docs, and if/when you write that book, I'll be buying a copy!
-
reading the source is often better than any documentation.
especially if everything is an easily accessible shell script.
-
Hi hiro
reading the source is often better than any documentation.
Yes, but only if one can comprehend the source. I do very little scripting, but can usually get the general idea
of what's going on in a script. However, in order to fully understand it, I often have to start Googling to figure
out what all the $##* type syntax does.
-
I agree, bourne shell has some very clumsy syntax. I ignore such parts that I don't understand :)
-
I find those parts of sh are logical once you know them. I hear it's similar for perl once you get to know it.
-
Posted by: curaga
« on: 2012-10-21, 09:35:32 »
This highlights a lack in our docs, I believe :)
Core is not even close to being as complicated as many other distros, but it does have many nice tricks like that. If even experienced users like coreplayer2 find new old things, that to me says docs aren't up to snuff.
If only there was enough time ;) I've had this idea of writing a book on Core, fully current for one release, with chapters describing the internals, some on projects to use Core for, some focusing on boot time etc. I was thinking both the pdf and ascii sources would be freely available online, dead tree version available at some cost.
Sadly, at least 'til christmas uni is taking all of my time, weekends too.
Posted by: roberts
« on: 2012-10-21, 10:18:27 »
Our system has matured and settled down from the frantic pace of early development.
A book would be most welcomed. Curaga, I would encourage you to do so.
Posted by: curaga
« on: 2012-10-21, 11:20:28 »
I was going to request topics, and also if anyone wanted to contribute chapters. But as it is, I haven't even yet gotten to prototyping asciidoc for that purpose.
I've written man pages in asciidoc, and so far I really prefer it to any alternate formatting systems, like latex and docbook. It would seem suitable to do books in as well, given that O'Reilly does so.
But anyway, with no time there's no time. Any comments appreciated of course, just don't expect any progress this year ;)
Hmmm... maybe this topic warrants at least a thread of its own?
I'd been sort of hoping something like this would come up, even knowing that Core was a bit of a moving target. It does seem to have settled down a bit lately.
Perhaps the remainder of this year can be used by the community to compile a wish list of topics and and a volunteer list of those who would contribute chapters or other assistance. Put my name on the latter list.
-
in the spirit of talking ideas.....I have one for more experienced maintainers to consider, if you can understand me
Lets pretend I am a simple user....check
Lets pretend I use APPS panel to do my updates instead of using the command line....ok
If a maintainer, in the info file, or in a forum is recommending that some post-install action may be needed,
---could the maintainer have a post-install script that interacts with APPS to alert the user of that possibiltiy
-----and if there is already a post install action script, how does a newbie know its been done,
---------in case it impacts on other things?
I am thinking some kind of echo script like
echo 'see forum or wiki if you need something or use something or don't have something etc'
I am not an expert and don't want to name any packages as I think that might be inflaming.
cheers
-
We don't want useless messages displaying on every boot.
Read the info panel.
-
gerald_clark
if you are referring to me, I am not sure I was suggesting any such messages at boot. I am only talking about the possible messages maintainer might want users to see when they update thru the APPS panel
I can see my suggestion was not understood so shall blame me the sender so don't worry.
-
How would the apps panel installing an extension differ from tceload -iw ?
Something that displays once, and then never appears again would be confusing.
How would you go about displaying it again?
Isn't it better to read the info file?
-
I regret posting this but lets pursue it to its natural death eh?
I am making a suggestion about using APPS for updates .........not installing a fresh tcz.
If the suggestion has no merit, please consider this suggestion withdrawn, I don't want you wasting time pondering it.
I shall spank myself virtually for wasting your time....sends virtual beer to Gerald so no hard feelings impied
-
I'm not trying to discourage you. You said you wanted to talk over an idea. I am just trying to get a clear idea of what this suggestion was to accomplish.
-
ahh ok
well this the issue as I see it, in my mind
Someone becomes a convert to TC
then uses APPS panel to do their updates
(but does not research any info file for a reason----below)
upon receiving updates thru the panel they are not aware that there may be some info that just missed out on.
OK so the reason why they use the panel, is because thats a tool that is available and in my mind, if it should not be used in the way I described above, we need better docs.......Yeah
sidetrack issue 1) I am not suggesting I am the expert here
sidetrack issue 2) Now when newbies read or don't read the info file, they may be using the wiki.....so wiki needs improving sometimes ....eh?
We are not talking installing or research new software to install, We expect that a search for a package or provides a executable or has a tag.......leads the newbie to read the info file.
So what I was wondering, can APPS receive a post-install script on updates alerting them to information the maintainer would like to impart. I am aware that maintainers can already have post-install scripts but due to the nature of that script, it tends to be absolute and not offer cautionary advice.
(more waffle) And some people, using APPS panel will open 2 panels at once,
upon seeing the list of packages to click on .....to update
they click into the second panel to browse....search package name and read the info.
Now if that was only one or 2 packages newbies (like me) might do it, but what if the list was long such as when a key lib package changes and onflow packages depending on it then update?
We all have time issues and my suggestion would require (I assume) a change to TCB to allow "on update" messages
--if in doubt, each tcz might need to have a post-install terminal -e echo type message but that might be pushing my luck?
is that clearer?
-
I don't remember there ever being any special instructions needed when updating an already installed extension.
New code is written to fix problems or add useful features.
I am not sure I see either here.
-
well thats ok, I have bounced it off someone important
I will have another idea in 2.6 years ;)