Hey Christoph, You are quite right of course, I should know better than to actually _send_ a late night cranky rant, and any point the first paragraph introduced rapidly got lost in the handwaving from there. And if you got the impression I'm against making things simpler and more friendly, then I definitely blew it -- because that's actually the advantage that I'm worried you are at risk of losing here.
If the things that have worried me about some recent suggestions here were easy to explain and well understood then I wouldn't have to explain them, but I'll try to point out a few key ones for consideration a bit more coherently... just remember, you asked ;) - I'm not against supporting eclipse users, but if that is The Answer to making this "user friendly", then you've already lost. It needs to be simple, well structured, and have a strong self consistent logic from the lowest levels up. If it has that, it will be friendly, not just to the developers hacking at that level, but also to the people layering on support for various IDEs, and users of every level. If it's not, the "framework" that you create will be incomprehensible to all but the tiny handful of people who are hacking on it every day, and who can't understand why everyone else doesn't realise just how simple it is to use. That you can drive it with drag and drop and button clicks, instead of command line operations, will never be able to hide that fundamental flaw, and to the extent that it can hide it, it will be to make the system extremely inflexible, for any use out of the norm. For embedded development, where every system is, somewhat by definition, out of the norm, that's not a minor problem. What you can get away with if you are making GUI applications constrained by someones HI guidelines is totally inappropriate to apply at this level. - slindets itself I can't really comment on in depth just yet. I've looked over the script, but I've yet to see any real specification for exactly what problems in the existing system it seeks to solve, and what principles it applies to solve them well. I don't want to sound unfair to the people who put their effort into that, but the discussion here seems to be a bit "ok, here's my latest crack at it", followed by trying to reverse engineer what benefits it may have. That's a perfectly ok thing to do, and I'm sure there was lots of discussion that I'm not privy to that went into this as well ... but some of the supposed benefits would seem to fairly greatly overestimate how easy they will be to realise, or how desirable it would be to try at this stage. And it's not clear if they were actually a part of the design criteria, or something projected onto this in hindsight. - I see a lot of kneejerk about making this all "more agnostic", and "less tightly bound to debian" -- which in the same breath often proposes reliance on some other constraint, such as eclipse or home grown replacement tools, to cover for things that you'd lose which didn't otherwise need reinventing yet. And yes, since the observant will have noticed that I've been subscribed to this list, and contributing when I have with a debian hat on, I'm not going to preach about how debian is So Much Simpler and the One True Answer here -- the truth is, I don't really care much which system you choose for managing packages if you have good technical reasons to back that up -- but I can tell you with a straight face and a hand on my heart, that if you don't choose ONE of them, then you are setting yourself up to fail, because supporting them _all_ is a hard problem that no-one has yet solved well. Lots of people have tried, and maybe some people here would be happy for their employer to fund yet another attempt at that too, but IMO it is a MAJOR distraction from the value-add that slind is ostensibly seeking to provide, and an 'optimisation' that is considerably premature. A large part of the reason that slind might currently be considered 'unfriendly' to some is the sheer number of slind-specific operations that are currently required to do all the things that you want it to do. If you want to make this truly friendly that number needs to be reduced not increased. Trying to support any package format, and taking more direct responsibility for things the package systems already handle increases the number of slind specific things you need to reinvent, and the result is almost certain to be a system that is incompatible with all other systems on some level or another, and probably more confusing and limiting to use too. What you should be identifying is the problems that aren't slind's to solve, which you currently workaround but which should be punted back to debian to provide out of the box for you. That makes your problem space _smaller_, and in turn makes it much easier to keep it simple, friendly, and quickly familiar. It also stems the tide of the massive division in resources that we currently have to devote to this. There are already so many projects working in entirely separate, isolated, and incompatible directions that the developer pool is spread very thinly among them. All of these projects are under-resourced for the amount of work there is still to be done, and they are almost all reproducing what the others are doing at the same dribbling along pace. slind is just one leaf on a great big tree. As a leaf, it's where all the real energy is generated. But if the leaves don't feed the branches they hang off, and maintain a tight connection to it, the tree won't grow and the leaves will get ground mold, or eaten by rabbits or something ... I dunno, I don't want to get poetic again, but you get the idea. Anyhow, I've been distracted with other projects for a few months now, and probably will be for a few months more before I'm really looking at this full time again, so I don't really have any right to tell people who have been busy on this that they are Doing It Wrong, but reading some of this just added to what has otherwise been a rather disappointing week on many fronts, so I snapped and screamed. I do have a working system here that I'm using to build our rootfs from source though so I have few illusions about which bits are easy and which bits are hard, and which are currently still quite impossible (at least to maintain) until all of us agree on a few more of the fundamentals and responsibility for implementing them is delegated to the right people. So, if Maxim wants action points, here's a few, and no I won't be offended if the right ones get shot down for the right reasons (: - Pick a package management system, rpm or deb. Don't try to reinvent one, or pretend that they can be easily abstracted. This is not the rework you were looking for. Take the information that other people have already hand encoded for us and use it wisely. Don't be afraid to exploit the strengths of that system to their fullest extent. We are pushing the boundaries of traditional package management here, but not so far as to warrant entirely replacing that with something else. - Identify the things about slind that are hard or suck because either the package system or the packages themselves also suck. Research good answers to that. Open a line of communication to the people responsible for that and share with them what you learned. - Restructure grasp to better reflect a system that is trying to maintain the minimal possible changes from your upstream package source and that encourages a workflow of continually pushing those changes upstream with a constant aim of reducing their number to zero. - Work with the people already trying to figure out good ways to strip out just the parts of the packages that you really want on the rootfs. Different systems have different needs for this. Some systems want to be able to use the package management system on the device once it is up and running. Others will install on something like cramfs which makes that essentially impossible, so the packages only need to install even less again. If you try to reinvent this independently, you're going to be left on a ledge when someone else incorporates upstream support for their preferred mechanism. We are all diverse enough in our needs that any consensus will be difficult to come by, but if we commit to addressing _everyone's_ concerns in this process the quality of the resulting system will also reflect that deep perspective and we will all benefit instead of constantly treading on each others toes as we do now. - Write the tiny little scripts that will remain to automate the mundane tasks of building and installing a selected set of packages, for a selected arch, on a selected fs type. - Sell product. Eat. Drink. Be Merry. Add IDE support. Write a For Dummies book. Get promoted to senior management. etc. IOW. Most of the things you actually need code for here are either very simple, or already done by someone else. The Hard problem here is figuring out which remaining problems aren't "our" problem (speaking with a slind hat on), finding out whose problem they are, and coming up with some convincing arguments for why and how they should fix that. Grandiose plans to work around that without addressing it might keep a medium sized team in work for years, but it won't look so good on a resume when some other team presents a better working solution faster and your whole team gets laid off. There are enough hard problems here to solve to keep us all busy for a while -- but the key distinction to never lose sight of is that while many of them are well suited to be solved _by slind_ (meaning the people here), very few of the ones that tend to make this so messy really should be solved _in slind_ (meaning the repos and the support code). So there's some prose crib notes to make sense of the poetry for those who weren't already in the choir I was howling to last night. Use them as you please. I know what I need to do to play my part in all this, our system is currently simple enough that I can maintain it single handed if I need to, but it's still Yet Another Way To Do This, and so it's guaranteed to be a constant pain in my ass, however small, for as long as lots of other people are all throwing resources in conflicting directions. When I get back to hacking on that, I'd planned to share the cream of what I've learned from it here -- but if you guys abandon the core strengths that made slind an attractive base for some other definition of 'simple', then we won't really be solving the same problem anymore. Maybe I've misread where this is really heading. I certainly hope so. But from the outside, this looked a lot like the guys who whine that autoconf or GNU make is "too hard" for them to understand, and who extrapolate from that they they are somehow qualified to write a better replacement for it. I don't see a package management abstraction that can really hide the difference between rpm and deb _and_ have all the strengths of both when used to their fullest, any more than I see a viable replacement for autoconf and make. So when I hear talk of slind trying to get _further_ from exploiting the strengths of an existing well tested system and reinventing its own "friendly layer", alarm bells start ringing. Loudly. If the friendliness isn't intrinsic in the basic design, then this is an anti-pattern that I've seen often enough to be pretty sure that you really are Doing It Wrong. Even if I also fail to explain clearly (or politely), exactly how and why... There's more, but that's plenty enough of me shooting my mouth off for now, so I'll pass the cluebat to somebody else to winnow out my misconceptions first too ... Cheers, Ron On Fri, May 16, 2008 at 10:16:25AM +0200, Stueckjuergen, Christoph wrote: > I read your mail several times now and still I'm not sure if I got your > point. > What is it exactly that bothers you? Is it the Eclipse integration? Is it the > slindets tool? Is it the general idea to make Slind more user-friendly? > > Am Donnerstag, 15. Mai 2008 22:20:46 schrieb Ron: > > On Thu, May 15, 2008 at 06:03:50PM +0400, Maxim Osipov wrote: > > > For user friendliness we have "Slind Eclipse Integration", > > > > Oh Dear ... > > > > > where planned features are: > > > > > > - Slind package generation from project (in progress) > > > - Target rootfs generation (something like synaptic) (next step) > > > > ... and we'd bet slind would be a winner because you _weren't_ trying > > to reinvent what others had already got right to make this all easier > > (and actually maintainable in practice). > > > > Oh well. Back to Plan B for our project if this is what specification > > without vision will look like... > > > > But don't let me discourage you, if my welfare depended on this being > > a boundless and difficult problem to solve, rather than delivering a > > working product asap, then I'd be buying you beers for genius like > > this too. > > > > I can't begrudge another man his job security, but I fear this is where > > our ideas of what is "easy", "friendly", and not "tightly coupled", are > > going to quite rapidly part company. If you can convince the people > > that matter to you that you can make this simpler by reinventing from > > scratch all the bits that already deal with the hardest problems, then > > more power to you -- but if you want some genuine, shop floor advice > > on how to make things easier: then avoid the temptation to replace a > > widely used, well tested, generic system, that you find too hard to > > understand, with a buzzword powered framework that you think you might. > > > > That never goes well. Seriously. Even without the second generation > > engineering troubles. > > > > Anyhow, sorry to rain on your parade, but I genuinely don't want to > > see your seed shrivel before its time through some unfortunate, > > avoidable sunstroke. Plenty of people go blind staring at the sun > > through an eclipse -- and I'd feel more guilty if I found out later > > that maybe you would have listened if more folks suggested "don't > > do that" ... > > > > So I've said it. Flame me if you must. I'd personally rather that > > you just _prove_ me wrong if you really believe that you can, but > > the stakes you are playing for with this look a bit too rich for me, > > and I don't think this new game will be over before what we need > > should be put to bed, so we might have to cash out and spread our > > bets on some other tables if this is what slind wants to commit to. > > > > Sorry, but this really isn't _that_ hard, > > Ron > > > > > > _______________________________________________ > > slind-devel mailing list > > [email protected] > > http://lists.slind.org/cgi-bin/mailman/listinfo/slind-devel > > > _______________________________________________ slind-devel mailing list [email protected] http://lists.slind.org/cgi-bin/mailman/listinfo/slind-devel
