|
hi all
the last time i was doing sth for hdw... the hdw
structure wasn't so nice, this might be caused by base implementations... alike,
"in architectures and software.. things move around the implemented
base".
i am not bothering, and i am not a native hdw
developer.. and i ve been apart of this stuff during several months, but what i
think is that hdw implemented base was done still with testing purposes. at
least last time i left hdw we discused this. hdw needs a
new implementation and may cause a different version (cause of
substantial changes if these are given).
ive learned that "implemented base" in
architectures and massive software is the one which defines complexity in
the project. conforming project grows, added stuff is related around of the
installed base. and therefore is recommendable (cause of possibly large changes)
put new stuff around installed base instead of modifying this one to get rest of
stuff working propertly too.
for example.. if i desing a software code model,
with an interface which will be the "core" of future implementations (cause this
decide how the rest of stuff will work) and i want to add what i will call
"objects" or "modules".. might be many of those, i should ensure that
those objects will be treated with the same maneer than others.
if suddenly i note that one of the "objects" i want
to add doesnt fit the rules to be managed by the "core" section, the best thing
i could do is to change "object" model to make it fit in the mode defined by the
"core". otherwise, if i modify installed base or "core" part, it's possible that
this will produce inconsistent and ugly code, that in fact, doesnt correspond
with other object model ive used with the other "objects" already added.
Other solution is the "expensive" and massive
morfism, which consist in make change the current "objects" models, to also make
them similar to the new code model i am incorporating with this new "object"
which is causing confusion. aside, this idea will spend much time and it's
common to see that the code of everthing (core and objects) will increase, not
so efficient.
the last solution, and not liked by many people..
but fastest one. is the choice of ignoring the code model presented by this
new object, and just reject it with its stuff. although it is not a good
solution for many people, this could be the best one in environments where those
object models are not common and possibly not so important for the complete
software specification, and time and money is valuable.
ummm..
so !
my point here is to demonstrate some way that hdw
implementation model is cool by the moment.. but like evolution story.. things
change.. and they should mutate to fit new objectives. In this
case, with several purposes:
*
make software developer coding easier
*
distributed code environment
- integrated development around a futurist and open
base
- new object models which share features decided by
base
- independant objects themselves and dependant objects for
base.
* distribution
main focuses and purposes. relative to targets too.
* current
software models for an easier objects fit in the new base.
*
users
those are strongly my main purposes with the
development of a new hdw version. i dont want to see hdw left behind cause a new
idea wasnt incorporated cause base implementation didnt allow this. with this i
do not mean the current state of hdw is bad. instead, i see beyond.
other thing preocupate me is the amount of
developers now working in hdw. i know that most of people who want to help and
colaborate with hdw can't dedicate full time to this.. and at least, package
maintenance is a hard work.. and this is my main focus when i say this. i thing
that if people want to see hdw up-to-day and satisfacing needs .. many hands
should be used to make this possible. if u support me... i'll try to get
interested people to support hdw.
feel free to critic those aspects:
* spend some
time making an analysis of current problems and proposes.
* list shared
characteristics of packages hdw will work on
* describe and
discuss users, different hdw targets and their promotion
* patching and
developers source code management in the project
*
documentation. new users and developers must see this.
* code
modulation. that what we structured in scripts: "Download","Puzzle","Build"..
you know.
* complete
packages management discussion. this might be the most tedious thing here. how
to distribute packages configuration files.
* hdw build
settings. previous build procedures, build procedures, post build
procedures.
* hdw install
settings. previous install procedures, install procedures,
post install procedures.
* build
settings. how to build hdw. a cool way to make build powerful and
efficient. * build
stages. * upgrade
support. most people like to see systems up-to-date.
* system
configuration. support users and developers a nice interface to simplify system
administration.
** there are a
lot of other aspects.. i can't remember all of them now.. but i know they will
surge with time.
remember i am just another voice and opinion.
i am not saying "good bye hdw"... i am saying
"hello hdw.. u will stay a long time with people".
those are aspects i suggest to analize. i am not
suggesting now my opinions about implementation, not until things will be
discussed.
as i said before with my previous example.. the
fastest and cheap solution is to ignore new object models that comes
and that things continue as they are.
but i wonder if ignoring new object models and
things that grow around will be the best solution. other people are not
tied with hdw, hdw should be tied with other people. this is not
comunism.
the only thing i ask for is to notify me what u
think clearly. i dont ask for anything else.
excuse me for the talk if i am bothering. just
giving my opinion as the hdw list if for i guess.
simply,
Demian |