Karrde712 writes
"Fedora Cloud Architect Matthew Miller announced a proposal on a plan to redesign the way that the Fedora Project builds its GNU/Linux distribution. Fedora has often been described as a 'bag of bits,' with thousands of packages and only minimal integration. Miller's proposal for 'Fedora.Next' describes reorganizing the packages and upstream projects that comprise Fedora into a series of 'rings,' each level of which would have its own set of release and packaging requirements. The lowest levels of the distribution may be renamed to 'Fedora Core.' Much discussion is ongoing on the Fedora Devel mailing list. If any Slashdot readers have good advice to add to the discussion, it would be most useful to respond to the ongoing thread there."
A
full presentation on the plan will be given at the Flock conference next month, and
draft slides have been uploaded. A few more details about the discussion are below the fold.
Karrde712 continues, Discussion on the list has questioned whether this is meant to be a return to the old "Fedora Core" and "Fedora Extras" model of Fedora's early life, to which Miller responded: 'I'm aware of this concern — I was there too, you know. As I was talking about the idea with people, it kept being hard to not accidentally say "core". Finally, as I was talking to Seth Vidal, he said, in his characteristic way, "Look, here's the thing. You should just call it Fedora Core. If you don't, people are going to be grumbling in the back corner and saying that it's really Core, and the conversation becomes about a conspiracy about the name. Just call it Fedora Core, and then have the conversation about the important point, which is how it's different."'
I pretty much left the software development world when all this "Agile" bullshit became popular.
Over the past decade there has been an explosion of methodologies and metrics to coincide with a stagnation in fundamental developments in engineering. Contrary to what the young'uns think, there is very little that's appeared on the software scene that wasn't already there - and written more efficiently - either on the desktop in the '90s, or on the mainframe/cloud in the two decades prior. But what we do have is a whole pile of paperwork, of admin, of things to remember about how you're supposed to be doing things, of new ways to make creativity just that little bit harder.
So there is an *explosion* on all the new platforms of very similar software products, all developed the same way.
Stop it. Find out what works in your organisation, and evolve incrementally. Don't look to claims of revolutionary buzzwords.
If you're concerned about packaging you're in marketing not software development, why not just spend hours talking about the colour of the box and be done with it. This is one of the reasons why debian is making inroads into the enterprise space. Less colour and more bang. Once many years ago I thought that Debian wasn't for business use and only redhat was a contender in this space and I fought hard to standardize on this supported model. Since then the packaging quality of debian has demonstrated its robustness and redhat has been focusing on other things.
Seems to me that when I'm working on a build with security in mind, I start with a bare build that is the barest of essentials to boot the system and use the hardware. From then, we add on the packages we need to get just what we need. And as we layer those packages on, we focus on the hardening of the individual services. As time has gone on, in a virtualized environment, it's very easy to build "default" systems that fill certain roles and are sized for different resource levels. It would seem to me that these standardized baselines would serve well for an installation model. Fedora does that to some extent (loosely) but that could be built upon more I would think. So if I want a firewall, I could get a bare boned installation with enhanced iptables rules and hardening provisions commonly used. Or if I want a web server, perhaps a slightly less bareboned installation with the needed scripting tools (PHP, Perl, etc?), etc... It seems the biggest questions I've dealt with when building new systems is, role, size, and whether or not it's for development. Outside of that, the builds are rather typical.
Select from tblFriends where interesting >= 4;
In order to get Linux growing is a similar thing. ...
A "ring0" with a very basic system on top of which all other distros are based.
This would avoid everyone re-inventing the warm water multiple times, while distros would focus on the other rings.
More or less the same as is seen in FreeBSD with the "GIU"derivatives.
A controlled ring0 would focus on keeping the system up and running at the very best with a centralized repo for everyone.
But you may say i am a dreamer
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
What makes this AGILE?
Sounds to me like they're talking about Debian, the way it's integrated and layered.
As a Debian fan who's often asked to administer RH boxes, this would be a welcome change.
Never eat more than you can lift -- Miss Piggy
There's more truth to this post than I'm comfortable with, actually. How sad is it when people can't just articulate a clear plan of action - something that anyone familiar with Fedora would be able to, you know, start hacking away on.
A successful API design takes a mixture of software design and pedagogy.
If you really want to make Fedora better get rid of gnome3.
73 49 111 01001001
- Make the distro more "exciting"
I'd be excited if upgrades weren't an ugly afterthought. Y'know, because everybody has to do it at least once a year.
If it takes this 'ring' idea, to force the upgrade issue, and perhaps versioned packages outside of kernel-*, then I'll get behind it.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Fedora itself is a relatively small, bare distribution.
There are fourteen thousand software packages in Fedora.
it doesn't come with codecs, Flash, any proprietary repositories, VirtualBox, etc. That's why Adobe, Oracle and RPMFusion exist, they are add-ons to the core of Fedora.
Which only contain a few hundred packages, mostly due to licensing issues that Fedora doesn't want to tackle (have an argument with the government over).
No thank you, I'll stick with an all-in-one set up like Mint or Debian.
Adobe doesn't even run a repo for Debian and its packages rely on downloading binaries raw, without repo support. It's good that the intermediate packagers make the effort to stay on top of vendor updates, though.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
So they're basically "reinventing" how BSD does things? They even blatantly copied an OpenBSD image for this presentation...
(Compare slide 13 from the presentation with OpenBSD 4.9 art)
In all seriousness though, it's a pretty good plan. Everyone knows that BSD means real engineering while Linux is "just a hobby, won't be big and professional"
Unless all 14000 are preinstalled you aren't exactly disproving them.
To further the comment on the huge size of the "Everything" repository that is Fedora - I think F18 x86_64 is around 40+ Gb with updates, so, yes it is a huge distribution.
I think it would be great if they would get off this release everything every six months kick they're on and figure out something better. If rings helps them get this accomplished, that's fine. I hate to think of the number of packages that get recompiled just to change the name of the package from f17 to f18 to f19 with no substantive other changes.
If the rings let them alter their dependency tree from works with version x of lib x to works with at least version x of lib x on more outer ring fluff, I'm all for it. This is particularly true for all the font and game and other data packages where large blobs of data that probably didn't change from one release to another just get reissued with a new name.
The KDE group already releases their desktop for all non EOL versions of Fedora. I'm sure it costs them a bit of extra care to do that, but they manage. They're a great ring. It's the synchronization with some of the other same level rings like Gnome that give them fits.
The biggest issue is that some of the low level ring changes will force lots of next layer ring changes anyway that will propagate out, so in the long term I'm not sure if it will really fix the problem. But if it would slow down the massive changes in the outer application ring that in the old days wasn't even part of Core and allowed them to just update individual packages when needed to because of a library incompatibility in a lower level ring but otherwise didn't release a new version unless the software functionality was upgraded, that would be great.
Back in the day (circa 2001, so RH 7 thru 7.3) before RH adopted YUM and the entire distrubtion fit on 1 CD, I was constantly frustrated by the unexplainable need of RH to make packages depend on completely unrelated stuff. I swear you couldn't install a 10kB console text editor without installing 50MB of dependencies. What possible reason could a console editor require libjpg? Things like that were common. IIRC, before YUM you had to type in every single package name x 20 or so packages (with exact versions like libjpg-rh7.1.2.3.0-i386.rpm); this was a serious hassle.
When it became time to move to another system, I went with Debian (woody I think) because the implementation was cleaner to begin with and APT was a godsend for dependency resolution. I say the implementation was cleaner, because even when reduced to using dpkg instead of APT, I usually only had to type in two or three dependencies, whereas I remember many more installing the same on RH.
So, yes. If I was still using RH/Fedora, I would love a clean and elegant (agile if you like buzzwords) implementation without all the extraneous crap.
I'd be excited if upgrades weren't an ugly afterthought. Y'know, because everybody has to do it at least once a year.
If it takes this 'ring' idea, to force the upgrade issue, and perhaps versioned packages outside of kernel-*, then I'll get behind it.
Good, because those two things are exactly what this is all about.
It would be hard to imagine a better recipe for epic failure. It seems that the proponents don't realize that the less baggage it carries, the more robust and easy to use a distro becomes.
I have to say, I'm not entirely sure you've read this proposal. Or maybe there is something that could be more clear? The audience here is really Fedora developers, so it's likely that some things aren't immediately apparent if you're more removed from that. Overall, this is a proposal for significantly less baggage.
And "excitement" is definitely not needed. An operating system isn't an electrical appliance needing new excitement and frills to shift product off the shelves each season. Boredom is a sign of stability and reliability, and those two are without doubt most important features a distro designer can provide.
Well, Fedora isn't ever going to be that completely safe kind of boring. For that, we have our downstream distributions, which are awesomely boring in all the way you describe. Fedora isn't supposed to be that, and is supposed to be in place where we are generating excitement, whether that's at the OS core or further out. But in general, the idea here is to separate out that "no frills" core from the language stacks and other areas where "be up to date" and "make available the exact things we need" are the demands. Then, we can address these needs differently.
If you're just interested in the base, awesome: we will put that together for you in a well-defined way and let you do whatever you want on top of that.
Having the separate ring 1 lets us focus on making that a coherent base which can be enhanced in an cohesive way which doesn't break everything for users as we go from release to release.
Question all you like. I don't mind. However, I'd really prefer questions to the trolling. *
Which, given all the posts, by tibit, I have to assume is the case. If I were to take it seriously, though, I would say that probably what's happened is that much of the concrete part of the proposal uses labels which are unlikely to be familiar to someone not active in Fedora development (Fedora Formulas, Software Collections) without explaining them. You might know OpenShift, but "OpenShift Gears, decoupled" just sounds like gibberish. Even the term "base design" sounds vague but actually relates to a specific ongoing effort (http://sched.co/11El9OZ).
I didn't really think about how this would read to an outside audience, because Fedora developers are the intended audience, and because this is a presentation, not an in-depth white paper.
(* I know, I know, am I new here or what?)
you know how sometimes you run into a word a few times, then don't see it for years, then this word pops into your head for some unknown reason and a day or two later, BOOM!, there it is.
kinda freaky.
anywho, the word in this case is 'remunerated', which you misspelled here 'renumerated', which is kinda how it was brought to my attention years ago.
and stay off my lawn.
I have plenty of common sense, I just choose to ignore it. -- Calvin
to rule them all! Of course, you insensitive hobbit clod!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.