Re: [MiNT] Pending patches review

[MiKRO <miro.kropacek@gmail.com>]

Hi,

> We have 3 problems:
> 1. Packages don't get approved quickly enough
> 2. There's no suitable environment to test packages that might break things
> 3. Since we are static linking, there's no way to include packages for
> users with faster CPU.  Everything is optimized mostly for 68000 yet we
> probably have no 68000 users!
>
You're completely right. I especially agree with point #3, I remember
that _INCREDIBLE_ speedup when I compiled quake with gcc 3.3.6-m68k
and gcc 3.3.6-m68060. And this goes for everything -- bash, sed, grep,
awk... everything compiled for 68k... our systems need every spare
cycle from CPU and this could make 20-40% speed for whole system.

> 1. A dynamic website running on a linux server in PHP.
I agree completely.

> 2. A build farm.  Using php or bash scripts, this build farm would be 6
> or so aranym instances which would each run a fully different version of
I think we don't need 6 instances, gcc&stuff are quite universal,
there's no problem to have 3 gccs, 3 different libs (000, 030, 060,
...) and to use right one each time. It's just matter of passing right
path to gcc to ./configure process. The same for mintlib, there's easy
way how to tell gcc when use what library.

> 3. SUM or Sparemint Update Manager.  A combination GEM/console program
Also with dependency tracking? Something a la yum?

> MUCH of this functionality is DONE.  The website is mostly done, the
wow.

> 20GB+ diskspace to devote to sparemint.
>
and this is much? 20 GB has to be really for everything including
sources, builds for each target etc...

> People would be able to on a whim use the sparemint update manager to
> replace every package on their system with the 68060 optimized version,
> or things like that.  While the system is statically linked this would
> be safe and easy to do to a currently running system.  Think of the
> possibilities.  Only thing required is TONS of bandwidth on the server.
>
This would be awesome. Bandwidth... hm, maybe yes, in general term but
let's face it -- even if we manage to catch very atari user with
TT/Falcon030/40/60/Aranym to use freemint... do you really think it
would be thousands of downloads each day? As I see it, 90% traffic
will be made when some major release arrives (i.e. start of the portal
;-), then only few RPM downloads here and there. I think nothing to
worry about. Certainly no need for 1 GB fiber net ;)

> this a couple years ago and very few people have noticed or cared.
> What's the point of such work and expense?  I already have the available
> server and diskspace but it's at my house and thus my house needs to the
> bandwidth and static IP.
I think the problem is bad propagation. As you see, even me, guy who
cares about mint&stuff didn't know about it. I bet I'm not alone. I
think I have the way out of this:

- make this happen :)
- if you say the only remaining stuff is to configure aranym, then
great. if you encouter any problems, I'm sure people in aranym-list
will be glad to help (this was the initial purpose of aranym, right?
to bring new, powerful machine for freemint development)
- if you need some help with that GEM SUM, I'm also sure someone will
help you, if not, I volunteer :)
- and here it comes... the final, absolutely necessary point is to
make... DECENT DISTRIBUTION. Easymint, that's not what I call a
distribution. It's good for fast install but it lacks configurability,
flexibility... and still unusable for MagiC newbies

I think I can say it now, for the past few weeks (or days, to be
precise, hardware problems rule) I'm working on it. Yes, on a
distribution :) That doesn't mean just taking RPMs and code some
copy-and-install tool but full-featured wizard in as we know from
Fedora, Ubuntu & co. Not just fast hack but GEM application with
hints, explanations, roll-backs, multiple options, preconfigured
environment, ... The main point is to show people FreeMiNT != that
strange stuff with console but full-featured OS. I think this is the
problem of aranym, too. Start AFROS and what you'll get? Unusable
desktop in black and white (Emutos) or nice coloured XaAES with...
nearly nothing. This is everything but motivation to leave 'that nice
MagiC'.

I plan to do it in 4 steps:
- code the installer. as user friendly as possible
- use existing RPMs (no recompilation or anything)
- recompile these RPMs for 68060 using gcc4
- one-by-one replace (the most important first -- bash, coreutils,
sed, awk & stuff) old RPMs by new ones (I use some SRPMS from fedora 8
already).

As you see, you site would be very, very, very helpful in this case :)

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org