I see that yum 4 was released for CentOS in testing recently. What does this mean for the future of yum and dnf for Fedora and RHEL. It seems like it will be difficult to maintain yum v3, v4, and dnf simultaneously across different OSes. Are there any plans to merge these projects across the Red Hat platforms in the nearterm?
Yum 4 is a frontend backed by DNF. Yum 3 is on its way out; not my area but I expect it will be maintained for the life of the RHEL versions that depend on it, but only for security updates and any very serious bugs.
I'm not sure what we'll do in Fedora with the DNF vs Yum 4 name.
> RPM [...] Example: still uses mainly file-based dependencies
That's not true. It _can_ but primarily does not use file-based dependencies. I think, realistically, from a packaging perspective, you'll find places where both RPM and deb suck, and where they both have strengths — it's kind of half-a-dozen-of-one, six-of-the-other. From a user perspective, it barely ever matters even a little bit.
> Another example: executable scripts to initialize network interfaces.
I assume you mean the legacy ifup/ifdown scripts? The primary and default path is NetworkManager, instead. Or did you _want_ this done with shell scripts? Unclear from your post.
Not many people want to reload their OS every 6 months.
Supporting a release for an extended period of time is very expensive, both in terms of actual money but also in demands on volunteer time — and despite Red Hat sponsorship, Fedora is largely a volunteer project. We could choose to focus on a longer lifetime, but that would come at the expense of other areas (like bringing new tech to users quickly while still doing a decent amount of QA). So, instead, we've worked on making upgrades as painless as possible. You definitely don't need to reload your OS every six months — you can do an update, which in this release took me about 25 minutes, the first five-ten of which were downloading the needed packages while I kept working, and the rest could have happened while I went for coffee. Additionally, we test upgrades from not just the previous release, but one back, so if you want, you can take this half an hour once a year rather than every six months.
No secret deals, double or otherwise. Fedora does not work like that.
I mean, except for our deal with the Knights Templar to make systemd the one true init system of the new world order. That one, we did do, but it's triple-secret, so can only be revealed in Slashdot comments.
There is currently some support for this in GNOME (and therefore Fedora Workstation), but it's rudimentary. Some technical bits about this here: https://wiki.gnome.org/HowDoI/.... A lot of the software just wasn't made for it, though, so it's going to be a bit of a bumpy road.
This is basically due to a misconception around the Fedora release policy. Some projects work on a strict calendar basis; others work on "release when ready". Fedora has always had a hybrid approach. We aim for a certain target, but we're integrating a huge amount of upstream software over which we mostly have little control, and it's almost inevitable that something isn't up to standards at that time.
I thought it might be just the summary, but I read TFA. What in the world are we talking about here? This is slashdot, not the evening news or something. Is "app slicing" a fancy word for "we only give you the bits you need for your architecture?"
It depends on whether they plan to use this feature to sell more TVs.
Merely allowing the site to be accessed through the product features is not commercial by itself, but if the links are included by default in a prominent place (and we know they will), that counts as product placement and branding; and it can definitely be considered a commercial purpose - people pay money to that kind of placement.
I'm not saying that this interpretation is necessarily wrong, but... it's quite wide in scope. It seems like you are saying that not only would hosting NC content on a site with ads be disallowed, but that merely prominently linking to such content from a site with ads would be disallowed, as would any advertising for any commercial software or hardware which implied that NC content could be accessed.
Furthermore, the suggestion that if some people sometimes pay for a particular activity, then all instances of that activity must be commercial in nature -- wow, now that has some implications!
This is exactly the problem with "NC". To you, this is "clear commercial use". Is it because a big company is involved? Two companies? We assume money is changing hands, but... maybe it's not. The license says "primarily intended for or directed toward commercial advantage or private monetary compensation". What if the money goes towards "supporting the community"? What exactly is "commercial advantage" in this context? I'd have to ask a lawyer, and... unless I was paying them to advise on a specific case, I doubt they'd actually give a straight answer.
Overall, "noncommercial" licenses are problematic and should be avoided. I understand the intention, but it's hard to make a license that actually gets there.
I don't think it's size, exactly. The Boston urban area has roughly the same population as the Houston metro area (about 4 million), and we've got the 250MB data cap. And we even have (some) competition -- some of the richer suburbs have Verizon FiOS, and many neighborhoods (like mine) offer RCN (which, in my experience, is both faster and cheaper, but also more prone to outages).
Back in the 1990s, I helped run one of several mirrors for CDDB. When the company suddenly took a proprietary turn, they shut all of those down. They sent message promising to give some sort of reward to everyone who had run a mirror, but nothing ever showed up.
I guess a couple of million would probably make it up....
In seriousness, this was an early wakeup call about contributing to "community" projects without clear licenses for submitted data. And here I will put in a plug for FreeDB, which forked the original and continues to run it in an open way, with submissions under the GPL. http://www.freedb.org/en/about...
This makes it sound like a long-lost native civilization was discovered. Not the case. Early European settlers in New England devastated the native landscape and, basically, turned it into English sheep farms. As expansion pushed westward and agriculture shifted with it, that economy changed and native (and some invasive) species have reclaimed the landscape.
Still very cool and interesting, but a different story from what you might expect from reading the lede.
I feel your pain. I wish Fedora would go to a 9 month update schedule, it would make me happier.
We probably won't go to 9 months permanently, but it's very likely that Fedora 20 -> F21 will be along those lines as we retool for Fedora.next ideas, and work on improving qa and releng automation.
I think we should focus discussion on the specifics of the guy's proposal.
Thanks, I appreciate that.:)
I could definitely have chosen "flexible" or "nimble" or some other random adjective. It didn't quite just pop into my mind, though -- I'm definitely familiar with the agile programming movement and have seen it in action in very positive ways. (I'm sure it can go horribly wrong, just like anything.) So, the title isn't completely an accident. I do want to evoke some of the agile manifesto: focus on interactions and individuals, responsiveness in the face of change, and so on. In general, I think we need to make some room for "worse is better" underneath the Fedora umbrella (while still keeping the core to a "the right thing" model) -- that's not agile in specific but is part of the same vein from which it developed.
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.
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.
As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.
MySQL and spinoffs all occupy an uncomfortable middle ground. 99% of the small web sites which are built around MySQL don't need it.
I don't know if kids today remember, but Loki Games was one of the first commercial plays for big name games on Linux. Ended in tragic business troubles and financial doom.
It warms my heart to see that Sam Lantinga is still working on SDL.
I really hope that people won't give in without at least expressing their anger to Comcast by finding another ISP if available, when they implement tiered pricing.
"If available" is the catch here. Comcast has a near-monopoly on broadband service in many parts of the country. Some places have the luxury of a second cable provider like RSN, but mostly, the other choice is more expensive and much slower DSL. Some places have Verizon FiOS, but apparently they're pulling back on that as well.
Slashdot Mirror
I see that yum 4 was released for CentOS in testing recently. What does this mean for the future of yum and dnf for Fedora and RHEL. It seems like it will be difficult to maintain yum v3, v4, and dnf simultaneously across different OSes. Are there any plans to merge these projects across the Red Hat platforms in the nearterm?
Yum 4 is a frontend backed by DNF. Yum 3 is on its way out; not my area but I expect it will be maintained for the life of the RHEL versions that depend on it, but only for security updates and any very serious bugs.
I'm not sure what we'll do in Fedora with the DNF vs Yum 4 name.
Okay, I'll bite:
> RPM [...] Example: still uses mainly file-based dependencies
That's not true. It _can_ but primarily does not use file-based dependencies. I think, realistically, from a packaging perspective, you'll find places where both RPM and deb suck, and where they both have strengths — it's kind of half-a-dozen-of-one, six-of-the-other. From a user perspective, it barely ever matters even a little bit.
> Another example: executable scripts to initialize network interfaces.
I assume you mean the legacy ifup/ifdown scripts? The primary and default path is NetworkManager, instead. Or did you _want_ this done with shell scripts? Unclear from your post.
For whatever it's worth, Steam runs just fine on Fedora.
Supporting a release for an extended period of time is very expensive, both in terms of actual money but also in demands on volunteer time — and despite Red Hat sponsorship, Fedora is largely a volunteer project. We could choose to focus on a longer lifetime, but that would come at the expense of other areas (like bringing new tech to users quickly while still doing a decent amount of QA). So, instead, we've worked on making upgrades as painless as possible. You definitely don't need to reload your OS every six months — you can do an update, which in this release took me about 25 minutes, the first five-ten of which were downloading the needed packages while I kept working, and the rest could have happened while I went for coffee. Additionally, we test upgrades from not just the previous release, but one back, so if you want, you can take this half an hour once a year rather than every six months.
No secret deals, double or otherwise. Fedora does not work like that.
I mean, except for our deal with the Knights Templar to make systemd the one true init system of the new world order. That one, we did do, but it's triple-secret, so can only be revealed in Slashdot comments.
No secret deals, double or otherwise. Fedora does not work like that.
There is currently some support for this in GNOME (and therefore Fedora Workstation), but it's rudimentary. Some technical bits about this here: https://wiki.gnome.org/HowDoI/.... A lot of the software just wasn't made for it, though, so it's going to be a bit of a bumpy road.
This is basically due to a misconception around the Fedora release policy. Some projects work on a strict calendar basis; others work on "release when ready". Fedora has always had a hybrid approach. We aim for a certain target, but we're integrating a huge amount of upstream software over which we mostly have little control, and it's almost inevitable that something isn't up to standards at that time.
PS: We're slipping a week for F23. :)
Fedora 24 will be next May; we don't really do point releases, but I guess if you apply patches sometime in July you could call it Fedora 24 1/4.
I thought it might be just the summary, but I read TFA. What in the world are we talking about here? This is slashdot, not the evening news or something. Is "app slicing" a fancy word for "we only give you the bits you need for your architecture?"
It depends on whether they plan to use this feature to sell more TVs.
Merely allowing the site to be accessed through the product features is not commercial by itself, but if the links are included by default in a prominent place (and we know they will), that counts as product placement and branding; and it can definitely be considered a commercial purpose - people pay money to that kind of placement.
I'm not saying that this interpretation is necessarily wrong, but... it's quite wide in scope. It seems like you are saying that not only would hosting NC content on a site with ads be disallowed, but that merely prominently linking to such content from a site with ads would be disallowed, as would any advertising for any commercial software or hardware which implied that NC content could be accessed.
Furthermore, the suggestion that if some people sometimes pay for a particular activity, then all instances of that activity must be commercial in nature -- wow, now that has some implications!
This is exactly the problem with "NC". To you, this is "clear commercial use". Is it because a big company is involved? Two companies? We assume money is changing hands, but... maybe it's not. The license says "primarily intended for or directed toward commercial advantage or private monetary compensation". What if the money goes towards "supporting the community"? What exactly is "commercial advantage" in this context? I'd have to ask a lawyer, and... unless I was paying them to advise on a specific case, I doubt they'd actually give a straight answer.
Overall, "noncommercial" licenses are problematic and should be avoided. I understand the intention, but it's hard to make a license that actually gets there.
I don't think it's size, exactly. The Boston urban area has roughly the same population as the Houston metro area (about 4 million), and we've got the 250MB data cap. And we even have (some) competition -- some of the richer suburbs have Verizon FiOS, and many neighborhoods (like mine) offer RCN (which, in my experience, is both faster and cheaper, but also more prone to outages).
Back in the 1990s, I helped run one of several mirrors for CDDB. When the company suddenly took a proprietary turn, they shut all of those down. They sent message promising to give some sort of reward to everyone who had run a mirror, but nothing ever showed up.
I guess a couple of million would probably make it up....
In seriousness, this was an early wakeup call about contributing to "community" projects without clear licenses for submitted data. And here I will put in a plug for FreeDB, which forked the original and continues to run it in an open way, with submissions under the GPL. http://www.freedb.org/en/about...
This makes it sound like a long-lost native civilization was discovered. Not the case. Early European settlers in New England devastated the native landscape and, basically, turned it into English sheep farms. As expansion pushed westward and agriculture shifted with it, that economy changed and native (and some invasive) species have reclaimed the landscape.
Still very cool and interesting, but a different story from what you might expect from reading the lede.
I feel your pain. I wish Fedora would go to a 9 month update schedule, it would make me happier.
We probably won't go to 9 months permanently, but it's very likely that Fedora 20 -> F21 will be along those lines as we retool for Fedora.next ideas, and work on improving qa and releng automation.
I think we should focus discussion on the specifics of the guy's proposal.
Thanks, I appreciate that. :)
I could definitely have chosen "flexible" or "nimble" or some other random adjective. It didn't quite just pop into my mind, though -- I'm definitely familiar with the agile programming movement and have seen it in action in very positive ways. (I'm sure it can go horribly wrong, just like anything.) So, the title isn't completely an accident. I do want to evoke some of the agile manifesto: focus on interactions and individuals, responsiveness in the face of change, and so on. In general, I think we need to make some room for "worse is better" underneath the Fedora umbrella (while still keeping the core to a "the right thing" model) -- that's not agile in specific but is part of the same vein from which it developed.
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?)
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.
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.
As a general rule of thumb, if you need something lightweight, SQLite is the way to go. If you need something more powerful or sophisticated than that, PostgreSQL.
MySQL and spinoffs all occupy an uncomfortable middle ground. 99% of the small web sites which are built around MySQL don't need it.
Actually, this apparently comes from Dell's acquisition of Wyse. That is, these guys: http://upload.wikimedia.org/wikipedia/commons/thumb/7/72/WyseTerminal100.jpg/220px-WyseTerminal100.jpg -- the people who *did* do this decades ago. So, I guess, fair enough.
In Massachusetts, it's the law. http://www.mass.gov/courts/jury/compensa.htm#INFORMATION%20FOR%20EMPLOYERS:%20RIGHTS%20AND%20OBLIGATIONS:
I don't know if kids today remember, but Loki Games was one of the first commercial plays for big name games on Linux. Ended in tragic business troubles and financial doom.
It warms my heart to see that Sam Lantinga is still working on SDL.
That is all.
I really hope that people won't give in without at least expressing their anger to Comcast by finding another ISP if available, when they implement tiered pricing.
"If available" is the catch here. Comcast has a near-monopoly on broadband service in many parts of the country. Some places have the luxury of a second cable provider like RSN, but mostly, the other choice is more expensive and much slower DSL. Some places have Verizon FiOS, but apparently they're pulling back on that as well.