LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 10-22-2014, 08:54 PM   #31
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,442
Blog Entries: 15

Rep: Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007

Quote:
Originally Posted by tronayne View Post
Well, thing is, they weren't broken; they were just slow.

The first programmable computer was the Bomb developed and implemented at Bletchley Park in Milton Keynes, Buckinghamshire, England during World War II. That's where they broke Enigma. It had electronic tubes (what the Brits call valves), paper tape, lots of relays and other exotic gadgets and was operated by a lot of really smart folks led by Alan Turing.

All that's really happened is that electronics has gotten physically smaller, packed with more and more circuits that go faster and faster on less power and the price of admission has gone down exponentially over time. The basics are still the basics: load register, load other register, execute. Some guys recently (like in the last week two) have developed quantum in silicon (which wasn't supposed to be possible a month ago). Multicore processors are just more stuff on the same die for less cost still doing load register...

Anymore it's not the hardware that's the limit. Gordon Moore (in 1965!) postulated the law named for him and it's still in effect (so far, anyway). Starting to plateau, it's beginning to look like nanotubes might be the next great thing. When it was tubes and relays and miles of wire and big clunky boxes it was the programming that mattered. It still is. You could "write" bad programs on a phenolic punch board, you could write good ones. You still can -- in multiple languages with a lot of help from utilities and the shell but nobody has figured out, yet, how to create perfect systems although I believe Linux comes darned close to be a perfect platform where you get to stand on the shoulders of giants and do your thing.

The trick is to learn when to stop.
It's not just learning to stop, it's also knowing which path leads to the best conclusion, knowing when to say when, and knowing that often accuracy in computation is going to be a factor worth taking notice of. It's natural people want bigger, faster, shinier, and more, but to use it as an analogy, fast cars with poor drivers and bad tires do not win races.

Writing programs that do their job, must take precedence, and they have to do that job well. It doesn't matter how fast or slow the process is, it's how accurate the process is performed.

Take the emulator higan/bsnes against a comparable emulator zsnes as a prime example of accuracy versus speed. Yes, zsnes is faster, can work on lower end hardware systems and plays games well, but against the ability of higan/bsnes to run games with near 99.99% hardware accuracy including various specialty add-on processing chipsets used by SNES cartridges which has not only allowed games that were thought non-emulatable to run, it also has beat copy-protection by making the ROM used by the emulator actually believe the software is so accurate it's the real hardware. Higan/bsnes is a masterpiece at SNES emulation.

It may cost more resources to be more accurate in execution and process, but the accuracy is worth the effort. Programs must do their jobs, do them well, and be within acceptable standards of accuracy, otherwise, it's like you're just try to drive a Lamborghini Diablo with bald tires on a wet road at 250kmph.

Last edited by ReaperX7; 10-22-2014 at 08:57 PM.
 
Old 10-23-2014, 07:04 AM   #32
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541

Rep: Reputation: 1060Reputation: 1060Reputation: 1060Reputation: 1060Reputation: 1060Reputation: 1060Reputation: 1060Reputation: 1060
Quote:
Originally Posted by ReaperX7 View Post
Writing programs that do their job, must take precedence, and they have to do that job well. It doesn't matter how fast or slow the process is, it's how accurate the process is performed.
Oh, yes.

On this subject, there is a nice, compact, discussion (en.wikipedia.org/wiki/Unix_philosophyn):
Quote:
Doug McIlroy, then head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe, summarized the Unix philosophy as follows:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Beyond these statements, he has also emphasized simplicity and minimalism in Unix programming:

The notion of "intricate and beautiful complexities" is almost an oxymoron. Unix programmers vie with each other for "simple and beautiful" honors a point that's implicit in these rules, but is well worth making overt.

Conversely, McIlroy has criticized modern Linux as having software bloat, remarking that, "adoring admirers have fed Linux goodies into a disheartening state of obesity." He contrasts this with earlier approach taken at Bell Labs when developing and revising Research Unix:

Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option.
One might postulate that the BASH mess is a result of exactly the sort of thing McIlroy says in the above two paragraphs?

Just sayin'
 
3 members found this post helpful.
Old 10-23-2014, 07:26 AM   #33
harryhaller
Member
 
Registered: Sep 2004
Distribution: Slackware-14.0
Posts: 452

Rep: Reputation: Disabled
Quote:
Originally Posted by tronayne View Post
Oh, yes....
Excellent quotes!

and that complexity impacts on maintainability.

Quote:
Instead of adding an option, think about what was forcing you to add that option.
Exactly.
 
Old 10-23-2014, 12:12 PM   #34
rob.rice
Senior Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 1,036

Rep: Reputation: 186Reputation: 186
boot time !
boot time !
boot time !
you want a faster bootup
tailor a custom kernel to the hardware you run
build it as a monolith kernel
this will cut your boot time in half

DON'T MESS WITH SLACKWARE !!!
it's the best distro there is
 
2 members found this post helpful.
Old 10-23-2014, 12:17 PM   #35
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,982

Rep: Reputation: 491Reputation: 491Reputation: 491Reputation: 491Reputation: 491
For even faster boot time switch the startup scripts to ash or dash.
 
Old 10-23-2014, 05:16 PM   #36
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,442
Blog Entries: 15

Rep: Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007
You also can move the cache updates into cron as well.
 
Old 10-23-2014, 06:46 PM   #37
GazL
Senior Member
 
Registered: May 2008
Posts: 4,754
Blog Entries: 14

Rep: Reputation: Disabled
What I did was move the cache updates into their own rc file and then added an extra line to the bottom of inittab so that it runs in the background once rc.M finishes in parallel with the getty's or xdm being started.

/etc/inittab:
Code:
# Maintenance scripts
m1:34:once:/etc/rc.d/rc.app_updates
/etc/rc.d/rc.app_updates:
Code:
#!/bin/sh
#

exec >/var/log/app_updates.log 2>&1

# Update the X font indexes:
/usr/bin/fc-cache -v -s -f

# Update any existing icon cache files:
rm -f /usr/share/icons/icon-theme.cache
find /usr/share/icons -maxdepth 2 -name 'icon-theme.cache' \
  -printf '%h\0' \
 | xargs -0r -I'{}' /usr/bin/gtk-update-icon-cache -t -f '{}'

# Update mime database:
/usr/bin/update-mime-database /usr/share/mime

# These GTK+/pango files need to be kept up to date for
# proper input method, pixbuf loaders, and font support.
/usr/bin/update-gtk-immodules --verbose
/usr/bin/update-gdk-pixbuf-loaders --verbose
/usr/bin/update-pango-querymodules --verbose
/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas

# All done.
I've reworked the icon-cache update part to something a little more efficient than what is in rc.M.

My system is up and presenting a login prompt in a little over 14 seconds. Moving sendmail, sshd and a couple of the other non-critical-path daemons to run after rc.M could also make it present a little quicker, but 14 seconds is more than good enough for me.
 
12 members found this post helpful.
Old 10-24-2014, 05:09 PM   #38
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,442
Blog Entries: 15

Rep: Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007Reputation: 2007
This is a tremendous find GazL, I implemented this myself, and wow. You should submit this idea to Patrick.
 
1 members found this post helpful.
Old 10-24-2014, 11:34 PM   #39
notKlaatu
Senior Member
 
Registered: Sep 2010
Location: Wellington, New Zealand
Distribution: Slackware, Fedora, NetBSD
Posts: 1,048

Rep: Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712Reputation: 712
Quote:
Originally Posted by GazL View Post
What I did was move the cache updates into their own rc file and then added an extra line to the bottom of inittab so that it runs in the background once rc.M finishes in parallel with the getty's or xdm being started.
I just tried this. I'm sold! I don't know if it was 14 seconds, but it was much faster than usual.

You should at the very least add this as a tip on docs.slackware.com.

Nice work, thanks!
 
Old 10-25-2014, 12:14 AM   #40
genss
Member
 
Registered: Nov 2013
Posts: 739

Rep: Reputation: Disabled
great idea, just one thing
afaik font cache has to be done before starting X as it is loaded at the servers start
 
Old 10-25-2014, 01:21 AM   #41
GazL
Senior Member
 
Registered: May 2008
Posts: 4,754
Blog Entries: 14

Rep: Reputation: Disabled
Yep, that's something I considered, but I believe the font-config cache is used at an application level rather than X level (fontconfig/freetype is all client side) so it shouldn't matter if its updated after the X server starts. Fonts rarely change anyway, so the majority of the time you could get away with not running it at all. I believe some slackers just comment it out completely and just update it manually after any package management activity.

But I could be wrong, so if anyone who has also done this encounters any weirdness, please post and let us know.


@notKlaatu, 14 seconds was with my custom kernel and on my dual core (Core2) system. Prior to this change it was around 21.5 (+/- .5 sec) so it was around a 25-30% saving for me, but hardware will be a factor to, so results will be variable.
 
Old 10-25-2014, 01:26 AM   #42
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,770
Blog Entries: 6

Rep: Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586Reputation: 2586
Truthfully, boot times are not on my radar and my eyes usually glaze over at the thought of trying to shave a few seconds off... but it is the end of a difficult week and I am catching up on my LQ threads and found this one. So why not!

I have tried this on my two main systems, laptop and desktop with the following results:

Code:
Laptop - Pentium M, 1.7Ghz, 2GB RAM Slackware 14.1+ w/initrd
Normal boot: 45 sec
Modified boot: 36 sec
Diff: 20%

Desktop - AMD Phenom II X2 3.1Ghz, 3GB Ram Slackware 14.1+ w/initrd
Normal boot: 45 sec
Modified boot: 32 sec
Diff: 29%
So I guess that is a worthwhile gain if that is important to you. It is certainly an interesting data point and has now entered my admin knowledge base - thanks Gazl!

That said, I have returned both machines to the original configuration for now, because my beard is too gray, my shoes are too tight and I have forgotten how to dance...
 
Old 10-25-2014, 03:28 AM   #43
bartgymnast
Member
 
Registered: Feb 2003
Location: Almere, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 356

Original Poster
Rep: Reputation: 145Reputation: 145
I think I made my point not clear.

Its not only init systems I talk about.
Lets say for example Wayland.

like every other software, It is new and not yet proven stable. (as most of you call it)
so with testing, and testing etc. it will be stable in the future.
I bet someone wants to test KDE on top of wayland.

This is what it is all about.
As it is not just 1 script that needs to be installed, its a set of packages that most likely needs to be rebuild.

such a project like I describe should not be too difficult to achieve,
maybe a set of maketag files and slackpkg+ repo.

Maybe we can even make a sticky thread here with links to specific pages etc...
 
Old 10-25-2014, 05:01 PM   #44
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
Packages aren't a problem, should the upstream developers care about more than just their narrow group. Really, the only group of dependencies that has proven to be truly nasty is the GNOME3 set. That comes from stale instructions and a poorly-organized site for getting the source code. Oh, and there's that "we need version 3.4.999 but you're only using version 3.4.998" mentality that makes me want to visit somebody in person and have a talk.

[I've never been able to compile Open Office, either, but that's due to all of the unknown places on the Internet I have to visit just to find the prerequisites. Half of those Java-related sites look like they'll serve malware one day.]

I know nothing of Wayland. If X11 can be run, then stopped, then Wayland can be run, that's fine. If Wayland is one-quarter broken over the course of a year, then it is just as reliable as X11. There's no issue with me. Should the packages make it into -current, I'd like to try it, even if it crashed the PC. If it's acceptable to use when installed using upstream instructions, it's fine with me. If it has to be set up with a bunch of undocumented XML config files, it will probably not be fine with me.

Somebody please correct me if Wayland is really an evil beast that breaks everything else and is just waiting to be unleashed...
 
2 members found this post helpful.
Old 10-25-2014, 05:17 PM   #45
genss
Member
 
Registered: Nov 2013
Posts: 739

Rep: Reputation: Disabled
wayland is a protocol
the implementation is using KMS + something to draw with (egl/opengl(es) or just a buffer)
and evdev for input

so it shouldn't break more then the mesa driver used to render, if hardware acceleration is used that is
or break at all if no acceleration is used

logind is used there as an input and output... permissions manager, that was a job of xorg-server so far (and console-kit, i think)
as almost everybody else on the planet i know very little about console-logind
should not be needed for single user computers but there needs to be some kind of mechanism
idk
i wish the kernel would be able to change permissions on open files but idk

as for xorg in wayland, there should be some xwayland bug tracker somewhere

Last edited by genss; 10-25-2014 at 05:21 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Call For Community Input: Linux Professional Institute "Job Task Analysis" LXer Syndicated Linux News 0 02-05-2010 03:11 AM
LXer: All They Need Is Funds: A Call For Community Support LXer Syndicated Linux News 0 01-13-2007 10:03 PM
You call this COMMUNITY?? Hitboxx General 53 10-22-2006 11:23 AM
New Slack User!!! Appreciates Community!!! boutrosboutros Slackware 4 01-03-2004 08:49 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:38 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration