Public Bug Tracking and Open-Source Policy 118
Observer writes "Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy? A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature. Between Gnome's public bug tracker and similar trackers from distributions which released (and still distribute) the buggy version, months of debate provide an interesting case-study in the way front-line users and developers interact for better or for worse. What lessons can be learned here for release planning, bug triage, and marketing for a major open source project?"
+1 Transparency (Score:5, Insightful)
Transparency still beats all other alternatives.
Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.
Re: (Score:1)
Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.
Huh? If they're public and open, the end use can see them. What are you talking about?
Re:+1 Transparency (Score:5, Insightful)
I think he might mean that there is no "Show Forum Discussion" option during installation, likewise, the "Bug" section of a website is usually hidden under terrifying things like "Developer Section" etc, ie: unless the (average) user bumps into a problem and goes hunting online, or bumps into it randomly, they won't know about it.
Re:+1 Transparency (Score:5, Interesting)
Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.
Huh? If they're public and open, the end use can see them. What are you talking about?
My emphasis.
Re: (Score:2)
I see what you did there, you covertly pointed out the 'bug' in his 'user'.
Glad we caught that little bugger, lest we have a public discussion about it, and no one ever finds out.
Oh forget it...
Re: (Score:3, Insightful)
As with me and a few others of the true slashdot elite, you probably spend every spare waking hour of your life following the minute details of the latest comment to report of a bug in sylpheed alpha four; never even sparing a moment to read code or try to replicate the bug yourself. However, you probably have to accept that even most of the people on slashdot have something else better to do with their lives (or at least more exciting), for example watching the countdown to the end of 64 bit time_t and p
Re: (Score:2)
I think it is important to keep lots of communication between end users and developers, but htis needs to be appropriately partitioned.
End users don't need to see technical discussions of bugs. These don't belong on a -users list. They do need an opportunity to provide feedback on feature requests, etc. and these should be discussed on the -users list.
Also a few bugs really should be hidden from the public. Security or other sensitive issues ought to be discussed behind closed doors among the core deveop
Re: (Score:2)
No bug should ever be kept from the public.
If there is a critical flaw in one of my public facing systems and the maintainers send out a blast informing me of a zero-day security flaw I can evaluate the situation, consider triage through modifying my local security measures, or simply pull the plug.
It may be a PITA, but finding out that one of my servers was running around naked on the internet while the maintainers of a core product remained silent would be worse.
Re: (Score:2)
Were it that simple. In practice, I think the following practices are best for security issues:
1) Within 1 week contact the individual that reported the bug and provide a timeline that a fix will be in place.
2) Within a month, unless there are mitigating factors, there needs to be a fix available, security advisories filed, etc.
3) 2 weeks after the initial patch, there needs to be a full disclosure email describng in detail the original issue as well as how to exploit it.
For most security bugs, though,
The real lesson (Score:3, Insightful)
The real lesson here is that not all developers are good.
Open Source means that anyone can make changes to code. It doesn't mean that they should.
Re: (Score:1)
Yes, this is true. The point is, even companies who create software and don't release source code have pieces of shit developers as well.
A benefit of OSS is that the True Masters of Computer Programming who may be interested in a project but not yet a part of it can view the code and submit a patch (scrutinized by a group of his peers), and close the reported bug.
Sure errors still occur, but I'd be more worried that no bugs were reported for a non-trivial project, because it just means nobody's really
Re:The real lesson (Score:5, Insightful)
Open Source means that anyone can submit changes, but in order to be accepted into the code base, the project leaders have to accept the changes, so any well-run open source project has competent developers reviewing all changes. (You're technically correct in saying that anyone can make changes, but it's not terribly relevant unless those changes make it back into the main project.)
Re:The real lesson (Score:4, Interesting)
Actually, I rather think that you are placing the blame on the wrong set of individuals here.
I work for a closed-source software company, which has some extremely large customers using our product. We were implementing minor/major releases and we incorporated functionality changes to minor releases. This was a problem almost every time, because at least one of our customers was using that feature and relying on it to work the way it worked in the previous patch.
Consequently we stopped adding new functionality into the minor releases.
You'll notice, however, that it's not the developers that caused this issue. No. It was the project and product managers for either a. allowing the functionality change, or b. allowing the functionality change but not realising the sheer impact it would have on the client-base and thus not planning accordingly.
That said, the difference between the company I work for and the Gnome project (after reviewing the ) was that when a regression occured for us we scrambled for a fix within a week, while the Gnome guys say things like "The bug is fixed when it's closed as FIXED.", "Paolo, Manu: Whining does not really help in getting things fixed. [gnome.org]
"What's the hold up?" Write the code for it and attach it here." and "Yeah. And the codebase for 2.24 has changed a lot, so the 2.22 code has to be
adapted/changed a bit. Just do it, the code is available. *shrug*"
The last comment was the most infuriating to a lot of people I think. The best response [gnome.org] I read in relation to Andre Klepper's "*shrug*" comment was:
As a fan of open-source for a LONG time, I'm beginning to wonder if it will ever cut it in the business world. I suspect with attitudes like the ones highlighted above that the answer is "no". And that makes me feel very, very sad.
Re: (Score:3, Insightful)
Well, most of open source is like that. It's full of eager developers who seek the glory of making software used by millions of people, but shy away from the onerous responsibility of maintaining and supporting it.
When a user complains, it's often taken as a personal insult or a slight on the developer's talents. They feel the need to retaliate with a dismissive or snarky response, and the whole thing erupts into a flame war. Or worse, the issue just stagnates because the developer digs in their heels si
Re: (Score:2)
A "Linux" thing huh? Could you be more vague?
The GNOME project works on a number of platforms, not just Linux, and to be honest they are pretty much the worst offenders.
Common developer problem (Score:5, Insightful)
Seems like a problem I see very commonly with developers:
Dev: "The old thing sucked, so we built this shiny new better thing."
User: "Does it do everything the old one did."
Dev: "Yes! It's just that the applications don't support it yet."
User: "So stuff that I use now stops working?"
Dev: "But our new thing is better. BETTER!(tm)"
User: "So stuff that I use now stops working?"
...and on this goes. Suffice to say the user doesn't give a shit about protocols and how sucky the old system was and how awesome the new thing is. He cares about features that did work now suddenly stop, and in his eyes, your new thing
sucks more than the old one, because it doesn't *work*.
Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.
Sadly, many developers never figure this part out.
Re: (Score:2, Funny)
Good developers don't care. Said user can go back to his C64 and stop complaining. Everyone else can have progress.
Re: (Score:1, Insightful)
Re: (Score:2)
Re: (Score:1)
Everything must get worse before gets better, its a matter of balance...
...only that sometimes it gets worse and better simultaneously... and stays like that.
I love whole the world
And all it's craziness
boom-de-ah-da, boom-de-ah-da
boom-de-ah-da, boom-de-ah-da
Re: (Score:1)
It has the application shutdown thingie.
Re: (Score:3, Interesting)
> User: "So stuff that I use now stops working?"
Yep, that is very much my experience with KDE 4.1. So many things stopped working that it is barely usable. Which is fine, expect that version 4.0 was supposed to be the shiny new framework, and 4.1 was promised to be ready for the end user. By sticking labels on it, the developers create expectations in the user base, and the stick is justified if the expectations are not achieved.
Re:Common developer problem (Score:5, Interesting)
Hear, hear. At work I maintain a internal fork of an open source library we use. Not because I enjoy forking: because the guy with write access to the library's repository started a major refactor 18 months ago in trunk and still hasn't finished it; the subset he uses works, but we use some of the more advanced stuff which he hasn't fixed yet. I can't just take a snapshot before the refactor because then I miss loads of bugfixes.
Re:Common developer problem (Score:5, Insightful)
But at least you can do that, even if it's not the most desirable option. With commercial software, you'd only get the backported fixes that the vendor decided were important enough (unless you were big enough client to scream and shout very loudly, or buy a $$$ support contract.)
It's always seemed to me that the basic philosophy underlying OSS was one of "the world is imperfect, but if we work together we can push it slowly in the right direction", as opposed to pretending that everything's perfect and then discovering one day that not only is it not, but that you're SOL because you don't have the freedom to do anything about it.
Having said that, expressing a certain amount of exasperation when stupid things are done is also part of engaging authentically in the process :)
There is nothing magical about open source (Score:4, Insightful)
But at least you can do that, even if it's not the most desirable option.
You can do it if you have the time and resources needed for the job.
In that respect, "software freedom" is rather like "freedom of the press," something to be celebrated on the Fourth of July.
It's practical significance is for those in the trade - and even there it can be more symbolic than real.
Re: (Score:2)
It's practical significance is for those in the trade - and even there it can be more symbolic than real.
Agreed - with the first part anyway. But even then it's hopefully still a win for end-users in the long run: the availability of the OSS code base should reduce the barriers to entry into the various markets that can use it, which should mean competition. Nobody expects Joe User to be touching the source to the programs he runs, but if the company he buys his mobile / netbook / home router / tech suppor
Re: (Score:2)
I was tempted to say that your attitude toward press freedom is telling, but then I decided to replace the word 'symbolic' above with 'potential'.
Ultimately, I think I can accept your premise, if not your interpretation. But then again, I've contributed to more than a couple of FOS
Re: (Score:2)
In that respect, "software freedom" is rather like "freedom of the press," something to be celebrated on the Fourth of July.
It's practical significance is for those in the trade - and even there it can be more symbolic than real.
I think if you were to live in a country that did not have a free press, you'd miss it. Particularly since it's almost certainly go with restrictions on free speech. Many of the rights in the bill of rights apply to some specific class, like "criminal suspect" and if you aren't in it you probably never invoked the 4th, 5th, 6th or 8th amendment. If you're not a gun owner, the 2nd amendment doesn't apply directly to you. I don't know anyone that's ever invoked the 3rd amendment in the 21st century. It's a ma
But that is a different related issue (Score:3, Insightful)
Which is change management. When and how do you make needed changes to code? Like it or not, most developers have absolutely NO skills in actually managing a project of this sort, and have none of the related process/management skills. Some do, but most don't.
What most projects REALLY need is a small committee which handles policy changes. Do we want to refactor in the middle of a stable branch? What are the policies involved in releases, etc, and actually enforcing this sort of thing. Then you have a
Re: (Score:3, Funny)
Not because I enjoy forking
Don't kid yourself, this is slashdot. You and all the other geeks here would love to do some forking.
Re: (Score:1)
Then it is not refactoring. Refactoring should (barring typos and thinkos) keep the functionality identical *with every change that you commit*.
What that guy is doing (and what the Gnome devs are doing with the session management) is essentially a rewrite. These are tricky and potentially dangerous, but can be beneficial in the long run. However, these should always be done on a branch and should be tested. Regressions are likely to happen with this type of work.
I am surprised that the reviewers for the Gno
Re:Common developer problem (Score:5, Insightful)
OTOH, if you never exert any pressure on application developers (to add support for the new shiny thing) and end users (to upgrade the applications), you end up supporting horrific APIs for years (*cough* Windows *cough*)
Open source can afford to be a bit more proactive on this front for various reasons. More of the code that runs on open source platforms tend to be open itself, so if necessary it be fixed by a third party. Linked to this is the concept of distributions, which means someone takes responsibility for evaluating the shiny new APIs and integrating patches for the apps if necessary. Last but not least one would hope that the users are slightly more engaged in the technology they are using, and therefore be prepared to put up with small-ish inconveniences in order to see progress made.
Of course, the particular decision we're talking about here does seem to have been a bad one. But it's a failure of judgement, IMO, rather than a failure of the development culture (i.e. the one that allows developers to make technical-aesthetic decisions sometimes, rather than trying to keep the users happy at absolutely any cost, which is of course impossible anyway.)
Re: (Score:2)
Last but not least one would hope that the users are slightly more engaged in the technology they are using
I would guess thath the average level of technical savvy is higher in the free-as-in-linux world; however, I dearly hope that the median level is the same as everywhere else (or maybe even lower).
Or rather, I hope for something that would cause that: a mass adoption of Linux.
Aside: "mass" is an exaggeration: I'd be happy with whichever distribution of market share among vendors (and... givers?) that'll make people take Linux seriously as a desktop platform and develop for real standards rather than Microsof
Re: (Score:2)
Back On Track: I'd rather have the tech-savvy bar set lower: that's what's going to drive the adoption. It's simple, really: people want computers that work. Their definition of work is "I can igure out how to make the computer do what I want". The easier that is perceved to be (let's try and make that match reality), the better looking the (Linux) offer is.
Yup, me too. But the openness of the market should make that more plausible, regardless of the occasional dotty upstream decision. The GNOME guys may ha
Re: (Score:2)
you end up supporting horrific APIs for years (*cough* Windows *cough*)
Where does this stupid *cough* gag come from? It's really lame.
I agree that the Windows API sucks. But let's be fair: the X Window System API sucks even more and has been around almost as long. The big difference is that there are some decent APIs running on top of X that impose some sanity, whereas Microsoft keeps bungling every new GUI platform it creates.
Re: (Score:2)
Where does this stupid *cough* gag come from? It's really lame.
Oh, I dunno, I find it less irritating on screen than when it's done IRL ;-)
I agree that the Windows API sucks. But let's be fair: the X Window System API sucks even more and has been around almost as long. The big difference is that there are some decent APIs running on top of X that impose some sanity, whereas Microsoft keeps bungling every new GUI platform it creates.
I don't know that X sucks, per-se, it's just become quite a large pile of la
Re: (Score:2)
People do it in real life? I've only ever seen it on TV shows. I mean, it's really hard to cough and say something at the same time. I guess what I should ask is what TV show first thought it was funny. Happy Days, at a guess, the show that invented the very Shark Jumping meme.
Layers have nothing to do with it. A good API provides a simple way to do common things. You should have to construct a complicated GUI framework every time you start writing an application. Neither Windows nor X Window System has an
Re: (Score:2)
It seemed to be fashionable when I was at school. Drove me nuts, mainly because I couldn't do it convincingly ;-)
The core of X was never really designed for writing apps with directly. At the very least it was expected that people use Xt [wikipedia.org]. The question in my mind has always been whether separating widget drawing and window management from basic region handling was efficient enough, and whether it made things too complicated. Here's a thought: given that GTK+ now uses Cairo most places, and Cairo can target D
Re: (Score:2)
A lot of the time users don't have to pay for upgrades/updates, that also helps a great deal
Re:Common developer problem (Score:5, Insightful)
It's a bit too simple to paint this as a user/developer problem. It's often equally much a developer/developer problem between the one changing the interface and the ones using the interface. Breaking stuf without depreciation and/or clear version jumps is very bad. Not following up on deprecation warnings is equally bad. Together, they're supposed to work as a team to make sure that the end user never notices. I've certainly met the kind of developers that will not fix their shit until the compile fails or the application crashes and burns. How long this period should be in practise depends on the circumstances.
Re:Common developer problem (Score:4, Insightful)
I propose we come up with a name or a term for this argument so that it doesn't have to be rewritten verbatim every single time there's an article that even begins to hint at either a usability issue or the expectations of the average end-user. It'd save all of us a lot of typing and would save Slashdot a ton of storage space. You see, it keeps getting raised as an "issue" only it's not getting anywhere; this "issue" never seems to develop its reasoning. The result is that lots of people are speaking about it, only they're all saying the same thing. If this name or term became a common one, perhaps then we can all just acknowledge the reality that developers are not average users and may think differently from average users. Why, one day, it may even be considered so obvious as to not bear repeating! Or at least, not without also suggesting a constructive solution.
I'll add that constructive feedback is one thing and developers often appreciate it, but I don't feel like I have a moral right to actually complain to an open-source developer when I am benefitting from his or her generosity. If I were buying commercial software or hiring the services of a programmer to perform custom work for me, I would then feel like it's reasonable to expect that the result matches my exact specifications. But when a complete stranger has decided to benefit me expecting nothing in return, that is a different situation in my opinion. Like I said, constructive feedback is one thing, but to complain about not even the software itself but the developer and what they should and should not care about or what their priorities should be seems a little out of line to me.
I think too that we forget that much of the technology we now enjoy is the direct result of advances made by those horribly out-of-touch developers (sarcasm) who did care about the underlying architecture and did think of how awesome the comp sci might be. You don't usually do difficult, painstakingly detailed work like that unless you find something creative or expressive in it that pleases you. This creative force is something that should be appreciated and cultivated. I could make a silly play on your post by saying "sadly, many users never figure this part out." When people lack understanding, they lack understanding; that's all. There's really nothing special about this particular "users and developers" issue except that a little mutual understanding would be a significant improvement.
Re: (Score:1)
Re: (Score:2)
It was a nice thought anyway. I for one am glad to see your username!
Re: (Score:2)
I propose we come up with a name or a term for this argument so that it doesn't have to be rewritten verbatim every single time there's an article that even begins to hint at either a usability issue or the expectations of the average end-user.
Call it 'Little Red Hen [wikipedia.org] Syndrome', then. The unfortunate truth is that non-participants in FOSS culture are only coincidentally beneficiaries of its largesse.
Actually finding a role for oneself in the process of making Free Software better is at times onerous, awkward and occasionally frustrating. Ironing out differences in perspective and expectation is a task that humanity has never done well, and - surprise surprise - FOSS is no exception.
My personal experience, however, is that, like democracy, it's sim
Re: (Score:2)
Can I propose "users are lazy"? It pretty much explains everything, if you think about it. And I don't just say that as a developer, either...
Re: (Score:2)
Re: (Score:2)
Which popular desktop distros use ext4 by default?
Re: (Score:2)
Re: (Score:2)
Yeah, but you said that "the two most popular desktop distros are horribly fucked by using it". To say they are "using it" when they offer it as an option is stretching the term a bit far, and they are certainly not "fucked".
Re: (Score:2)
"Use this crashproof file system!" *
"* warning: filesystem will not crash, KDE/GNOME will. Badly."
Like saying "Linux is crashproof!" when X most certainly isn't.
Re: (Score:3, Informative)
Your prone to unfounded exaggerations, aren't you. Nobody advertised it as "use this crashproof file system!". Point me to the screenshot if you have proof to the contrary.
Also, this [livejournal.com] has already been fixed [livejournal.com] before Ubuntu 9.04, for one, is even out of alpha.
That's that, but let it be said that your other examples are at least equally inane (hint: stability without a GUI is still a valuable property).
Re: (Score:2)
Gah.
1. You're
2. Second link should have been http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8 [kernel.org]
Re: (Score:2)
Does this [kernel.org], this [kernel.org], and this [kernel.org] not solve the problem?
Re: (Score:2)
Re: (Score:2)
This is open source development.
The source is there. The projects accept patches. There's no reason to work around crappy code when it can be fixed.
Ted is technically right, AFAIK nowhere in the standard it says that a rename must flush the file being renamed. For all you know this still breaks in Solaris.
Re: (Score:2)
Re: (Score:2)
Well, if multiple independent vendors take a spec and implement it in a way that break your assumptions, maybe you should reconsider whether your assumptions were correct.
Hence all the comments about sqlite. If you find dealing with the low level API too complicated, use a simpler abstraction.
Re: (Score:2)
Re: (Score:2)
The source is there. If the code is shitty, then the right thing to do is to make it not shitty, instead of adding shittiness to another piece of software to work around it.
Also, note:
Patch #1: Adds an EXT4 specific ioctl. Meaning the interested application must specifically call this. Obviously no current apps do. Maybe databases and such will use it.
Patch #2 and #3: These only apply "if the filesystem is mounted with data=ordered". This is the default setting, but the user or distribution can change it, s
[OT-ish] ext4 (Score:2)
I'd rather have ext4 than XFS [zork.net]!
It was just one of those nasty intersections between real-world usage patterns and and unexpected consequences of an intended feature (isn't the whole point of extent-based filesystems that we can do stuff like delayed allocation?) Sadly, I guess Canonical can't yet afford to pay to have hundreds of users sitting in labs typing randomly at PCs like MS can.. but OTOH, isn't a beta release a good substitute?
And let's not forget, Ted produced patches PDQ. He had a bit of moan at t
Re: (Score:2)
Re: (Score:2)
Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.
Sadly, many developers never figure this part out.
The problem is that we NEED someone to care about the underlying architecture. If nobody does, the system fails.
Yeah, sure - most users see computers as magic black boxes. But they wouldn't exist if everyone just sat around looking at a box and wishing for rainbows and unicorns (although you might get some nice books / movies). Someone's got to open the box and figure out what's going to go in to it to make it do the things people will take for granted tomorrow.
The danger is in extremes. Change too much
Re:Common developer problem (Score:4, Interesting)
It's for just that reason that I question this mostly unstated assumption that anywhere there is a gap between developers and users, that it is somehow entirely and automatically the job of the developers to bridge that gap. When you are talking about Open Source software that is both free as in speech and free as in beer, there is certainly no moral expectation that this should be the case.
The average users in this scenario are non-contributing beneficiaries. Non-contributing beneficiaries who are demanding instead of helpful are beggars who are trying to be choosers. Here, I'm not talking so much about what is said and done so much as the way it is said and done and the intent behind it. It's one thing to politely ask for a feature or a change because you think it would be great. It's quite another to make judgments about someone's character or their ability to figure something out because their free contribution was not to your liking.
By and large, these users are unwilling to acquire the skills necessary to implement the changes that they demand from the developers and yet some of them are willing to pontificate about how a developer should think. When the GP said "Sadly, many developers never figure this part out", that is a manipulative way of saying "they seem to disagree with me about what should be important." I say that because some things genuinely are "sad" while others are merely differences of opinion and it is intellectually dishonest to conflate the two. The only reason for doing it is to give an undue appearance of superiority to your own viewpoint but if your viewpoint were truly superior, no such tactics would be needed.
Furthermore, this is a difference of opinion not between two equal viewpoints but between a contributor and a non-contributor. Beware the tendency to automatically consider all viewpoints to be equal. It has a certain allure because it can sound noble but there are many times when it just isn't the case.
When you unnecessarily phrase something in a manipulative fashion, subtle though that may be, it has some interesting effects. Most people are not aware enough to understand why or to see this process as it occurs, but what happens is that they instinctively sense that there is a "wrong feeling" to it. Unfortunately many people, even those who can see this happening, lack the strength to just calmly point it out and show by their example that there is another way. They don't know how to experience it without being affected by it because they are externally motivated and it is external ("externally motivated" = "responds to pressure"). So when they sense this "wrong" feeling there is a tendency to either appease it or to fight it, depending on the character of the person. Both are wrong because both are harmful.
Appeasing it is a mistake because it validates the tactic and sends the message that it's acceptable and will obtain the desired results. It also robs the appeaser of much of the joy that could have been found in the creative process by replacing noble service with demeaning servitude, a process that tends to breed resentment. Fighting it results in senseless pissing contests and personal arguments which reinforce the "us against them" mentality, in this case "the interests of developers vs. the interests of users". It also makes sure that your position is no better than that of the other person and so it destroys your ability to lead by example even if you were initially correct. There a
Re: (Score:2)
Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.
Sadly, many developers never figure this part out.
The entire IPv6 standards group never figured this out.
It's buzzword compliant and has features than can only be expressed in scientific notation, but can you get to your favorite websites with it? No, you can't. You can send email with it? No, you can't.
People wonder why only internet engineers get excited about it.
Re: (Score:2)
Sadly with IPv6 it's the only way to do it. There's no way to extend the address space in a compatible manner, because there's no way for an old node to indicate a new node as a destination address. So it's not a question of IPv6 being badly designed, it's a question of whether to transition at all, or stick with an ever-growing stack of increasingly rickety hacks that may eventually fall over (how many layers of NAT does it take before P2P apps like VOIP can't punch their way through? Excuse me if I don't
Re: (Score:2)
There's no way to extend the address space in a compatible manner, because there's no way for an old node to indicate a new node as a destination address.
Sure there is. The easiest backwards-compatible option would be to add an optional extra address field to the IP header. NAT gateways would then examine any incoming packets, and if they have that option set, they would pop off the first one and send the packet off to whichever address was named there. For packets without such options, they'd behave as they always did.
*poof* no more address shortage. An additional advantage is that NAT could no longer pretend to be a security tool.
IPv6 is a great leap forwa
Re: (Score:2)
It sounds like you're thinking about assigning bigger addresses only to clients, i.e. the ones initiating the connections. That's fine, but at some point we're going to need to assign the new, bigger addresses to servers, and that's a bit of a different issue (and of course with P2P, everybody's a server.) For servers listed in DNS you could I suppose do the reverse of what something like totd [mahidol.ac.th] does, and return a fake IPv4 address to the old IPv4-only client, but .. yuck.
At some point new code will have to b
Re: (Score:2)
DNS would need a new address type instead of A. It would contain a list of IPv4 addresses. Something like 1.2.3.4:5.6.7.8:9.10.11.12. Old clients would only look up A, and so they wouldn't work.
It wouldn't be a big problem though. There are many many clients for every server, and people who need P2P would be eager to upgrade.
Re: (Score:2)
Just to chime in as a developer. Here's how the conversation too frequently sounds from my perspective.
Dev: "Due to ever improving changes in hardware capabilities and the demands of the field, we had to refactor several of our libraries. Though we tried to maintain backwards compatibility as much as possible, in some cases we could not."
User: "Does it do everything the old one did?"
Dev: "Yes, and more. You can now x, y, z which was not possib
Re: (Score:1)
The new Gnome DBUS session management system may be better than the X protocol, but:
1. will other session managers adopt the new protocol (KDE, Xfce, X11)?
2. what if a user wants to use an older version of a program that only supports the older protocol?
3. will application writers need to support both protocols? (answer: yes)
4. applications supporting both protocols will need to abstract it - how easy is this to do?
5. what if an application refuses to use the new protocol (not standardised, not stable,
It is a problem... we need tracker moderation (Score:3, Interesting)
When you run an open to post bug tracker you are inundated with idiots who think a bug tracker is a discussion forum as well outright spambots. Some of the "me too" and "I think this is a major bug" posts could be addressed with a "me too" button and counter in the tracker. But..
I have a modest proposal for what we really need:
1/ cold hard cash
2/ nothing appears in the publicly visible tracker until approved by a moderator
The way this would work is when you file a ticket your credit card should have $50 deducted and the ticket hidden from view until it has been approved, if approved you should get $40 back. So if you report a crash without the backtrace or even a description what you were doing when it happened you are out $50. After paying the CC fees any 'profit' could be burned in trashcans to provide heat for the homeless, just so the moderator can not be accused of being unfair for the cash. Similar fees could be applied to ticket comments, say starting at $10 per inane comment and escalating to $100 for repeat offenders. None of these comments would ever have to make it out to the publicly visible face of the tracker, but there are plenty of people who would still keep posting at $100 a pop just to annoy the devs. Burning thousands of dollars in small bills could warm the hands of many a homeless man, and scaled up to a large number of OSS apps would help keep inflation under control.
To the humor impaired: Ok, this is tongue in cheek. My point is that once a project grows past its first few thousand users a public issue tracker becomes a liability. Real bug reports get lost in the constant barrage of junk tickets, but you can't even close those junk tickets because then you have to deal with some luser with a bee in their bonnet.
Re: (Score:2)
I seem to recall Sun used to charge customers for reporting bugs that it later decided weren't. My memory is not what it once was, however :)
The meandering nature of discussions on bugs.launchpad.net has been bothering me too, recently. Maybe a simple Slashdot-style moderation system is a solution? I think LP already has a "me too"-type button / link, maybe there should also be a way for admins to convert users' otherwise content-free "me too" comments into simple votes for fixing the bug, which would unclu
Re: (Score:2)
Microsoft does that too. Or atleast did 5 years ago when I tried to report a bug to them.
Re: (Score:2)
Doesn't Gnome already require a trusted user to confirm bugs in their tracker before anything is done with them?
I know that was the case with one that I discovered after talking with some Gnome devs on IRC (and the guy I was talking with immediately confirmed it; for the curious, it was a bug in Evolution).
Re: (Score:1)
No, that is not true.
Only some users can confirm bugs, I assume you think it implies more than it is in practice.
Re: (Score:2)
Regarding becoming a discussion forum, in my experience it's a sign of lacking other ways to give some design input. In the commercial world, if you bother to put together some notes on what problem you're trying to solve, how the solution is today and how it could be improved, what it means for you and how it could help the product in general. then it's usually well appriciated. That is because there's someone sitting on the vendor side guessing what the customers want and need, who appriciate you taking s
Re: (Score:3, Interesting)
The nice thing about a public bug tracker is that many problems have been raised and solved often without changing a single line of code. As a simple example my ethernet card was showing up as eth8 and not eth0 by use of google and finding a bug report i found the reason was due to a udev rule and a particular file which i then edited to get eth0 back. There was no need to go any further.
I found another feature/bug in open office writer today I wanted a block of text in title case and found open office give
Re: (Score:2)
Credit card, bank transfer, and paypal would all work. There are plenty of ways to transfer money these days.
The worry of course is whet
Adapt Policy in the Open (Score:3, Interesting)
"Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy?
Policy adaptation is a care-requiring activity, especially if discussion in the open is involved. Closed projects may get away with customer defenestration, but open source projects are more susceptible to their developer community and enthusiastic users. How a project would adapt policy should be given a great deal of thought and dialog to ensure no one is left out of the loop.
I hate to say it (Score:2)
But things like this are why people still trust Windows more than Linux; at least they won't randomly lose major features after an upgrade.
Re:I hate to say it (Score:4, Insightful)
Not entirely true. I just switched back to Linux from windows for that very reason. After an upgrade, I lost networking for no reason. Took several reboots of boh the laptop and the wireless router to get it back.
At least with Linux you know the regression was likely intentional. Stupid, but intentional. The Windows folk just don't know what they're doing.
Re: (Score:2)
Heh... funny, but I have the opposite.
It seems like every open source project eventually swerves off the road and into a ditch.
-OpenOffice v3.0 (fails to register extensions on many Windows systems; no file extension dialog)
-Deluge Bit Torrent (Options to start in a paused state removed; blocklists now load after torrents start and connect to seeds/peers)
-CVS (I've never used it, but why do you think SVN and GIT now exist?)
-Gnome (Kills apps instantly. I don't mind, to be honest. I even use this feature to
Re: (Score:3, Informative)
OpenOffice, from what I heard of it, isn't really as much an open source app as an "opened closed source" one. I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something. And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please. Outside contributors may find that something they spent a month working on is now useless, because core decide
Tell me more (Score:2)
There is always a reason.
You talk about an upgrade. What were you upgrading?
Hardware? Software? Third-party driver?
If the re-booting solves the problem it strikes me that the OS is doing it's job on start-up. Unloading the trash. Resolving conflicts. Working towards a clean launch.
Re: (Score:2)
At least with Linux you know the regression was likely intentional. Stupid, but intentional. The Windows folk just don't know what they're doing.
That's a bunch of crap. I've run both Windows and Linux and they both have their share of bugs. I have experienced clean upgrades with both, and broken upgrades with both. Software is complex, and so is the mix of hardware that operating systems have to support.
Re: (Score:2)
Yeah, like being able to load old versions of their Office files. Oh, wait...
Re: (Score:2)
But things like this are why people still trust Windows more than Linux; at least they won't randomly lose major features after an upgrade.
Like file-sharing via firewire (1394) just vanished in Vista - though it was available in XP?
Re: (Score:2)
It's just not true though.
I've had wireless network drivers stop working after a windows update installed new ones and only got them working again by uninstalling them and installing an older version.
Just this week I was using Visio to reverse engineer an old DB schema but a security update in one of the office service packs stopped the functionality working. For a while you had to roll back the update to get it working. Then there was a hotfix you could get but had to contact MS support for. By the time I
Incentive (Score:2)
What is the incentive for unpaid developers to abandon their private lives to go into crunch mode developing something for some(thankless)one else? A thousand "me too" on a bug tracker or a million "+1"s have yet to purchase a cup of coffee. "Market share" and "exposure" have little value to encourage altruism in project members. But endless bitching has enormous power to discourage it.
A smart member of this project would neither post to nor reply to that bugtracker thread.
But that's only because this d
Re: (Score:3, Insightful)
No, you're missing the point. Yes, that is one value. But the popularity of an open source project is directly tied to its influence. If there are too many regressions like this which are incompetently handled, people will end up saying "fuck it" - and either fork the project or move off to something else entirely. Just because you volunteer your time doesn't mean you don't handle it professionally - these things reflect on you when it's time for the rubber to meet the road and you need to get paid some
Re: (Score:2)
I don't mean ignore users, nor put out bad code.
Actually, it looks like the people working on the session code are doing an excellent job, and doing the best they can to create a quality package. It just appears that, unfortunately, either Ubuntu or Gnome made a release cut in the midst of the session package's gradual migration from one IPC mechanism to another. The session code itself is not an issue, as far as I can tell. So, where was the problem generated, and who gets blamed? I see 3 points of con
Re: (Score:2)
I admit to having screwed this up myself with a project I maintain - something I'm trying hard to rectify as we speak.
With this sort of honesty and self-awareness from the maintainer, I'd feel a lot more comfortable about using the product (and contributing to it, if I were able).
Session management (Score:2)
A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature.
I think losing that "feature" is a feature in itself.
I'm currently using xfce, and the fact that the session manager thinks it works annoys me quite a bit. I have in fact turned it off, but it still chooses to open a bunch of firefox sessions before wlan is up (and NetworkManager is querying the password in the background).
Another useful "feature" of session management is opening up 17 terminals on bootup. This feature just needs to go. I'm not a big fan of Gnome, but they got this thing right ;-).
Re: (Score:2)
I seem to recall having to delete some files from somewhere after disabling session saving in Xfce (~/.cache/sessions maybe?) Either that or closing everything and quitting to save an empty session first, and then disabling it ;-)
just wait it out (Score:2, Insightful)
I'm going without session management for about 6 month now and I really didn't notice. Gnome session 'management' has always been broken, at least for some years imho.
Isn't that how it goes? Some things break, more get better. Next ubuntu release is just around the corner anyways.
Do you remember pulse audio, upgrading to 64bit, how long it took for utf8 to actually work out of the box, or this one issue with redhat and kgcc?
There is no easy way, progress always creates problems.
Re: (Score:3, Insightful)
OK, I'll bite.
I don't think the submitter was knocking OSS, or advocating commercial software as an alternative. I think s/he was genuinely interesting in figuring out what went wrong here, what to do about it, and how to handle the increasingly forum-y threads that turn up on bug trackers these days (particularly on launchpad.)
Re: (Score:2)
Flamebait? No, not flamebait. Allow me to clarify.
Fedora decided that they were going to ship KDE 4 before it was ready. I unfortunately decided to upgrade to Fedora 10. Half the features weren't there, it crashed randomly and had unexpected behaviors, and it was just unusable. I was pretty unhappy with the whole situation. Kmail still has a few regressions in it, the "system settings" is pretty unpolished, and they are still nowhere near the level of 3.5, even on 4.2. 4.2 has been the first release t