WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Core v4.2rc1  (Read 15983 times)

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7344
  • Founder Emeritus
Re: Core v4.2rc1
« Reply #15 on: December 11, 2011, 08:06:30 AM »
There are no plans to drop the "prebuilt example of what is possible with Core", TinyCore.iso.

The Core Project will continue to offer both isos MicroCore as well as TinyCore.

The change in 4.2 is to emphasize that our project is not dictating your desktop. Nor does one have a add on their preferred desktop. Using extensions choosing a desktop is just as easy as choosing a browser and without the extra bloat of unused or unwanted software.

I knew from the beginning, that if I offered a tiny CLI distro that it would not get much attention, but a tiny GUI Desktop would.

As users get comfortable using extensions, which is an absolute requirement in all cases, Such extension use is easily extendable to the the desktop GUI. I still get complaints about the default window manager. CorePlus showcases several Desktops, one of which the user may prefer.

The whole concept and philosopy of Core is Choice based on a tiny foundation.
I repeat TinyCore iso is not going away. It will continue to be offered as a working example of a very tiny GUI desktop.
Users may continue to use TinyCore as their main desktop from which to build upon.

4.2 moves the Core Project to a common foundation, which is easier to support both code and forums.
 
« Last Edit: December 11, 2011, 06:31:21 PM by roberts »
10+ Years Contributing to Linux Open Source Projects.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7344
  • Founder Emeritus
Re: Core v4.2rc1
« Reply #16 on: December 11, 2011, 08:09:57 AM »
Not strictly an issue with 'Core.gz', but rather 'Xprogs.tcz' (and so one could argue whether this belongs to the TCE section instead of the TCB one): In 'startx' (which has now been moved from '/usr/bin' to '/usr/local/bin') there are three hard-coded occurrences of '/usr/bin/xsetup.sh '.

IMHO using a hard-coded path is generally not a good idea, in particular when things are moving around (e.g. '/usr/local/bin/xsetup.sh' in this case). The issue becomes obvious after booting 4.2rc1 with the default option (i.e. 'tc') and then trying to use a different X server, e.g.
Code: (bash) [Select]
tc@box:~$ tce-load -wi Xorg-7.6 > /dev/null 2>&1 && startx
/usr/local/bin/startx: line 57: /usr/bin/xsetup.sh: not found
tc@box:~$
Agreed. This is what Release Candidate Testing is all about. 4.2 is a major change. I know have changed some 70+ programs. Surely I am not perfect. Bugs will  found and can be addressed
10+ Years Contributing to Linux Open Source Projects.

Offline thane

  • Hero Member
  • *****
  • Posts: 521
Re: Core v4.2rc1
« Reply #17 on: December 11, 2011, 12:39:33 PM »
Thanks roberts. That's actually the approach I was hoping for. It gives maximum flexibility to users who want it but provides a good example for less-experienced users to build on.

Offline maro

  • Hero Member
  • *****
  • Posts: 1229
Re: Core v4.2rc1
« Reply #18 on: December 11, 2011, 04:33:39 PM »
Robert, I've taken the liberty to run a quick loop over the "TC extensions" to search for other cases of '/usr/bin' files that have now "gone AWOL" :
Code: [Select]
tc@box:~$ for E in /mnt/sr0/cde/optional/*.tcz ; do sudo mount $E e ; find e -type f | while read F ; do strings $F | grep '/usr/bin/' | sed "s#^#[$(basename $E )] $F: # ; s#\] e/#] #" ; done ; umount -d e ; done > r
tc@box:~$ sed "s#.*/usr/bin/#/usr/bin/# ; s# .*##" r | while read F ; do [ -f $F ] || echo $F ; done | sort -u | while read F ; do grep $F r ; done
[flwm_topside.tcz] usr/local/bin/flwm_topside_makemenu: # Typically called from/usr/bin/desktop.sh
[Xprogs.tcz] usr/local/bin/screenshot.sh: /bin/sh -c "sleep 1 && /usr/bin/imlib2_grab $filename"
[Xprogs.tcz] usr/local/bin/setbackground: printf '\n[ -x /usr/bin/wbar.sh ] && wbar.sh' >> "$SETBKG"
[Xprogs.tcz] usr/local/bin/startx: [ -f /tmp/xsetup_requested ] && /usr/bin/xsetup.sh
[Xprogs.tcz] usr/local/bin/startx:      grep -q $XSERVER $HOME/.xsession || /usr/bin/xsetup.sh booting
[Xprogs.tcz] usr/local/bin/startx:      /usr/bin/xsetup.sh
tc@box:~$

Obviously the last three are the ones I had already reported in reply #13, but the others might deserve some TLC.


Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7344
  • Founder Emeritus
Re: Core v4.2rc1
« Reply #19 on: December 11, 2011, 06:06:30 PM »
Thanks, extra eyeballs, especially during release candidate testing, are always welcomed ;)
« Last Edit: December 11, 2011, 11:52:29 PM by roberts »
10+ Years Contributing to Linux Open Source Projects.

Offline coreplayer2

  • Hero Member
  • *****
  • Posts: 1606
Re: Core v4.2rc1
« Reply #20 on: December 11, 2011, 06:25:58 PM »
TC here to stay, cool. glad we got that cleared up

Online bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 4851
    • My Community Forum
Re: Core v4.2rc1
« Reply #21 on: December 12, 2011, 01:22:36 AM »
I'm using TC 4.1 on a notebook. There are three partitions, /dev/sda1 is ext4 others or NTFS (for Vista). There is a /tce directory on sda1. TC is booted from USB stick created with Unetbootin. Works fine, this setup is used for extension building, testing, etc.

Now created a stick on the same way with 4.2rc1

Starting tc with base norestore brings up the system with usual tc look and works.

Starting with norestore ends up in infinite 'Checking for extensions... ' with rotating chars.

Doesn't like my collection of extensions.
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Online bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 4851
    • My Community Forum
Re: Core v4.2rc1
« Reply #22 on: December 12, 2011, 01:39:58 AM »
Next test, I created a tce dir on sdb1 which is the USB FAT32 partion booting from and used

tinycore waitusb=5 tce=sdb1 norestore

expecting to hava a clean TC-like system using a /mnt/sdb1/tce to store downloaded extensions. But the result is just a command prompt.

Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline Guy

  • Hero Member
  • *****
  • Posts: 1089
Re: Core v4.2rc1
« Reply #23 on: December 12, 2011, 03:06:59 AM »
If you use an Ext2 filesystem, what happens?
Many people see what is. Some people see what can be, and make a difference.

Online bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 4851
    • My Community Forum
Re: Core v4.2rc1
« Reply #24 on: December 12, 2011, 03:29:37 AM »
If you use an Ext2 filesystem, what happens?

Do not want to use ext2. It is working fine in TC 4.1 and no reason to drop this functionality.
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline caminati

  • Full Member
  • ***
  • Posts: 180
    • Homepage
Re: Core v4.2rc1
« Reply #25 on: December 12, 2011, 03:54:42 AM »
If you use an Ext2 filesystem, what happens?

Do not want to use ext2. It is working fine in TC 4.1 and no reason to drop this functionality.

+1
(even though this is not an answer to the original question)

Offline Guy

  • Hero Member
  • *****
  • Posts: 1089
Re: Core v4.2rc1
« Reply #26 on: December 12, 2011, 04:08:06 AM »
Testing it with Ext2 is just a way of narrowing down the cause.

If it works ok with Ext2, something has malfunctioned as a result of fat32.

If it does not work ok with Ext2, that is not the cause of the problem.

Knowing this may help resolve it.
Many people see what is. Some people see what can be, and make a difference.

Online bmarkus

  • Administrator
  • Hero Member
  • *****
  • Posts: 4851
    • My Community Forum
Re: Core v4.2rc1
« Reply #27 on: December 12, 2011, 04:19:04 AM »
You are free to make such test if you are interested in result :)
Béla
Ham Radio callsign: HA5DI

"Amateur Radio: The First Technology-Based Social Network."

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7344
  • Founder Emeritus
Re: Core v4.2rc1
« Reply #28 on: December 12, 2011, 07:11:41 AM »
With a common foundation, being core.gz,  base norestore will result in a command prompt.

As noted in the announcement post is xbase.lst, i.e., using lst=xbase.lst norestore will result in a base X/GUI system.
xbase.lst is delivered in the TinyCore iso and should be copied to your working tce directory. Of course it is editable and therefore as a benefit "base" can mean Xorg & jwm as an example, or even, Xorg/XFCE. Whatever is "your" base X/GUI.
« Last Edit: December 12, 2011, 07:17:40 AM by roberts »
10+ Years Contributing to Linux Open Source Projects.

Offline roberts

  • Administrator
  • Hero Member
  • *****
  • Posts: 7344
  • Founder Emeritus
Re: Core v4.2rc1
« Reply #29 on: December 12, 2011, 07:14:35 AM »
I'm using TC 4.1 on a notebook. There are three partitions, /dev/sda1 is ext4 others or NTFS (for Vista). There is a /tce directory on sda1. TC is booted from USB stick created with Unetbootin. Works fine, this setup is used for extension building, testing, etc.

Now created a stick on the same way with 4.2rc1

Starting tc with base norestore brings up the system with usual tc look and works.

Starting with norestore ends up in infinite 'Checking for extensions... ' with rotating chars.

Doesn't like my collection of extensions.
Use boot option showapps to display each extension as it is being loaded should help in resolving this issue.
10+ Years Contributing to Linux Open Source Projects.