I don't know, but what I do know is that a red blood cell is a hell of a lot bigger than a virus or an antibody. So if you filter out those, you filter out the red blood cells. That would not be a terribly useful material for blood transfusion.
I'm aware of techbase. It's not really helpful. Let me give an example. Suppose I want to write a Plasmoid. Okay, let's start at techbase.kde.org. Under "Discover" I click on "Developing with KDE." Fine so far. Now what do I click? It's hard to say -- I want an API reference. Nevertheless, I figure out that I need to click on "KDE Architecture." Okay, now I click on "KDE 4 Architecture Overview." Ooh, I finally see a link to "Plasma - the Desktop." I click it.
Now, I have three choices. The most logical is the link called "API." I click that, and now all of a sudden I need to shift my focus to the left hand column, where I finally locate "Plasma/Applets." I click it. I get this useless page. But hey, there's a link to Plasma again! I click it, and I get this.
I refer you to my earlier post ITT. There are just so many things that are now mandatory in KDE4 I feel claustrophobia. Ironic, since I love Python's OTW but how come I can't get rid of that button in the top corner?
As an honest question, which parts of the interface are you considering mandatory, because you can turn almost all of it off. As far as the button in the upper-right corner, I find that annoying as well, but I'm not aware of any other part of Plasma that you can't turn off if you want to. It doesn't even take that much. Just delete the panel.
One of my favorite things to do (yes, I'm weird) was hammer on that button as the system was trying to POST. Most BIOSes did not handle this very well at all. They would fail in all manner of hilarious ways.
wait, I thought part of the sprint creation was team estimates of "points", 1, 2, 4, 8, 64, and 128.
I'd like to note that the point scale isn't fixed. That particular point scale (powers of two) seems a little too granular for my tastes, but whatever works, works. Around here, we use a Fibonacci sequence -- 1, 2, 3, 5, 8, 13... Numbers other than these are not allowed. This represents the reality of software development -- as complexity increases, the ability to accurately estimate decreases. It's more of an ordinal scale than a linear one, but some kind of numeric value is required, if you want to gauge your velocity.
How do you estimate how much work each piece is going to be, in order to divide the work into proportionally-sized pieces?
The methods for doing that vary, and Scrum does not dictate any particular method. Typically, backlog difficulty is measured in terms of "points," which are dimensionless numbers that do not map directly to lengths of time. The point scale is arbitrary, but is supposed to be fixed. Team members generate individual estimates for each backlog (including those they won't be directly involved with) and these estimates are then collected by a vote. It sounds chaotic, but it really isn't that bad, because you can often draw a comparison between a new backlog and something you did, say, last year -- if that thing turned out to be a "5", then you might start out with an estimate of "5". Team members will debate, and some may revise their estimates up and down. Once the backlogs have been assigned these point values, enough of them are brought in to meet the velocity the team has demonstrated in the past.
There's always slop in the system -- a prescribed set of rules is incapable of dealing with that. That's where wise management comes in.
What's the difference between that and estimating?
The estimates are estimates of difficulty, not the amount of time it takes to complete something. The amount of time it takes to complete is defined as the sprint length. I admit I was very confusing in my initial post.
It puts no horizon on anything. I'm having a hard time imagining a task that simply cannot be broken into manageable pieces, but suppose there was such a thing. At the end of two weeks, the item will not have been completed. Ok, fine -- unless you're working somewhere really weird, where failing to complete a backlog results in you getting fired or something, I don't see what the problem is. You don't just throw it all away and start over, you push onward. If you're tracking velocity like you should, this will ripple down and affect the number of story points you allocate in the next sprint, which should allow you to pull in additional team members to help get the tasks completed.
The time-boxed sprints are a critical component of Scrum, because they force development and QA work to be interleaved. A backlog will include development work AND whatever testing work is required to fulfill the item's acceptance criteria. Once you start to try to work outside the sprints, you run the huge risk of doing a large chunk of development without any testing until the very end. If your backlogs are repeatedly unfulfilled/unfulfillable, then there is a problem with the construction of the backlogs themselves, your measurement of velocity, or your team size and responsibilities -- this is a management error, not a fault of the process.
In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them. There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc. You can't "create and agree" on performance, debugging etc backlogs ahead of time.
That depends how you want to manage interior goals. Some people use Scrum only to manage externally committed product development work. Internal stuff might be relegated to a more chaotic system. But you particular example of performance testing isn't a good one. There is nothing inherently unpredictable about doing testing -- in fact, it's core to the entire Scrum model. If performance testing is creeping in at the last second and ruining your best-laid plans, then something is wrong.
Scrum's not perfect, and I'm the last one to try to champion it -- I'm just trying to describe it.
No -- the point is that the estimates fall out of the process as a side-effect. You do not approach it by forming estimates. You approach it by dividing work into proportionally-sized pieces. Then you count how many pieces you have to determine your estimate. So yes, I misspoke by saying that Scrum doesn't generate estimates, but it does so in an indirect way.
Scrum is a way of chunking development into well-defined portions. The idea of using Scrum to estimate time just doesn't make sense. Everything in Scrum takes the same amount of time. Two weeks. (Or one week, or whatever your sprint length is.) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks. So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint. Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.
This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?" That's much easier than making wild-ass guesses about the time it takes to do something.
There's no such thing as a taskbar. There are Plasma panels, and these can be located pretty much anywhere you want. Just add a new panel to the top of the screen and put whatever widgets in there that you want.
And this is different from most Linux projects how?
I don't think KDE should view itself as "most" Linux projects. KDE isn't an application, its a framework and base upon which to CREATE an entire desktop environment. Given the amount of hours which have obviously gone in to code development, I'm just asking for a tiny fraction of that effort put toward helping me understand how to develop apps for it. Open source shouldn't have to be synonymous with amateurism. And like I said, I'd be happy to help with docs, but I need some guidance. I really am not in the mood to spend several weekends working on docs just to have some "guru" tell me that I'm completely full of crap and I've just been wasting my time (and this has happened to me a couple times, it really has a tendency to sour a person toward contribution).
The guy broke some serious laws, and should be punished, and is being punished. But calls for his death? Where does this vindictiveness come from? He obtained information on space flight, not neutron weapons.
You know, the reason we have laws and a justice system is so we don't need to waste our time with hatred, anger, and death urges. Grow the fuck up, folks.
The API "documentation" is still completely unorganized and most of it is just Doxygen pages. While the Doxygen tagging is fairly good, this is not a "manual," it's a reference. And what about Plasma? I've wasted hours hacking applets without a real understanding of the APIs. The Plasma API front page is pretty much useless.
Although I suppose somebody will now yell at me for being too lazy to contribute to the docs... I'd be happy to, if I had some kind of handle I could grab to bootstrap myself and start delving into it. But seriously, no, you don't get good docs by people who are unfamiliar with the code just staring at it and trying to document their own misunderstandings. Somebody who actually designed and wrote this crap needs to step in. Please?
I came to post the same thing. I'm really tired of open source developers being so spineless in this regard. Come on -- your software is clearly successful, used by thousands, people are writing books about it -- surely you can make the commitment and say hey, we've created a real, useful product here, let's roll the version to 1.0. Sure, you might need to break your API at some future time, you might discover some terrible, data-destroying flaw... But at some point you ought to just pinch your nose and jump off the high board.
Software that remains continually pre-1.0 just gives the (probably accurate) impression that the authors don't really think their software works well enough for general use. Which is, of course, an indication to the user to choose other software.
Why is it that people doing what people do naturally -- looking out for their own interests -- is normal and acceptable when you do it, but evil and wrong when somebody else does it?
IMHO, people who run into link farms are searching for really spammy shit in the first place. The idea of basing page ranking on the link structure of the web is so fundamentally correct that there's no real alternative. If your results are useless because they're filled with spam, then you are searching for some really stupid shit.
There's no denying that the fungi are incredibly successful, but by "dominating" I meant more of the "causing other species to tremble in fear" sort of thing.
Great, now you have something that will work for 5% of the cases in which people need to remotely connect.
I never suggested that this is a general crypto solution for the masses. I am pointing out that if you think you do need to security offered by an OTP system, it's not really that hard to communicate the pads securely. If I can't afford a $1000 plane ticket to deliver the pad in person, chances are my data isn't important enough to need that level of security in the first place.
And your suggestion is what, kill yourself? Yes, all governments decay and become corrupt. These governments need to be restarted. Nobody (at least nobody with any knowledge of history) holds the delusion that the next system will be perfect or last forever. But it will probably be tolerable enough, for some period of time, until it needs another reboot. Until we can figure out WHY humanity acts like this and change it (I don't see that happening any time soon), what exactly would you have us do?
Not really hard. Buy two 2 TB drives, fill them with the same, cryptographically strong random data. Travel with both drives to one secure endpoint, deposit one drive there. Return to the other secure endpoint, deposit the other drive there. The drives are never out of your possession until they are in the hands of the other trusted party. Depending on what kind of crap you are encrypting, 2 TB is plenty of pad to last for quite some time.
If physically traveling to the endpoints with the pads is cost-prohibitive, then the data you are protecting probably isn't important enough for OTP anyway.
Define fair. If I use my ability to access information relevant to the trial in my own manner (instead of the information fed to me by lawyers) to find out the defendant is at fault, why shouldn't I use it?
Because the defense needs a chance to present their arguments as to why such-and-such piece of evidence may be unimportant, irrelevant, wrong, etc. Basically, you went out and did your own research, and formed opinions and conclusions based on that, without giving the accused a chance to try to explain it. That's grossly unfair. We do not convict people on the basis of secret evidence.
Slashdot Mirror
Isn't blood filtered before it is transfused?
I don't know, but what I do know is that a red blood cell is a hell of a lot bigger than a virus or an antibody. So if you filter out those, you filter out the red blood cells. That would not be a terribly useful material for blood transfusion.
techbase.kde.org
I'm aware of techbase. It's not really helpful. Let me give an example. Suppose I want to write a Plasmoid. Okay, let's start at techbase.kde.org. Under "Discover" I click on "Developing with KDE." Fine so far. Now what do I click? It's hard to say -- I want an API reference. Nevertheless, I figure out that I need to click on "KDE Architecture." Okay, now I click on "KDE 4 Architecture Overview." Ooh, I finally see a link to "Plasma - the Desktop." I click it.
Now, I have three choices. The most logical is the link called "API." I click that, and now all of a sudden I need to shift my focus to the left hand column, where I finally locate "Plasma/Applets." I click it. I get this useless page. But hey, there's a link to Plasma again! I click it, and I get this.
Guys, this is not documentation.
I refer you to my earlier post ITT. There are just so many things that are now mandatory in KDE4 I feel claustrophobia. Ironic, since I love Python's OTW but how come I can't get rid of that button in the top corner?
As an honest question, which parts of the interface are you considering mandatory, because you can turn almost all of it off. As far as the button in the upper-right corner, I find that annoying as well, but I'm not aware of any other part of Plasma that you can't turn off if you want to. It doesn't even take that much. Just delete the panel.
One of my favorite things to do (yes, I'm weird) was hammer on that button as the system was trying to POST. Most BIOSes did not handle this very well at all. They would fail in all manner of hilarious ways.
wait, I thought part of the sprint creation was team estimates of "points", 1, 2, 4, 8, 64, and 128.
I'd like to note that the point scale isn't fixed. That particular point scale (powers of two) seems a little too granular for my tastes, but whatever works, works. Around here, we use a Fibonacci sequence -- 1, 2, 3, 5, 8, 13... Numbers other than these are not allowed. This represents the reality of software development -- as complexity increases, the ability to accurately estimate decreases. It's more of an ordinal scale than a linear one, but some kind of numeric value is required, if you want to gauge your velocity.
How do you estimate how much work each piece is going to be, in order to divide the work into proportionally-sized pieces?
The methods for doing that vary, and Scrum does not dictate any particular method. Typically, backlog difficulty is measured in terms of "points," which are dimensionless numbers that do not map directly to lengths of time. The point scale is arbitrary, but is supposed to be fixed. Team members generate individual estimates for each backlog (including those they won't be directly involved with) and these estimates are then collected by a vote. It sounds chaotic, but it really isn't that bad, because you can often draw a comparison between a new backlog and something you did, say, last year -- if that thing turned out to be a "5", then you might start out with an estimate of "5". Team members will debate, and some may revise their estimates up and down. Once the backlogs have been assigned these point values, enough of them are brought in to meet the velocity the team has demonstrated in the past.
There's always slop in the system -- a prescribed set of rules is incapable of dealing with that. That's where wise management comes in.
What's the difference between that and estimating?
The estimates are estimates of difficulty, not the amount of time it takes to complete something. The amount of time it takes to complete is defined as the sprint length. I admit I was very confusing in my initial post.
And puts a two week horizon on your creativity
It puts no horizon on anything. I'm having a hard time imagining a task that simply cannot be broken into manageable pieces, but suppose there was such a thing. At the end of two weeks, the item will not have been completed. Ok, fine -- unless you're working somewhere really weird, where failing to complete a backlog results in you getting fired or something, I don't see what the problem is. You don't just throw it all away and start over, you push onward. If you're tracking velocity like you should, this will ripple down and affect the number of story points you allocate in the next sprint, which should allow you to pull in additional team members to help get the tasks completed.
The time-boxed sprints are a critical component of Scrum, because they force development and QA work to be interleaved. A backlog will include development work AND whatever testing work is required to fulfill the item's acceptance criteria. Once you start to try to work outside the sprints, you run the huge risk of doing a large chunk of development without any testing until the very end. If your backlogs are repeatedly unfulfilled/unfulfillable, then there is a problem with the construction of the backlogs themselves, your measurement of velocity, or your team size and responsibilities -- this is a management error, not a fault of the process.
This is hacking like sawing your front door out from the frame is picking the lock. Yes, they got in.
Your comparison of an indisputably awesome hard-hack such as this to mindlessly sawing through a door makes me... sad.
In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them. There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc. You can't "create and agree" on performance, debugging etc backlogs ahead of time.
That depends how you want to manage interior goals. Some people use Scrum only to manage externally committed product development work. Internal stuff might be relegated to a more chaotic system. But you particular example of performance testing isn't a good one. There is nothing inherently unpredictable about doing testing -- in fact, it's core to the entire Scrum model. If performance testing is creeping in at the last second and ruining your best-laid plans, then something is wrong.
Scrum's not perfect, and I'm the last one to try to champion it -- I'm just trying to describe it.
No -- the point is that the estimates fall out of the process as a side-effect. You do not approach it by forming estimates. You approach it by dividing work into proportionally-sized pieces. Then you count how many pieces you have to determine your estimate. So yes, I misspoke by saying that Scrum doesn't generate estimates, but it does so in an indirect way.
Scrum is a way of chunking development into well-defined portions. The idea of using Scrum to estimate time just doesn't make sense. Everything in Scrum takes the same amount of time. Two weeks. (Or one week, or whatever your sprint length is.) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks. So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint. Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.
This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?" That's much easier than making wild-ass guesses about the time it takes to do something.
There's no such thing as a taskbar. There are Plasma panels, and these can be located pretty much anywhere you want. Just add a new panel to the top of the screen and put whatever widgets in there that you want.
And this is different from most Linux projects how?
I don't think KDE should view itself as "most" Linux projects. KDE isn't an application, its a framework and base upon which to CREATE an entire desktop environment. Given the amount of hours which have obviously gone in to code development, I'm just asking for a tiny fraction of that effort put toward helping me understand how to develop apps for it. Open source shouldn't have to be synonymous with amateurism. And like I said, I'd be happy to help with docs, but I need some guidance. I really am not in the mood to spend several weekends working on docs just to have some "guru" tell me that I'm completely full of crap and I've just been wasting my time (and this has happened to me a couple times, it really has a tendency to sour a person toward contribution).
The guy broke some serious laws, and should be punished, and is being punished. But calls for his death? Where does this vindictiveness come from? He obtained information on space flight, not neutron weapons.
You know, the reason we have laws and a justice system is so we don't need to waste our time with hatred, anger, and death urges. Grow the fuck up, folks.
The API "documentation" is still completely unorganized and most of it is just Doxygen pages. While the Doxygen tagging is fairly good, this is not a "manual," it's a reference. And what about Plasma? I've wasted hours hacking applets without a real understanding of the APIs. The Plasma API front page is pretty much useless.
Although I suppose somebody will now yell at me for being too lazy to contribute to the docs... I'd be happy to, if I had some kind of handle I could grab to bootstrap myself and start delving into it. But seriously, no, you don't get good docs by people who are unfamiliar with the code just staring at it and trying to document their own misunderstandings. Somebody who actually designed and wrote this crap needs to step in. Please?
Uh, the problem is not the lightweight vehicles. The problem is the HEAVY ones.
I came to post the same thing. I'm really tired of open source developers being so spineless in this regard. Come on -- your software is clearly successful, used by thousands, people are writing books about it -- surely you can make the commitment and say hey, we've created a real, useful product here, let's roll the version to 1.0. Sure, you might need to break your API at some future time, you might discover some terrible, data-destroying flaw... But at some point you ought to just pinch your nose and jump off the high board.
Software that remains continually pre-1.0 just gives the (probably accurate) impression that the authors don't really think their software works well enough for general use. Which is, of course, an indication to the user to choose other software.
Why is it that people doing what people do naturally -- looking out for their own interests -- is normal and acceptable when you do it, but evil and wrong when somebody else does it?
Barbies? Yugh. If I have a daughter and she's not programming by the age of 10, I'm going to disown her.
Translation: "I don't give a fuck what my daughter actually wants. She is, after all, only a FEMALE. She will do what daddy wants her to do."
Thank God you're only dreaming about what you'd do IF you had children. Please, never have any.
IMHO, people who run into link farms are searching for really spammy shit in the first place. The idea of basing page ranking on the link structure of the web is so fundamentally correct that there's no real alternative. If your results are useless because they're filled with spam, then you are searching for some really stupid shit.
There's no denying that the fungi are incredibly successful, but by "dominating" I meant more of the "causing other species to tremble in fear" sort of thing.
Great, now you have something that will work for 5% of the cases in which people need to remotely connect.
I never suggested that this is a general crypto solution for the masses. I am pointing out that if you think you do need to security offered by an OTP system, it's not really that hard to communicate the pads securely. If I can't afford a $1000 plane ticket to deliver the pad in person, chances are my data isn't important enough to need that level of security in the first place.
And your suggestion is what, kill yourself? Yes, all governments decay and become corrupt. These governments need to be restarted. Nobody (at least nobody with any knowledge of history) holds the delusion that the next system will be perfect or last forever. But it will probably be tolerable enough, for some period of time, until it needs another reboot. Until we can figure out WHY humanity acts like this and change it (I don't see that happening any time soon), what exactly would you have us do?
Not really hard. Buy two 2 TB drives, fill them with the same, cryptographically strong random data. Travel with both drives to one secure endpoint, deposit one drive there. Return to the other secure endpoint, deposit the other drive there. The drives are never out of your possession until they are in the hands of the other trusted party. Depending on what kind of crap you are encrypting, 2 TB is plenty of pad to last for quite some time.
If physically traveling to the endpoints with the pads is cost-prohibitive, then the data you are protecting probably isn't important enough for OTP anyway.
Define fair. If I use my ability to access information relevant to the trial in my own manner (instead of the information fed to me by lawyers) to find out the defendant is at fault, why shouldn't I use it?
Because the defense needs a chance to present their arguments as to why such-and-such piece of evidence may be unimportant, irrelevant, wrong, etc. Basically, you went out and did your own research, and formed opinions and conclusions based on that, without giving the accused a chance to try to explain it. That's grossly unfair. We do not convict people on the basis of secret evidence.