K-Tizen

[knc1]

As a follow-up to my comment about the Mer Project;
https://www.mobileread.com/forums/sho...03&postcount=4

It may well be an "all powerful" distribution builder, but the learning curve is far too steep for this old man to climb. Life's too short for that.

They (MerProject) mention they will be sharing with Tizen -

Tizen is a relatively new, embedded device, distribution with a strong focus on providing a base for a good Application SDK.

The MerProject has the Platform SDK portion of distribution building well underway, I suspect their "code sharing" will be to use the Tizen Application SDK. I may well be wrong, this is only a guess.

The Tizen home page: https://www.tizen.org/
Tizen already builds for ARM.

For a quick review of Tizen -
https://source.tizen.org/
Click the two pages linked to in that banner;
The platform overview: https://source.tizen.org/platform
and
The release description: https://source.tizen.org/release

This one, at first look, appears to be a better choice for replacing the Amazon/lab126 mess.

The lack of a Platform SDK is only of concern to the (few, often very few) "core of the system" developers. Those people with the office under the back stairway who deal with things like kernel e-ink drivers.

The Application SDK is what the vast majority of K-Tizen developers would be dealing with day-to-day.

So this one seems worth a more in-depth look.
Developers starting point: https://developer.tizen.org/

Too big a job for a "one man show" but with a half-dozen or so active developers...

K-Tizen anybody?

Edit Needed to put these cartoons on my own thread:

[Nyoxi]

I'm still not too comfortable with that `let's all use html/js to build apps' idea that is pushing through lately, but as far as MER is concerned I find it really interesting.

[knc1]

Originally Posted by Nyoxi

I'm still not too comfortable with that `let's all use html/js to build apps' idea that is pushing through lately, but as far as MER is concerned I find it really interesting.

Agreed. But then maybe I am just too "old school" in my thinking.
- - - -
The Tizen project does not let you rsync (or anything else) their distribution source tree(s).
The Mer project does allow rsync (and provides a tool to do it for you, you just need to have an extra 7..10Gbytes handy to store it on).

For those who want their Kindle to act like a Samsung smartphone...
(Which is where the system api evidently came from, nearly everything else is Debian Wheezy/sid.)
And the Samsung stuff looks like it came from Google Android (see: Linux Poker above).

Arch Linux Arm (probably stripped down) is still in the running (in my mind anyway).

Edit: 05/12/2012
Tizen does allow you to mirror their download sub-domain.
22Gbytes downloaded now and still working on it.
It isn't as if they don't give you some reference material to read.
- - - -
Plus, they updated the SDK and SDK InstallManager in the midst of this effort to mirror (and fix) the SDK installation process.
Maybe their updates to that section of the download tree have already fixed the problems that started me off on this "file grab" trip.
- - - -
Here, I am writing about their "Application SDK" (no "Platform SDK" yet, long term, it isn't needed except by a very few).
This SDK comes in two flavors - an Eclipse Plug-In and a Web Interface.

Having the Application SDK available as a Web Interface is an important point for a Kindle Fan Site (such as this forum).

It gives the developer of the one (or few) small projects immediate access to the Application SDK - without the "installation handsprings" of getting a typical SDK installed locally (complete with editors that get the line endings wrong).

[knc1]

Still downloading, 50Gbytes and counting. See "Edit" above.
Edit 5/13/2012:

Originally Posted by wget

FINISHED --2012-05-13 07:06:41--

About 57 gigabytes.
Now, tell wget to do it again, just to pick up anything changed during the first several days it took to mirror the Tizen download site.

[knc1]

Originally Posted by knc1

As a follow-up to my comment about the Mer Project;
https://www.mobileread.com/forums/sho...03&postcount=4

First things first, a hyphen in a name is a bad idea (tm).
Tag this baby as: kTizen from now on.

Ref:
https://www.mobileread.com/forums/att...8&d=1336652980

Def:
OBS - Open Build Service
An openSUSE project, see: http://www.open-build-service.org/
Ref: http://en.opensuse.org/Portal:Build_Service


Mer Project
A community (Corporate or otherwise, including a "community of one") Embedded Linux project, see: http://merproject.org/about.html

Tizen
A system distribution for Embedded Linux platforms, see: https://www.tizen.org/

Both the Tizen distribution and the Mer Project use the OBS build system.
The Tizen distribution, being a distribution, maintains the system repositories.
The Mer Project allows the configuration of local (or community) system repositories. The Mer Project does have system repositories but expects that they will just be a starting point for any new, community (or Corporate) system repositrory. (Which is why they let you rsync them.)

Neither (currently) supports the Freescale, i.MX, SoC devices.
Neither (currently) defines any of the Amazon e-book products as a platform.
Both currently build for armel.

At this point in the post, review the first reference link above, then take a deep breath...

Tizen uses the code from Samsung (as used in the Samsung smart phones and tablets) to provide the "core platform API".
Giving a Kindle product a sub-set of the Samsung product behaviors is "good enough" as a starting point for kTizen.
Assume that kTizen re-uses the Tizen/Samsung "core platform API code".

Tizen is pulling most of their "platform sources" from Debian Wheezy/sid and some from Ubuntu.
Not a bad choice for Tizen, embedded systems need to be "conservative" in their choice of platform sources.

But, being locked into the aging, very conservative, choice of Tizen may not be suitable for kTizen.

Enter the Mer Project.
Using the Tizen/Samsung "core platform API code" snapshots (no repo access) plus defining the "platform sources" as remotes of the Debian/Ubuntu upstream sources would be a better choice for kTizen.
That would allow the choice of "very conservative" core system builds (like Tizen) or "bleeding edge" core system builds. Builder's, build-time, choice.

Every embedded Linux device needs a bootloader and a kernel.
You all know where the kernel and u-boot repositories live.

Freescale maintains a product specific set of repositories, with the upstream u-boot and kernel repositories as remotes, see: http://git.freescale.com/git/
Note: Freescale has the series three kernel sources in the "-2.6" named repository. Currently as recent as: 3.0.0 (a.k.a: 2.6.40).

Amazon does not publish access to their repositories, but they do publish their product specific changes to the kernel.
Hope to find someone who loves to merge patches and presuming such a masocist will be found...

Tizen is using ScratchBox-2 as its cross-compile engine, see: http://maemo.gitorious.org/scratchbox2

More later, once I have studied these tens of gigabytes of files I downloaded a bit more.

Comments welcomed here.

[knc1]

Originally Posted by knc1

Still downloading, 50Gbytes and counting. See "Edit" above.
Edit 5/13/2012:

About 57 gigabytes.
Now, tell wget to do it again, just to pick up anything changed during the first several days it took to mirror the Tizen download site.

Second pass:

Originally Posted by wget

FINISHED --2012-05-13 10:16:29--
Downloaded: 14942 files, 449M in 33m 40s (228 KB/s)

Now to turn that into a "reference R/O base" -
I may be able to get it onto a "boxed set" of 8 DVDs if anyone wants to skip the 3-1/2 day long download step.
Should be able to "over-night" it anywhere in the USA sooner than your Internet connection could grab a copy from the rate-limited Tizen site.

And a third pass, just to be sure:

Originally Posted by wget

FINISHED --2012-05-13 22:29:29--
Downloaded: 14942 files, 449M in 28m 59s (265 KB/s)

[knc1]

The tizen/download.tizen.org file tree is about 48 Gbytes on R/W disk.
As a squashFS RO file tree it is about 19 Gbytes.

It should fit on a "5 DVD set" as a multi-volume archive.

When used as the "base" RR layer of an auFS stack, will allow the use of wget --mirror command to track the contents of the Tizen download sub-domain without downloading the initial 48 Gbytes.
Since the Tizen download sub-domain is rate-limited, this can save you about 3-1/2 days of watching wget work.

PM me for details.

[knc1]

Originally Posted by knc1

The tizen/download.tizen.org file tree is about 48 Gbytes on R/W disk.
As a squashFS RO file tree it is about 19 Gbytes.

It should fit on a "5 DVD set" as a multi-volume archive.

When used as the "base" RR layer of an auFS stack, will allow the use of wget --mirror command to track the contents of the Tizen download sub-domain without downloading the initial 48 Gbytes.
Since the Tizen download sub-domain is rate-limited, this can save you about 3-1/2 days of watching wget work.

PM me for details.

Started an update of the Tizen download domain last night.
Will know if the first attempt at making an: "update layer" works once it is finished.
Will be posting the "HowTo" once correct/intended behavior is checked.

PS: It is too big for me to post, and my public servers are about 1,200 miles away - too far to carry a set of DVDs over to the DVD reader and load them.
But I will be able to ship sets of the DVDs (in the USA at least).

Edit 5/24/2012:
This "incremental change" to the contents of download.tizen.org is larger than their original release. Must have been a busy two weeks over at the Tizen shop.
And, yeah, they still have it rate limited to "extra slow".

Edit 5/25/2012:
70Gbytes and still going strong. Sure glad I don't pay for my bandwidth by the byte or by the hour!

What happened down at the Tizen project this past week, they added three directories to the download sub-domain.

snapshots - They have started posting snapshots of the entire system, sometimes as many as five per day. That should slack off once the distribution stablizes.

live - Evidently as a storage place for each user of the on-line build system.
The public release of Tizen is only a few weeks old, but this sub-tree will probably grow quickly.

Most of the directories under "live" have names that end in a colon (":") -
Anyone familar with any *nix can imagine what a poor idea that is.
(And anyone who isn't, colon (":") is the directory path entry seperator.
Quick now is: "/usr/bin:/usr/sbin" one pathname or two? What if the name of the first is "bin:"?)

5/26/2012:
80 Gbytes and still going strong.
Modem is a bit warm and has had to be re-booted three times during this process.
Still adveraging 1 Gbyte / hour. (1/4 the capacity of my aDSL line) Grumble, grumble, grumble.

Later:

FINISHED --2012-05-26 06:33:31--
Downloaded: 33764 files, 70G in 3d 10h 11m 45s (247 KB/s)

Not really, download ran out of disk space.
Should have seen that one coming but forgot to check on it the last several days.
Restarted Just hope I can get that domain mirrored before they go back to work next week.
Later:
Moved things around a bit so the "changes" file had room to grow another 150Gbytes in size. Hope that is enough this time.
Evening:
82Gbytes - still going strong, may be finished by tomorrow morning with any luck at all.

5/27/2012:
90Gbytes and still going strong.
There had been four snapshots added between when the download began and when it ran out of disk space three+ days later.
Anyway, have gotten past that "snapshot" sub-directory and now working (again) on the "live" directory.

If the "live" directory is the storage place for the on-line web-builder (in use 24/7) then it may never be possible to find it "idle" long enough to get a complete copy.
Except during "World Stopping Events" -
The Indy 500 race today -
The World Soccer Cup (whenever that is) -
Things like that, when not even drunk geeks work on-line from home.

Evening:
96Gbytes and still going strong.
Will need to re-think this idea of keeping a mirror of the Tizen download site.

5/28/2012:
124Gbytes and it went zombie.
Guess I need to find out what I (or Tizen) did wrong.

[knc1]

Tizen "went public" April 30th.
The first copy of the download.tizen.org sub-domain was made middle of this month.
The second (updated) copy of the download.tizen.org sub-domain should be completed today (end of May).
- - - -
When Tizen added the three new directories, the changes in the menu layout combined with the options I was using with wget caused a recursive loop that wget did not detect.

Edit:
The problems of the indirect, recursive, linked directories is solved.
Still getting downloads from the /tools directory that are not required, but that is because those files are dated on the server in the future. So that will "fix itself" as soon as the calendar catches up with the Tizen time-warp.
(and some of their *.jar files contain files that where created two weeks __after__ the jar file was last modified. Them *.class files must be reproducing inside of the jars.)

Edit 5/29/2012:
Still playing "catch up" with the Tizen.org server cluster clocks.
If I decide to follow this distribution's download sub-domain for more than this initial 30 days, will have to patch wget's timestamp matching routine. As if wget didn't already have enough options.

[twobob]

+1 for awesome.

we would need people "on board" though. quite a few I would guess